Question about intended ChatController responsibilities (local vs remote persistence)

[lhengl]

Hi Guys,

First of all, great package. Very customisable and very well performant.

I’m trying to better understand the intended purpose of ChatController in flutter_chat_ui.

From the docs and examples, it looks like the controller is designed primarily for local persistence / local state management (e.g. InMemoryChatController, Hive example). However, I’m struggling to understand how this is meant to work with remote backends.

Specifically:
The pagination examples (e.g. pagination_older.dart) use insertAll() to hydrate older messages when onEndReached is triggered. This implies insertAll() is used for UI hydration, not for syncing data to a backend.

If a custom controller were to persist remotely inside insertAll(), this would re-write messages that were just fetched from the backend, which seems incorrect.

So my questions are:

1. Is the intended use of ChatController mainly for local persistence / caching, not direct remote sync? If so perhaps the doc can be a bit clearer.
2. Should remote persistence only occur on user-initiated actions (e.g. onSendPressed), while insertAll() / pagination are meant purely for local state hydration?
3. For multi-session chats (chatId / room based), is the expectation that session management lives outside the controller?

I’d appreciate clarification on the intended architecture here — especially for apps using remote backends (Firebase, Supabase, etc). Perhaps an example? I can't find any backend examples.

Thanks!

[leeyisoft]

My understanding is that "work with remote backends" is something beyond the responsibilities of the flutter_chat_ui and needs to be implemented by the respective apps

[demchenkoalex]

Sorry about the lack of a BE example - I was working on a guide for Firebase but never finished it 😭

1. ChatController is basically a messages management solution (not persistence or caching, though it can handle that, as you saw with the Hive example). In v1, I'd just accept an array of messages, but that had some downsides. For instance, if someone added a message, I'd have to calculate the diff between the two arrays to run an insert animation for the one I identified. With the controller, you can just say "insert," and I can directly animate the known message. There's still a set method that does the diff calculation, but dedicated functions like this are way faster. The controller has nothing to do with the BE - it's just for managing messages. That said, you could maybe build one with sync built in, like a FirebaseController - though I'd need to test it with a PoC myself. Even without sync, the BE side stays totally separate. In the repo, there's an example with a small personal BE where you can see how I listen to WS messages and insert them into the chat when they arrive. https://github.com/flyerhq/flutter_chat_ui/blob/main/examples/flyer_chat/lib/api/api.dart. Handling ordering or offline-first stuff is up to the package user.
2. insertAll is just one of the methods on the controller - you could loop through insert calls if you prefer. When you send a message, you can send a POST to your BE and then call insert on success. Or go with an optimistic update: insert the message, set its status to "sending" (which shows a loading indicator), and update the status later when the BE responds. Only that message gets rebuilt when you call update on the controller. For pagination, on onEndReached, call your BE to fetch the next batch (and await it), then use insertAll on the controller to add them to the chat.
3. Yes, the controller is just for inserting, removing, updating etc messages in a single chat.

Hope that helps.

[lhengl]

Thanks for the clarification — that helped.

It’s clear now that ChatController is intended to manage UI message state (insert/update/remove) rather than act as a backend abstraction.

My main concern is semantic stability over time. For example, if pagination or hydration logic were ever moved into the package internals and relied on insertAll() to hydrate (as per the example given). A backend-synced controller could unintentionally trigger remote writes for already-fetched data.

One possible improvement for long-term clarity would be to explicitly separate mutation vs hydration at the API level, for example by introducing something like a loadMore() method for pagination/hydration, while keeping insert / insertAll semantically aligned with new message creation. That would make it safer for advanced use cases and custom controllers.

Given that backend-synced controllers aren’t a defined pattern yet, I’ll hold off on that approach until there’s a reference PoC or clearer guidance.

Thanks again.

[demchenkoalex]

just to clarify - insertAll should never be used for hydration. when you init the controller you can provide initial array of messages - this is how I hydrate in my api example as well. If it's async, you should fetch latest messages first, then initialise the chat/controller, and if it is a local database (or cache) it will be sync, without any navigation delay.

[lhengl]

just to clarify - insertAll should never be used for hydration. when you init the controller you can provide initial array of messages - this is how I hydrate in my api example as well. If it's async, you should fetch latest messages first, then initialise the chat/controller, and if it is a local database (or cache) it will be sync, without any navigation delay.

You're right I wasn' clear, there are 2 ways to hydrate, initial hydration, and pagination of older messages (hydrating the list as your scroll up). I'm referring to hydration during pagination. In your pagination example, you used insertAll to hydrate older messages that are not yet synced to the controller.