How do you avoid over-fetching data with families?

[scopendo]

Hi – I've used (and been a fan of) Riverpod for quite a while now and appreciate how much it can simplify the architecture of an app. I often use families to retrieve data on demand when it's not already loaded.

For example, I might display a list of booking entities, where each booking holds the id of an associated room entity. When displaying the list of bookings I want to show the name of the room that the booking is for. This is easily done using a family retrieving the room data by id.

final roomFamily = FutureProvider.autoDispose.family<RoomData, String>((ref, roomId) async {
 // API call to load room data by id
});

class BookingTile extends ConsumerWidget {
 const BookingTile(this.booking);

 final Booking booking;

 @override
 Widget build(BuildContext context, WidgetRef ref) {
   final room = ref.watch(roomFamily(booking.id));
   return ListTile(
     title: Text(booking.title),
     subtitle: room.hasValue ? Text(room.value!.name) : null,
   );
 } 
}

This approach works but my concern is the number of API calls that get dispatched – especially when in my case the API that initially returned the list of bookings, also allows me to return the corresponding room data for the returned bookings.

What I would like is a way to supply a Riverpod family with the data for a set of keys. That way the app can take advantage of API calls that allow batch fetching whilst still falling back to get data by id if and when required.

One possibility I can think of is to have the Dart method that calls the API to get the list of bookings, to map each booking entity to have a room subobject contained within. That approach feels wrong to me, where does it stop? Plus, it wholly loses the reactive benefit of a widget watching the room provider.

Another approach I've seen mentioned elsewhere is for the "repository" layer to hold a cache of the values that have been pre-fetched. That strikes me as adding a whole layer of complexity and risks reimplementing what Riverpod already gives us.

How do other people address this issue – getting the balance right between an on-demand architecture and performance?