Several questions regarding v2 implementation (migration, ChatController interface, riverpod compatibility)

[nicolasbraun]

Hello guys,
First off thanks a lot for your awesome work! 🙏

Saddly I couldn't try the dev release of v2 so those questions might come a bit late; but looking at the new lib and the impacts on my project I came up with a few interrogations.

Note i did not try to implement my custom builder/ UI etc yet but only tried to rework a bit the current Chatcontroller I built for v1 (happy to share code, it's a bit messy though)
Also note I'm working with a firebase backend.

1. MIgration

• I first had in mind to create a Cloud Function to add to the "v1 message" the properties needed by v2 and the other way around too. Sadly the property createdAt kept the same name and changed its type , what prevents me to do so.
• The only thing I can think of (appart from a forced app update during migration) is to duplicate all messages in 2 separate collections.
  Maybe you have other ideas that could be added to the migration guide?

2. ChatController design
Looking at the ChatAnimatedList it only relies on the controller's messages and operationsStream.
Though the abstract class ChatController declares more methods (insert, update, dispose ..) ; that seem relevant if the Chat widget does some logic (like for example in your api example _addItem method but seem like an extra constraint when implementing a custom controller (my widget will only call something like controller.postMessage() and the controller will do the insert > api operation > update flow)

3. Name conflict with riverpod
This one may be relevant only because i'm a Dart newbie :)
I'm using riverpod to manage my states and provide the chatcontroller to the widget.

@riverpod
class MyChatController extends _$MyChatController
    implements ChatController

@override
  Future<void> update(
      chatcore.Message oldMessage, chatcore.Message newMessage) {
    // TODO: implement update
    throw UnimplementedError();
//==> throws "'ChatController.update' ('Future<void> Function(Message, Message)') isn't a valid override of 'AsyncNotifierBase.update' ('Future<void> Function(FutureOr<void> Function(void), {FutureOr<void> Function(Object, StackTrace)? onError})'"
  }

...

The override of update throw error because Riverpod AsyncNotifierBase(which implements ProviderElementBase) also has an update method. I can work around this one but If someone has a nice solution I'm happy to hear it.

[demchenkoalex]

Hello!

Thanks for your feedback. I definitely need to test v2 with Firebase/Supabase and Riverpod - something I couldn’t do before the release, which was already long overdue. I wasn’t able to do dev builds anymore. I’ll prioritise this next.

1. Migration

It looks like adding authorId alongside author would make base messages compatible, which is great. But I’m not sure what to do about the createdAt issue. I like the name - it fits well with other timestamps like updatedAt, sentAt, etc. Do you think I should rename all of them?

The real problem was my original decision to use int for timestamps. It turns out this doesn’t follow typical Flutter patterns, where all dates should be DateTime. I corrected this right at the start of v2. But now I’m unsure how to handle the situation.

Does Firebase allow middleware to convert data to a different type during processing? When serialising, a DateTime is still turned into an int, so the value stored in Firebase should be correct - we just don’t know how to turn it back into a DateTime I guess.

2. ChatController design

Is it okay to just throw UnimplementedError(); for methods you don’t plan to use if you only need insert? Or is there something I’m missing? I’ll try writing a Firebase example and see how it works with the controller, and whether anything needs to change to improve the integration.

3. Name conflict with Riverpod

I also haven’t tested the controller with Riverpod (and I don’t have much experience with Riverpod in general), so I wasn’t aware of that issue. Do you think I should rename update?

[nicolasbraun]

Hi Alex,

Thanks for your quick reply.

1. Migration

Does Firebase allow middleware to convert data to a different type during processing? When serialising, a DateTime is still turned into an int, so the value stored in Firebase should be correct - we just don’t know how to turn it back into a DateTime I guess

I'm not really sure what you mean and realized I mixed Date concepts myself.
The v1 (flutter_firebase_chat_core) managed the firebase sync and dates were stored as proper Timestamp(a firebase class).
Since the v2 does not manage the communication with Firebase anymore (which is great) it's my job to convert back the dates to a Timestamp using Timestamp.fromMillisecondsSinceEpoch() after converting a Message toJson() so everything should be fine.
TL;DR for a firebase backend, if you want to store the dates as Timestamp and not int you need to have a mapper no matter what so serizalizing to int or DateTime are both fine.

2. Chatcontroller

Yeah, that's what I currently do :) Just pointing that declaring those method in the ChatController abstract class, made me feel they had to be implemented because somehow the UI was relying on them. I had to check the code to confirm they were optionnal.

3. Riverpod

There are some workarounds but it might help to use more explicit method names (insertMessage, ...)
To give you a glimpse of riverpod, think of a riverpod class as a class that exposes a state. So for example for v1 my Controller was exposing the messages' stream but also if I was loading next page, uploading an image etc...
Your widgets can then watch this state and rebuild accordingly.

Maybe next week I will deep dive into my migration and can give you a little more feedback on this.

[demchenkoalex]

So based on your reply, it sounds like points 1) and 2) are solved - great news! :)

As for 3), I think I’ll go ahead and rename those methods now, while the package is still new. It seems like a good idea anyway.

Regarding the controller, we can definitely build on top of it. For example, I provide an upload_progress_mixin that you can attach to a controller. My image message implementation uses it to track upload progress.

For loading more messages, I added a callback to the list itself, since I provide two list types (reversed and not), and their pagination logic is different. But if you think we could move this to the controller somehow, I’m open to exploring that idea.

chatAnimatedListBuilder: (context, itemBuilder) {
  return ChatAnimatedList(itemBuilder: itemBuilder, onEndReached: _loadMore);
},

[demchenkoalex]

rename is published - hopefully it solves the problem 🤞 https://github.com/flyerhq/flutter_chat_ui/releases/tag/2.1.0

[nicolasbraun]

Hi @demchenkoalex

Thanks, i used a workaround but wil make a quick test to confirm.
I'll then close this thread an open new ones (or issues?) for an other encountered problem.
Nicolas

[demchenkoalex]

Yes, please do! Thanks :)

[nicolasbraun]

Just for anyone reading this I was mistaken.

The abstract methods in the ChatController are used (at least updateMessage in some optional packages like flyer_chat_image_message