Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deprecate ScopedModel? #86

Open
brianegan opened this issue Oct 17, 2019 · 19 comments
Open

Deprecate ScopedModel? #86

brianegan opened this issue Oct 17, 2019 · 19 comments

Comments

@brianegan
Copy link
Owner

Hey all! This might be a big change, but I think it might be the right time.

Scoped Model is a great library and a lot of folks have found success with it. However, it has largely been eclipsed by the Provider package. In many ways, you can think of Provider as Scoped Model version 2: It includes the same functionality, but extends that functionality in really nice ways.

  • The Model class is no longer needed. You can simply use ChangeNotifier from the Flutter library directly!
  • ChangeNotifierProvider and Consumer do the same job as ScopedModel and ScopedModelDescendant.
  • The Provider package also adds a Selector Widget as well, which is really handy
  • MultiProvider makes providing multiple Models very easy without a bunch of nesting.
  • You can provide any object down the tree, not only Models!

At this point, I think it might make sense to deprecate this library so it no longer appears in the search results of pub.dev and encourage folks to migrate to Provider. The library will still be available to projects that reference Scoped Model, so you shouldn't have any disruptions for projects that currently use it or need to import it from Pub.dev.

Would love any thoughts from folks in the community before making such a drastic change!
@callumclift
Copy link

I'm currently due to release my first Flutter app soon and that relies completely on ScopedModel. If this is deprecated does this mean potentially with future Flutter upgrades you will no longer support any required changes and my app could at some point stop working?

Looks like I will have to look into Provider for my next project. I'm hoping a potential migration from ScopedModel to Provider wouldn't be too difficult!

@brianegan
Copy link
Owner Author

brianegan commented Oct 23, 2019 •
edited
Loading

I'm currently due to release my first Flutter app soon and that relies completely on ScopedModel. If this is deprecated does this mean potentially with future Flutter upgrades you will no longer support any required changes and my app could at some point stop working?

Yep, that's exactly right. It will be deprecated and should continue to work for Flutter at the moment, but if there is a large breaking change to Flutter, this project would not be updated to fix those changes.

Migrating to Provider should be quite straight-forward. Please see this example in another discussion of the changes that need to be made: #61 (comment)

@deandreamatias
Copy link

Hi Brian,
I have all of my projects with Scoped Model, but I would like to migrate para Provider and this 'issue' drives me to do it.
I have a litle convern about Provider and your breakchanges (hi Angular). The actual version is 4.0.0 with one year of project.
But I support the project being depreciated.

@kasbst
Copy link

kasbst commented Jan 17, 2020 •
edited
Loading

Same here. I have all of my projects with ScopedModel.
Migration to Provider will take me a while, but I definitely support the ScopedModel to be deprecated in the future.

EDIT: But I have to add, that I totally love ScopedModel because of its simplicity. It's totally easy to use and powerful even for complex applications. I never needed to use BLoC pattern or anything different just because ScopedModel is totally sufficient!

So, I hope that migration to Provider will be pretty straight-forward as already mentioned above.

EDIT2: @brianegan It would be perfect if ScopedModel remains maintained at least until the end of 2020. That would be totally safe timeline for migration considering our workload. Thanks!!

@GrahamDi
Copy link

GrahamDi commented Jan 28, 2020 •
edited
Loading

@brianegan I am heavily dependent on scoped_model in quite a major commercial app that is about to go live so I will need a smooth transition when you deprecate the package. Will there be comprehensive documentation provided on how best to migrate to Provider?

With Flutter becoming more mainstream, there are people building stuff for the enterprise and using packages and tools provided (sorry) by clever people like yourself. However, we need to feel confident that we are not painting ourselves into a corner when we make use of packages fundamental to the apps we write.

Would appreciate your views on this.

@deandreamatias
Copy link

deandreamatias commented Jan 29, 2020 •
edited
Loading

@GrahamDi The pub.dev constantly tries to get support for yours packages, for example with Favorite Flutter or verified editors.
@brianegan is an independent developer who collaborates with the community with this package. He is not paid to give guarantees. That and other things of open source packages must be consider when choosing a package for a production app.
About provider, if you study it you can see that it is not very different from the concept of scoped model and can be easily applied.
Good luck

@ninnepinne
Copy link

@GrahamDi I recently ported a decent sized commercial app from ScopedModel to Provider.

  1. Read up on Provider.
  2. Google some examples of porting.
  3. Mostly use search and replace on your code base (yes, it is that easy).
  4. Apply optimisations/code improvements enabled by Provider (optional)

It took me approximately 2 days.
Good luck!

@deandreamatias
Copy link

deandreamatias commented Jan 29, 2020 •
edited
Loading

@GrahamDi I recently ported a decent sized commercial app from ScopedModel to Provider.

  1. Read up on Provider.
  2. Google some examples of porting.
  3. Mostly use search and replace on your code base (yes, it is that easy).
  4. Apply optimisations/code improvements enabled by Provider (optional)

It took me approximately 2 days.
Good luck!

Very nice :D
I started the same in my app but dont finish yet. In addiction try apply injection dependency with provider and other things to improve my app

@brianegan
Copy link
Owner Author

brianegan commented Jan 29, 2020 •
edited
Loading

Thanks so much for the feedback, everyone! Really appreciate the perspective from folks using this library :)

I'll plan on supporting ScopedModel for the rest of the year, and I'll look to see if I can write a codemod that will perform the upgrade from Scoped Model to ChangeNotifier / Provider automatically for you. This should make moving from Scoped Model to provider much simpler!

@GrahamDi
Copy link

@brianegan Thanks a lot. A codemod would be much appreciated :-)

@deandreamatias deandreamatias mentioned this issue Jun 22, 2020
Open
@lukepighetti
Copy link

lukepighetti commented Sep 3, 2021 •
edited
Loading

@brianegan instead of deprecating scoped_model, I would be interested in taking over the repo and pub.dev. This pattern is too powerful to let it go away, and there are even rumblings about provider being deprecated in favor of riverpod. I doubt that will happen, but I think it's important to not expect the migration path to be so clear cut in the future.

@larssn
Copy link

larssn commented Jun 30, 2022 •
edited
Loading

riverpod doesn't have scopes due to the obsession with eliminating runtime exceptions...

Anyway, this library is ultra simple, and the saying goes: "Simplicity is the ultimate sophistication". So while provider might be able to do more, you might also get more than you need with that package.

So I'd vote for keeping it alive.

@icnahom
Copy link

icnahom commented Jun 30, 2022 •
edited
Loading

Here's my shot at a "Rebirth" of ScopeModel https://github.com/icnahom/scoped_model

@GrahamDi
Copy link

GrahamDi commented Jun 30, 2022 via email

@brianegan
Copy link
Owner Author

brianegan commented Jun 30, 2022 via email

@icnahom
Copy link

icnahom commented Jun 30, 2022 •
edited
Loading

Hey Brian, it's nice hearing from you!

Do you think thay we should avoid making changes like renaming ScopedModelDescendant to the now very familiar way of naming Builders - ScopedBuilder?

@icnahom
Copy link

icnahom commented Jun 30, 2022 •
edited
Loading

Here's my shot at a "Rebirth of ScopeModel" https://github.com/icnahom/scoped_model

The new feature is ScopedContainer. The way ScopedContainer works has been in the armadillo source code. It's not that sophisticated to be considered a big feature.

@lukepighetti
Copy link

lukepighetti commented Jul 1, 2022 •
edited
Loading

it would be better to onboard you as a new maintainer if you’re interested.

My concern in becoming a maintainer of brianegan/scoped_model is that you'll be too busy to push up releases to pub.dev

@brianegan
Copy link
Owner Author

brianegan commented Jul 2, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@brianegan @lukepighetti @larssn @ninnepinne @deandreamatias @kasbst @GrahamDi @callumclift @icnahom