Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Flutter Provider means no StatefulWidgets?

I'm getting ready to write my first nontrivial app with Flutter and Provider. I've read up on how Provider facilitates immutable widgets (StatelessWidgets). My question is, is it always an antipattern to use StatefulWidgets when using Provider? If not, what are examples of when it better to use StatefulWidgets in a Provider app?

EDIT

It's been a couple months using Provider and I'm still favoring it over StatefulWidgets in every case. Every now and again I introduce a StatefulWidget, mostly to try to gain familiarity with them, and almost immediately regret it and refactor to Provider. The other day I ran into widgets not refreshing because they were identical types, so was looking at introducing keys so they would refresh. First couple attempts failed, so I refactored into Provider and everything just worked (without the need for keys).

Antipattern was not the proper term in my OP. I guess my question is, are there examples where StatefulWidgets are cleaner or otherwise easier/better to use?

like image 471
buttonsrtoys Avatar asked Dec 22 '19 15:12

buttonsrtoys


People also ask

What is Flutter provider used for?

The provider package is an easy to use package which is basically a wrapper around the InheritedWidgets that makes it easier to use and manage. It provides a state management technique that is used for managing a piece of data around the app.

Should I use provider in Flutter?

One of the main reasons to prefer Provider over Statefulwidget s is that, using Provider , you will rebuild only the widgets that needs that value (the Consumers ) while the other will not be rebuilt. Instead when you call setState the whole build function of the widget will be called.

Is provider a state management Flutter?

There are plenty of options to manage your state in a Flutter app. Provider is one of the most popular state managers. This community created tool relies on three core concepts: ChangeNotifier : the store of your state from which state is updated and widgets consuming the state are notified.


2 Answers

provider doesn't care whether you write stateless/stateful or anything else (hooks?).

It removes the need to write a StatefulWidget in many situations, but it doesn't claim that you should use StatelessWidget only.

In the end, it's your job to decide if you need a StatefulWidget or not. You may need it when writing animations for example.

like image 120
Rémi Rousselet Avatar answered Sep 27 '22 22:09

Rémi Rousselet


Adding to Rémi's answer and new to this implementation:

  • use Provider for shared models
  • use widget state to manage the model that is specific to that concern when it's needed
  • imagine a user object after auth, null before, shared through an app, with a form with state specific to editing fields, like a nickname, or whatever, updating local state and possibly propagating out to the rest of the product (when finished updating on the backend?...who knows) and that state is disposed of when that view isn't needed anymore, but the user reference remains via the provider reference. It doesn't make sense to manage all that state change in the provider model--that's where the result goes.

Making a few assumptions here based on my experience with React+Redux as well as passing objects around a native Web Components (similar lifecycle to both of these) as well as LitElement. The patterns seem similar if not the same so-far.

like image 26
jimmont Avatar answered Sep 27 '22 23:09

jimmont