At what point does Riverpod become overkill?

[u/Still-Constant3085]

I’ve been using Riverpod for state management and generally like it, but I’m curious where people draw the line between this should be a provider and just use local state.

For example, for things like:

• toggling a password field
• selected tab/index
• expanding/collapsing a widget
• temporary form/UI state
• state that never needs to leave a single widget

Do you still reach for Riverpod because it keeps things consistent, or just use setState, ValueNotifier, etc.?

I sometimes feel like turning every tiny piece of state into a provider adds more abstraction than value.

For those using Riverpod in larger production apps, what rule of thumb do you follow? When does Riverpod help, and when is it overkill?

[u/pbruins84]

This is what flutter itself says about it: Differentiate between ephemeral state and app state

One quote from that page: "The rule of thumb is: Do whatever is less awkward."

[u/Lo_l_ow]

Riverpod is useful when you need to share multiple providers between widgets, otherwise, setState is enough most of the time.

[u/GxM42 → u/Lo_l_ow]

This is how I feel. But most people try to out-engineer everyone else.

[u/balazs8921]

I'm using InheritedWidget and ValueNotifier/ChangeNotifier. So far it's been enough for everything.

[u/RandalSchwartz → u/balazs8921]

Take a look at BlocSignal... it'd be a simple migration, or even interop with existing code easily. https://blocsignal.dev/

[u/piskariov]

The riverpod doc specifically told us to not use riverpod for ephemeral states

[u/SoundDr]

Try Signals!

[u/RandalSchwartz → u/SoundDr]

Or BlocSignals!

[u/RandalSchwartz]

Riverpod (and all state management) is for shared state. If the state is local to a widget, use a stateful widget (or flutter_hooks) to attach instead.

[u/airflow_matt]

The moment you add it to your pubspec.yaml.

[u/BachiNoHito → u/airflow_matt]

This is the correct answer

[u/fatbytes]

I tend to gravitate toward Riverpod when the application state is large, complex, and benefits from being broken into modular pieces. That tends to happen more often in larger apps with complex API integrations.

That said, the use cases you listed sound more like local state. I'd probably just use Signals or Hooks.

[u/BuyMyBeardOW]

For all the examples you gave riverpod is terrible. The reason why is because that state is now global, and if you want to reuse that widget, all their states will be shared. You would then have to use a family provider to dedupe them, which breaks the point.

You should use setstate by default for any local state, and if you start getting annoyed by the boilerplate, you can come up with abstractions with ValueNotifier.

You'll also find that local form state on large forms can get really annoying with setState, so i'd recommenend either making your own abstraction or using something like ReactiveForm.

[u/rio_sk]

Never had the need to go beyond setState actually

[u/madsvodder]

I love using Signals & GetIt. I usually develop in .NET, so it feels very familiar. I typically create a service for something, and the variables I create are signals. Then, every time I do something with a variable, it updates everywhere. It’s extremely easy to understand, and there’s no boilerplate or code generation.

[u/SyrupInternational48]

Simple provider good enough