Hi, author of the article here.

Any state management approach requires you to adapt your way of thinking, whether that be BLoC, Riverpod, Redux or anything you want to use.

Rivepod gained popularity because it's really simple to pick up: create a Notifier, create a Provider for it, and observe, while some other approaches require additional boilerplate, setup, and understanding.

Your approach would work if you are only observing that state from a single widget, which might not always be the case. Additionally, assuming useState is using setState under the hood means it will rebuild the whole widget on change, while with Riverpod, you have the flexibility to wrap any part of a complex widget into a Consumer or listen to only part of the exposed state on the Notifier with .select().

To put it simply: - Notifiers are used for app state - Hooks are used for ephemeral state (local widget state)

Hope this clears it bit for you.

This was my experience as well. I have however been very happy with get_it <https://pub.dev/packages/get_it> and watch_it <https://pub.dev/packages/watch_it> though, which just totally clicked for me in terms of how it works with the state store (database).

Riverpod does a lot more than just state management - it also handles dependency injection and reactive caching.

Here’s a great guide on using Riverpod: https://codewithandrea.com/articles/flutter-state-management...

Check MobX, that's what I ended up using.

(I work at PowerSync)

This is a good point, and we definitely agree that the local sqlite database should be the source of truth for all things state management. The example here is consistent with that view because the intermediate providers and notifiers are stateless, their only role is to bundle related functionality as well as exposing database queries as typed providers (making it easier to read results in widgets because no explicit StreamBuilder is necessary).

We've recently published guides on using PowerSync with popular Flutter state management approaches [1], and we mostly agree that sync engines simplify state management to the point where intermediate layers are unecessary. Some really enjoy the structure Riverpod can provide though, and that's why we want to make sure PowerSync works well with those architectures.

[1]: https://docs.powersync.com/client-sdk-references/flutter/sta...

There are a lot more JS and Native developers compared to Flutter/Dart developers in the West. Plus fear-mongering around Google dropping development of Flutter.

Uh what? It’s extremely popular in the US? You wanna source that claim?

> poor countries

Ah yes, those fluttering countries and their fluttery ways

> A true local-first mobile app would allow me to collaborate with someone in the same room using Bluetooth, even out somewhere where I don't have wifi, cell service or Starlink

Are there any popular cross platform apps that actually do this? Genuine question, I don't know of any.

I won't speak on the author's behalf, but I think he was using the term loosely here to refer to an app that hydrates and mutates state against disk and asynchronously syncs with other users (via a sync service) in the background. Also, his post uses an architecture that connects to the devloper's own backend database (pg, mongo, etc) and not a proprietary backend-as-a-service. I don't see data lock-in here.

But yes, that is a trend. Even the conference has many talks that don't stick to the original 7 ideals. I think "sync" or "sync engine" is a more useful general purpose term that isn't bogged down by specifics.

Yes

Probably easier to ask an LLM, but here goes: drift gives you type-safe queries which lets you catch any errors at compile time instead of runtime (which is the case with sqlite). There are other benefits but that's probably the main one.

It’s still SQLite. Drift as an ORM they are using on top of SQLite.