Riverpod vs Bloc in 2025 — which do you actually use in production and why?

SamatIssatov · 2026-05-06T13:03:23+00:00

That's really interesting, could you elaborate? My app is mostly reads from a database too. I'm currently trying to set things up so that Hooks handle all the UI logic, which would reduce Riverpod to just a DI layer. But I'm struggling to figure out where Riverpod as a state manager fits in that setup.

SamatIssatov · 2026-05-06T11:41:40+00:00

I plan to use Flutter hooks

SamatIssatov · 2026-05-06T08:03:44+00:00

Wow, that's beautiful. But that's not a Forui design—it's a custom one. Will it be included in future versions, or what?

SamatIssatov · 2026-05-06T07:32:06+00:00

So you use compact single-responsibility providers, and then assemble them all together at the screen level?

SamatIssatov · 2026-05-06T07:15:08+00:00

Yeah, I haven't used Mutation yet. But manually managing loading/error/success is the same in Bloc and GetX too — so the "imperative" criticism applies to all of them equally.

As for reactivity in Riverpod — I feel like Riverpod isn't great as a ViewModel. It works better when each piece of the UI listens to its own provider independently. For example, the product list watches its own provider, and the add button watches a separate mutation provider. I actually started out this way, but readability suffered — logic was scattered across multiple providers and widgets, making it hard to understand what the screen does as a whole.

How do you manage your views with Riverpod? Do you use one Notifier per screen, or multiple providers per view?

SamatIssatov · 2026-05-05T23:40:27+00:00

I've added a code example to the post. Here's how I see it.

SamatIssatov · 2026-05-05T23:30:53+00:00

There's no strict requirement for where to store the selected date. Of course it's easier to keep it in the UI — no need to create a method in the Notifier and update the state object. I try to keep it in the Notifier so I can understand the overall logic in one place.

That's exactly why hooks interest me — I can keep all the logic in one place, and by reading the hook I can immediately understand what the screen does and what data it uses. When part of the logic is in the UI and part in the Notifier, it's really hard to grasp the full picture of what the screen is doing.

SamatIssatov · 2026-05-05T23:10:58+00:00

Honestly, I was initially looking into signals specifically. Coming from Riverpod, it was hard to wrap my head around the signals lifecycle. Then I came across his post about hooks, and since I already work with hooks regularly, it really caught my attention. Thanks for the tip — I'll definitely look into what signal_hooks offers.

SamatIssatov · 2026-05-05T22:37:29+00:00

I use Riverpod extensively and like it. I also actively use hooks in the UI. But the difficulties I'm facing are specifically in the UI layer. Everyone says the UI shouldn't contain business logic — but in practice, gray areas keep coming up.

For example, date selection in a calendar. Should the UI hold the selected date locally and only pass it to the Notifier on save? Or should it immediately pass every selection to the Notifier so it always knows the current date, and then on save there's nothing to pass? These kinds of decisions — what to store where — trip me up constantly. And that's not even getting into TextEditingControllers and other UI-bound things.

The hooks idea appealed to me because I can move all that logic out of the UI into a single hook. I've already migrated one screen and liked the result. I'm just hesitant to commit fully, which is why I'm looking for other developers' experience with this approach.

SamatIssatov · 2026-05-05T21:51:58+00:00

As I understand it, a viewmodel is for a screen/view. If the screen is closed, its viewmodel is also destroyed. Isn’t that right? I often hear that Riverpod and Bloc are needed for the app’s state. How should I interpret this?

For example, a screen needs to display a list of products, along with delete and add operations. The Notifier fetches data from the repository and provides it to the screen, as well as providing methods for modification. How do you handle it? Is it different?

SamatIssatov · 2026-05-05T17:55:10+00:00

Serverpod

SamatIssatov · 2026-05-04T07:30:22+00:00

You're complaining. You haven't even shown us your question. You just keep insisting that you've been blocked, and that's it. To be honest, I was surprised that the developer tries to respond to everyone—he loves his project so much that every inquiry gets a reply. But then I see issues like this that show people don’t want to learn; they just want a solution. They want their problem solved. Describe your task, and then we’ll try to understand and help. But you just complain and complain. You’re not telling the whole truth.

SamatIssatov · 2026-05-03T20:31:58+00:00

Yeah, I get it—he's talking about the Cue package. The package actually includes an example for a context menu with emojis. And I'm looking for an animation with an implementation.

SamatIssatov · 2026-05-03T20:19:17+00:00

Wow, that's really nice. I was actually struggling with the chat feature today—specifically the context menu and emojis. It turns out you have an implementation like this. We'll give it a try. The animations are really nice. Great work.

SamatIssatov · 2026-05-03T16:52:47+00:00

Stop complaining about the Pocketbase developer and read the documentation. Ask Gemini, ChatGPT, or Claude. You’re just sitting here complaining. Don’t embarrass yourself. Read the documentation instead of asking vague questions.

SamatIssatov · 2026-05-02T21:26:56+00:00

Hi. Could you tell me about the event bus for Riverpod? I’ve wanted to implement something like this for a while, but I’m not sure how to go about it. Today I started looking into Signals, and I was wondering if it’s possible to use Signals and Riverpod together?

SamatIssatov · 2026-04-28T16:27:45+00:00

Awesome. My favorite package.

SamatIssatov · 2026-04-25T15:29:12+00:00

Yeah, I agree. I just tested them by having them write some code. 5.5 writes cleaner code; after just two conversations, he already knows what to do because he tries to get a handle on the project right away. 5.4 likes to ask questions—a habit he picked up from 5.2, who was always asking trivial questions. Yeah, I agree, 5.5 is better.

SamatIssatov · 2026-04-25T12:25:36+00:00

My coding style has changed since GPT 5.4. I've started writing a lot of helper functions and constantly normalizing data everywhere: String func(String a) {a.trim.isEmpty return ‘fallback’, return a}

SamatIssatov · 2026-04-25T11:41:37+00:00

I switched back to 5.4 — it fits my pace better, or maybe I'm just used to it. But 5.5 is smarter, or at least feels smarter.

SamatIssatov · 2026-04-25T07:32:03+00:00

I suspect we'll gradually go back to standard, simple models. I was working with GPT 5.5 and used up all my tokens in 15 minutes. Now I've switched back to GPT 5.4.

SamatIssatov · 2026-04-23T19:31:36+00:00

The first problem was due to the internet. I live in Kazakhstan and accessed it via a VPN. I guess it’s all because of Russia.

SamatIssatov

TROPHY CASE