Documentation on the best way to nest providers inside other providers about riverpod

[rrousselGit]

I don't really understand what this is about.
Could you explain more?

[not-holar]

Let's say we took something like the Todo example, but made each TodoItem widget much more complex, so rebuilding them all at once when we change a field of only one item would be inefficient.

Right now all changes to a Todo are done through TodoList and you can only listen to the whole list at once.

You could wrap each list item in something like ValueListenable and then each item widget in ValueListenableBuilder for more granular rebuilds, but that would bring in a flutter dependency.

Basically what i'm asking about is a more modular state, where items of a list could change and notify individually without rebuilding the whole list

[hpn33]

on provider that was easy for me
i make my item with ChangeNotifier
class Item with ChangeNotfier {}
and when building widget list i put them on ChangeNotifierProvider.value

ChangeNotifierProvider.value(
value: item,
builder: ....)

and its worked
when item is change just that widget on list going change

but in riverpod is complex

[rrousselGit]

One solution is to pass the index/id to the item, then use a Computed.family (or Provider.family on 0.6.0-dev):

ListView.builder(
  itemBuilder: (context, index) => TodoItem(index),
);

...

final todoItemProvider = Computed.family<Todo, int>((watch, index) {
  return watch(todoListProvider.state)[index];
});

...

final int index;
Widget build(context) {
  final item = useProvider(todoItemProvider(index));
}

[arnoutvandervorst]

  static final provider = StreamProvider.family
      .autoDispose<List<GroupEarning>, String>((_, groupId) {
    return GroupEarnings().streamList(groupId);
  });

This works on 0.6.0, very nice!

[rrousselGit]

The todo/marvel app showcase how you can avoid unnecessary item rebuild, so I will close this for now