Merge "provider" and "scoped_model"

[rrousselGit]

provider is an alternative to inherited widgets management.

Both provider and scoped_model aims at doing the same thing, which provider having a slightly larger vision:

provider is not limited to exposing a Model and works with potentially anything, including BLoC, streams, and others.

On the other hand, scoped_model is a lot more popular than provider.

---

The state of things is pretty confusing for the community.

scoped_model is not enough for advanced inherited widgets, but provider has a too small reach for peoples to find the package.

Would this make sense to merge both packages?

provider already implements the same features as scoped_model but with different names.
provider could expose aliases of its implementations to match scoped_model names to make the merging non-breaking.

[brianegan]

Thanks, @rrousselGit!

Overall, I really like your provider library and definitely think it can be used as a replacement for ScopedModel. That said, I'd just like to quickly list some pros and cons I can think of to help evaluate it as objectively as possible and I'd love to hear much more from the community of people using this library before coming to any conclusions.

Pros

• Provider definitely adds some nice features
• Provider is very easy to use -- Simpler names closer to the discussion in Move to React Context naming #5
• In many respects, there's no need for the Model class at this point. You can now use ChangeNotifier directly from Flutter instead.
• Allows you to embed several models in a single Provider, related to Ability to connect multiple models in connector (ScopedModel) #9
• Offers a "StatefulProvider" out of the box (see Make the model providers stateful to keep the state of the current model #58)

Cons

• ScopedModel is hyper focused. It's not as powerful, but I think that's actually a feature.
• Since ScopedModel has been generally popular, there are so many resources out there explaining how ScopedModel works and how to use it.
• We just published a 1.0 a couple months ago, indicating ScopedModel is stable and ready to use in Production apps.
• There are other alternatives to ScopedModel that are also more advanced, and you could make a Case that ScopedModel should also merge into those projects.
• Provider would introduce an additional dependency: flutter_hooks. I'd like to keep dependencies to a minimum, and the flutter_hooks logic could be taken out of thee core provider package. I'd almost consider this a necessary step before merging.

Questions for the community

• Do most folks who use scoped_model need the additional features of provider, or is scoped_model enough for many apps?
• @filiph If you have a couple of minutes, could you offer your input on this discussion and how you see it impacting the community from your perspective?
• Do these libraries really need to merge? There are a TON of libraries on pub that offer overlapping functionality.

[rrousselGit]

My main concern is that currently, we have many duplicates.
What the community currently do is, instead of making PR in one repo, they bake their own.

I don't see it as being sustainable. It's confusing and splits the community effort across many packages for no reason.

---

• Do most folks who use scoped_model need the additional features of provider, or is scoped_model enough for many apps?

Considering more than half of the points in pros represents an issue on scoped_model, I think the answer is yes.

---

About breaking changes, I think it is possible to merge provider into scoped_model while being invisible for users.

This is ultimately just widgets with different names. We could replace the implementation of ScopedModel.build/of to simply point to the equivalent provider (ChangeNotifierProvider).

The only technical difference is provider is based on ChangeNotifier, and not just Listenable. This is mainly because Listenable is not disposable, while ChangeNotifier is.
That, and the fact that ChangeNotifier implements reporting errors to Flutter.

[brianegan]

What the community currently do is, instead of making PR in one repo, they bake their own.

Agreed. I think the question might become: In that case, should we merge the features of provider into scoped_model instead of deprecating scoped model in favor of a provider?

I'd agree the name provider and the associated Widgets are more appropriately named, IMO. Even the second version of ScopedModel in the Fuchsia codebase uses the name Provider.

Therefore, I think keeping provider as the core package makes the most sense, so long as the merge is transparent to end-users.

To clarify the plan:

• Remove the implementations from scoped_model, but keep the public interface (Model, ScopedModel, and ScopedModelDescendant) so that end-users see no change.
• Use provider package for the implementations of ScopedModel and ScopedModelDescendant.
• Use ChangeNotifier as the basis for the Model class, since ChangeNotifier is almost identical to Model at this point
• Encourage folks to migrate to the provider conventions / package over time.

This would allow a very nice upgrade path for folks while giving those who need the extra functionality immediate access. We could also collaborate together more on features in the core lib from that point on.

[tsun424]

Hi @brianegan , I just switched my apps from using flutter_redux to scoped_model because I think scoped_model is much easier. Hopefully, this provider merging won't affect current scoped_model.

BTW, another state management package provide was just released. Too many options in community now, and hope again the state management solution can get relatively unified ASAP.

[filiph]

Great discussion here! I'd like to point to a related discussion.

The "ScopedModel v2" from Fuchsia is now open sourced as https://github.com/google/flutter-provide, and on pub as package:provide. There is great feedback from Remi here: google/flutter-provide#3.

I don't have an answer yet and I'd like Eric and I to ponder our options. I do think Remi's package is fantastic. I also like the simplicity of ScopedModel / provide. For example, I agree with Brian that flutter_hooks is a big dependency.

There is value in choice but there is also value in one (potentially "official") starting point.

Please keep the discussion going.

[tsun424]

Hi @filiph , you called provide as "ScopedModel v2", I was wondering why you didn't upgrade this original scoped_model to V2 and try to keep backward compatibility, which will give flexibility to community to use a unified package.

Agree with this:

There is value in choice but there is also value in one (potentially "official") starting point.

If provide is considered as an official package, maybe put it into organisation flutter is better?

In one word, relatively unified/stable(understand 100% unify never happens, also should allow different choices) is good for community.

[rrousselGit]

The dependency on flutter_hooks made sense when it was a loner package, as all of my packages complement each other.

But if provider is taking a more official path, then I'm entirely fine with removing the dependency.

[halfahad]

@brianegan @rrousselGit @filiph Any updates on the direction of your efforts in the scoped_model arena. Where should we direct people?

Would be nice to keep the community updated on any future intentions, and excited to see a concerted effort.

[xalikoutis]

The super Marvel - DC power of scoped_model is simplicity. Is understanding docs with snap photographic reading and using with a straight simple way. For more complexity, obfuscating code, no life go for Bloc, redux. So keep it as is

[brianegan]

@halfahad IMO, it makes sense to merge these projects. Remi is working on v2, which removes the dependency on flutter_hooks. Once that's in place and the API has a couple of months to stabilize, I'll encourage folks to move over.

@xalikoutis Thanks for the input. Overall, while Provider offers extra functionality, I think it can be just as simple :)

Here's a translation of the Counter app in the readme to use provider, highlighting the differences in the code comments. It's pretty much the same!

// Extend ChangeNotifier instead of Model. 
// ChangeNotifier is part of Flutter and works the same way as model!
class CounterModel extends ChangeNotifier {
  int _counter = 0;

  int get counter => _counter;

  void increment() {
    _counter++;
    notifyListeners();
  }
}

class CounterApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Use the ChangeNotifierProvider Widget instead of ScopedModel
    return ChangeNotifierProvider<CounterModel>.stateful(
      builder: () => CounterModel(),
      child: Column(children: [
        // Use Consumer instead of ScopedModelDescendant
        Consumer<CounterModel>(
          builder: (context, model) => Text('${model.counter}'),
        ),
        new Text("Another widget that doesn't depend on the CounterModel")
      ])
    );
  }
}

[hectorAguero]

@rrousselGit now that provider 2.0 is out, can you update the last example from @brianegan ?

[rrousselGit]

Sure~

// Extend ChangeNotifier instead of Model. 
// ChangeNotifier is part of Flutter and works the same way as model!
class CounterModel extends ChangeNotifier {
  int _counter = 0;

  int get counter => _counter;

  void increment() {
    _counter++;
    notifyListeners();
  }
}

class CounterApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Use the ChangeNotifierProvider Widget instead of ScopedModel
    return ChangeNotifierProvider<CounterModel>(
      builder: (_) => CounterModel(),
      child: Column(children: [
        // Use Consumer instead of ScopedModelDescendant
        Consumer<CounterModel>(
          builder: (context, model, _) => Text('${model.counter}'),
        ),
        new Text("Another widget that doesn't depend on the CounterModel")
      ])
    );
  }
}

[kbrmimbyl]

ScopedModel user here. Using it in a pretty complex app and IMHO there’s no need to merge it with Provider (which itself looks awesome. I think I would have used it instead of ScopedModel if it were available in December 2018).

[brianegan]

Thanks for the feedback, @kbrmimbyl!

[Hawlitschek]

Previously ScopedModel User here.

Today I just run in several issues I am not able to explain to myself.
I was using a backdrop navigation, managing the current front panel using scoped model.
When selecting a front panel that contains a google maps widget, the ScopedModel get killed on iOS in an instant => the app rebuild with the initial scoped model state, resulting in an instant switch back to another panel.

Since the google map wasn't that necessary, I could just remove it.

On an other front panel I used an image grid with a plus button for image selection & upload.
Hitting the plus button opens multi_image_picker for choosing images to upload.
Whenever coming back from the picker (don't matter if canceling or selecting images) on iOS, the model got killed => The front panel from the inital model state was shown.

In both cases no error messages or stack traces.

Migrating to provider seems to fix the issue.