ProxyProviders in RiverPod

[noahsalvi]

I just recently migrated to Riverpod and I must say I'm liking it so far.
One thing i kind of miss from Provider is the following:

ChangeNotifierProxyProvider<MyModel, MyChangeNotifier>(
  create: (_) => MyChangeNotifier(),
  update: (_, myModel, myNotifier) => myNotifier
    ..update(myModel),
  child: ...
);

This creates a ChangeNotifier that has a reference of an other ChangeNotifier that gets updated through the update() method on the new ChangeNotifier. This means that the ChangeNotifier to be created, won't recompute when the referenced ChangeNotifier changes.

Atm i'm using this workaround for Riverpod:

Consumer(
        builder: (context, watch, child) {
          final firstProvider = watch(FirstModel.provider);
          final secondProvider = watch(SecondModel.provider);
          secondProvider.updateFirstModel(firstProvider)

          return ...

In this example the secondProvider would have an instance field called firstModel that gets updated through the method updateFirstModel().

[rrousselGit]

There's a WIP to allow something similar:

final myNotifier = ChangeNotifierProvider<MyModel>((ref) {
  final model = MyModel();

  ref.listen<Value>(provider, (Value value) {
    model.update(value);
  });

  return model;
});

[jlepocher]

Is this feature going to be released in the near future?

[rrousselGit]

Maybe after March
At the moment I'm full time working on a devtool for Provider/Riverpod

You don't "need" this new feature. You can do it with slightly more code yourself:

final anotherModel = ChangeNotifierProvider<Another>(...);

// obtains "Another" but will not cause dependent providers to "rebuild" when notifyListeners is called
final _anotherSelector = Provider((ref) => ref.watch(anotherModel));

final myNotifier = ChangeNotifierProvider<MyModel>((ref) {
  final model = MyModel();

  Another another = ref.watch(_anotherSelector);
  void listener() {
    model.update(another.value);
  }
  another.addListener(listener);
  ref.onDispose(() => another.removeListener(listener));

  return model;
});

That does the same thing as shown before and works with nearly all use-cases. It's just less convenient.

[Lootwig]

@rrousselGit would you also "recommend" that workaround for StateNotifier? Facing the same issue where I don't want to hard-reset Model B when Model A changes, just update it

[rrousselGit]

Yes, this is fine.

[janoschp]

@rrousselGit Why would you use watch and not read in the last example in the myNotifier _create method?

[rrousselGit]

Closing in favor of #335 for the ref.listen