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)
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).
Flutter state management always seemed clunky and complicated to me. With the caveat I'm developing small projects in it that tend not to need complicated state management functionality.
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.
I wonder why Flutter didn't gain traction in US. It seems to be more or less popular in poor countries and even less in Europe. But in US it seems to be quite a no name. Why US is so JavaScript-centric?
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.
In a similar trend, in many big American companies you can often find that in US they list front-end, full-stack and other similar js positions while e.g. C++ positions are "offshored" to the teams e.g. in India.
Let's be clear. This post describes an architecture that is offline-first, not local-first.
One of the main goals of local-first is so that the user of a local-first application owns their own data. (See Martin Kleppmann's paper on this).
As such, local-first applications don't necessarily have a concept of a central server. `git` is local-first, though most teams synchronize to a hub such as Github or Gitlab. This is a design principle to get away from having to sync to the cloud, making it more difficult to monetize as a SAAS. There seems to be a growing trend of people promoting offline-first applications as local-first, but structuring it to still lock people's data into their SAAS. (If you want to lock them in, then say so -- call it offline-first).
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
> 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.
> Are there any popular cross platform apps that actually do this? Genuine question, I don't know of any.
I don't know any, either. I doubt there will be any made. I have not figured out how and why anyone would be incentivized to write something like that, other than a foundation whose mission is to develop something like that.
I read Kleppman's paper again and realized that my idea of "local-first" is more strict than his.
When I think of "local-first", I am thinking of what permaculture design does for an ecosystem. Agency and being able to own your own data is essential.
Looking at it again, I can see why people disagree with me on what "local-first is".
On the other hand, based on Kleppman's formulation of local-first principles, I can see why those design principles degenerate into what it is now. You're still ultimately serving the needs of the business to operate as an ongoing concern, and as such, you still have to find some way to lock-in end-user data.
In order for the software to be useful even without the originating company, those software has to be able to collaborate with other users using that data. Otherwise, the only people who can make use of the local data are people with the skill to take the data apart and use it for something else. That does not really serve the needs of the end-user.
As an example of the difference, in Kleppman's paper, his formulation of local-first calls Github as local-first. With how I am thinking about it, while git itself is local-first, Github is not. The features Github makes to bring users back are the very features that are not local-first or even with a sync engine -- issues, wiki, Actions, repo search, to name a few.
Gitlab's use of ActivityPub for those things are moving towards being able to do that, but ActivityPub itself is designed as a client-server and server-to-server architecture.
To imagine a "local-first" Github ... I would imagine a hackathon where several people create a software forge with a git repo ad-hoc with bluetooth or some other short range discovery. At the end of the hackathon, maybe they sync with Github. Maybe they don't.
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.
As a newer user of Flutter I found Riverpod to be extremely heavy and have a lot more mental overhead than using stateless widgets with Hooks.
Any particular reason you personally prefer Riverpod?
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.
Great summary, it does indeed! Thanks for taking the time to reply
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).
That's the beauty of diversity. You can use whatever resonates with you best and still make it work on the app side.
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...
Yes it does, and I specifically outlined that in my other article: https://dinkomarinac.dev/riverpod-simplified-lessons-learned...
His question was directed towards the state management, hence the answer only covered that.
Check MobX, that's what I ended up using.
I replied to this 3 days ago even though it looks like hours ago now. Either way I've another question, that's similar.
If this is a local first app, why not use the sqlite database itself for state management? Powersync themselves talk about it here:
https://www.powersync.com/blog/how-local-first-simplifies-fl...
Flutter state management always seemed clunky and complicated to me. With the caveat I'm developing small projects in it that tend not to need complicated state management functionality.
(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...
I wonder why Flutter didn't gain traction in US. It seems to be more or less popular in poor countries and even less in Europe. But in US it seems to be quite a no name. Why US is so JavaScript-centric?
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.
Anecdotaly I've found this to be true. The cause is probably multifaceted. Some things I noticed:
- npm is legit slower in these countries
- Flutter's easy and stable toolchain and great cross-platform support counts a lot more in countries with less specialization
- lower on-disk footprint because no node_modules black hole, actually matters in countries without infinity disk size
- smaller app bundles mean less mobile data
Just some anecdotal observations, there are probably other factors too like inertia
In a similar trend, in many big American companies you can often find that in US they list front-end, full-stack and other similar js positions while e.g. C++ positions are "offshored" to the teams e.g. in India.
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
Let's be clear. This post describes an architecture that is offline-first, not local-first.
One of the main goals of local-first is so that the user of a local-first application owns their own data. (See Martin Kleppmann's paper on this).
As such, local-first applications don't necessarily have a concept of a central server. `git` is local-first, though most teams synchronize to a hub such as Github or Gitlab. This is a design principle to get away from having to sync to the cloud, making it more difficult to monetize as a SAAS. There seems to be a growing trend of people promoting offline-first applications as local-first, but structuring it to still lock people's data into their SAAS. (If you want to lock them in, then say so -- call it offline-first).
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
See:
- https://martin.kleppmann.com/papers/local-first.pdf
- https://www.inkandswitch.com/essay/local-first/ (Same, but in html)
> 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.
> Are there any popular cross platform apps that actually do this? Genuine question, I don't know of any.
I don't know any, either. I doubt there will be any made. I have not figured out how and why anyone would be incentivized to write something like that, other than a foundation whose mission is to develop something like that.
I read Kleppman's paper again and realized that my idea of "local-first" is more strict than his.
When I think of "local-first", I am thinking of what permaculture design does for an ecosystem. Agency and being able to own your own data is essential.
Looking at it again, I can see why people disagree with me on what "local-first is".
On the other hand, based on Kleppman's formulation of local-first principles, I can see why those design principles degenerate into what it is now. You're still ultimately serving the needs of the business to operate as an ongoing concern, and as such, you still have to find some way to lock-in end-user data.
In order for the software to be useful even without the originating company, those software has to be able to collaborate with other users using that data. Otherwise, the only people who can make use of the local data are people with the skill to take the data apart and use it for something else. That does not really serve the needs of the end-user.
As an example of the difference, in Kleppman's paper, his formulation of local-first calls Github as local-first. With how I am thinking about it, while git itself is local-first, Github is not. The features Github makes to bring users back are the very features that are not local-first or even with a sync engine -- issues, wiki, Actions, repo search, to name a few.
Gitlab's use of ActivityPub for those things are moving towards being able to do that, but ActivityPub itself is designed as a client-server and server-to-server architecture.
To imagine a "local-first" Github ... I would imagine a hackathon where several people create a software forge with a git repo ad-hoc with bluetooth or some other short range discovery. At the end of the hackathon, maybe they sync with Github. Maybe they don't.
Would this work with Flutter Web as well?
Yes
Flutter Web used to be pretty slow but I note that it has improved substantially in the last 2 years.
Why not just use sqlite instead of drift?
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.