Comments (15)
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 #5
- In many respects, there's no need for the
Model
class at this point. You can now useChangeNotifier
directly from Flutter instead. - Allows you to embed several models in a single Provider, related to #9
- Offers a "
StatefulProvider
" out of the box (see #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 ofprovider
, or isscoped_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.
from scoped_model.
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.
from scoped_model.
@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")
])
);
}
}
from scoped_model.
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.
from scoped_model.
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
from scoped_model.
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.
from scoped_model.
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")
])
);
}
}
from scoped_model.
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).
from scoped_model.
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 ofprovider
, or isscoped_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.
from scoped_model.
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
, andScopedModelDescendant
) so that end-users see no change. - Use
provider
package for the implementations ofScopedModel
andScopedModelDescendant
. - Use
ChangeNotifier
as the basis for theModel
class, sinceChangeNotifier
is almost identical toModel
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.
from scoped_model.
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.
from scoped_model.
@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.
from scoped_model.
@rrousselGit now that provider 2.0 is out, can you update the last example from @brianegan ?
from scoped_model.
Thanks for the feedback, @kbrmimbyl!
from scoped_model.
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.
from scoped_model.
Related Issues (20)
- Some widget don't refresh after calling notifyListener in flutter 1.22.1
- bloc model value fetch in init function not working
- can't run
- can't run
- Error: Could not find the correct ScopedModel.
- Testing when using scopedModelDescendant HOT 2
- 单独抽离一个方法 如何修改值?
- 不继承 ScopedModelDescendant() 如何修改值?
- void initState() 方法里如何修改值?
- Not Working error
- Target of URI doesn't exist: 'package:scoped_model/scoped_model.dart'.
- Publish null safe stable version
- Error: Could not find the correct ScopedModel. To fix, please: * Provide types to ScopedModel<MyModel> * Provide types to ScopedModelDescendant<MyModel> * Provide types to ScopedModel.of<MyModel>() * Always use package imports. Ex: `import 'package:my_app/my_model.dart'; If none of these solutions work, please file a bug at:
- ScopedModelDescendant raises noSuchMethodError. HOT 1
- How to connect multiple models in connector (ScopedModel) HOT 1
- scoped_model issues HOT 6
- Scoped Model - not working after go back to previous page
- Model notifyListeners closes EndDrawer
- ScopedModel
- scoped_model.of() issue HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scoped_model.