PreviewDataFetched on every old message when a new message comes in

[flyerhq]

PreviewDataFetched on every old message when a new message comes in

[demchenkoalex]

@zahidshaikh08 my comment above should solve the issue, it is how we planned it work, it is how it works with Firebase.

We had stateful widget before and it didn't work, don't remember the problem exactly, but it was so bad we replaced it with stateless widget and came up with this callback/user stores data system.

Not an option to keep these in memory since this chat should work on thousands of messages.

[m-j-g]

@demchenkoalex haha I completely missed it! I didn't realize the strategy was to update firestore with the preview, I thought it was expected to do it on the fly (locally) each time. That clears it up for sure, makes sense.

[demchenkoalex]

Hi, thanks for asking. Flutter fully reloads visible messages when update happens, we can't do anything about it. Regarding the preview, as you can see in the example here https://github.com/flyerhq/flutter_chat_ui/blob/main/example/lib/main.dart#L148 or inside the Firebase lib https://github.com/flyerhq/flutter_firebase_chat_core/blob/main/example/lib/chat.dart#L167 you need to implement onPreviewDataFetched and update your message on backend so it contains filled previewData. In our Firebase implementation when we update something it immediately syncs so basically you have previewData set and our preview library works in a way that when previewData is set it will use it instead of trying to unwrap once again. In your case there is no sync probably, so maybe you can try to update messages on backend and locally and it should stop trying to fetch the preview with each update.

[zahidshaikh08]

Don't you think instead of making message.dart a StatelessWidget we can have a StatefulWidget which might solve this issue. Didn't tried just an OPINION, i don't know if it will work or not but we can try this.

Or if performance is not concerned we can even add AutomaticKeepAliveClientMixin to message.dart so that it will not loose its state while refreshing or building state again on new messages add or list change. Again it's just an OPINION didn't tried.