26

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?

buttonsrtoys
  • 2,359
  • 3
  • 32
  • 52

3 Answers3

30

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.

Rémi Rousselet
  • 256,336
  • 79
  • 519
  • 432
  • 1
    Thanks @Rémi Rousselet. Regarding your comment of using a StatefulWidget for animations, is that because the animation data is UI specific? So, best practice is app/business data is stored in the Provider object while UI states (that are independent of app data) are better stored in StatefulWidgets? So, if user enters $50 to transfer money in a text field that pulsates 3x after entered, the $50 is stored in Provider class and the pulsate counter is best stored in a StatefulWidget? – buttonsrtoys Dec 22 '19 at 16:22
  • @Rémi Rousselet Can you help me to understand the below statement. Provider.of(context, listen: false); What is that listen:false ? Why we have to use it and what it's purpose. Please help me – hemandroid Jun 03 '22 at 14:25
2

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.

jimmont
  • 2,304
  • 1
  • 27
  • 29
1
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.

Jitesh Mohite
  • 31,138
  • 12
  • 157
  • 147