CODEWITHSUNDEEP
flutterprovider
buttonsrtoys
buttonsrtoys

Reputation: 2781

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?

Upvotes: 29

Views: 9350

Answers (3)

jimmont
jimmont

Reputation: 2543

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.

Upvotes: 3

Jitesh Mohite
Jitesh Mohite

Reputation: 34270

Provider.of<ProviderClass>(context, listen: false);

The Provider is one of state management mechanism which Flutter has, under the hood, Provider keeps track of the changes which are done inside the widget. It doesn't matter to Provider whether it's a Stateless widget or Stateful widget, It's gonna rebuild widget if anything gets change.

listen: false tells the Provider not to rebuild widget even if data gets modified. That means it can only re-build if the parent widget gets modified by setState() or by the ProviderClass class value gets modified.

Upvotes: 1

R&#233;mi Rousselet
R&#233;mi Rousselet

Reputation: 277697

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.

Upvotes: 34

Related Questions