GetStream
Add support for LegendList in MessageList
Motivation While the library already allows swapping out the list component, LegendList handles list inversion differently, which makes it incompatible out of the box for chat UIs. Proper support would require internal adjustments, especially around how inverted lists are handled (e.g. scroll anchoring, loading more messages, maintaining scroll position).
I’ve tested LegendList with a chat view and the performance improvement is significant — smoother scrolling and much lower render times on large message lists.
Suggestion: Provide a wrapper or internal integration that handles LegendList’s inversion model and maps the expected props accordingly. Even basic support would unlock better performance for many apps.
@isekovanic @khushal87 do you expect to support it in the near future? Would be really great to get the most optimized list available for the GetStream chat.
Hey @arekkubaczkowski, we totally value your feedback on this thing. We don't have this in immediate plan but I will put forward the request to the team and let you know i there's something that can be done around it.
@khushal87 Hi, any updates on this by chance? We’re still struggling with performance issues in the current MessageList component and are desperately looking for ways to optimize it.
Hey @arekkubaczkowski, we have working on a new MessageList(MessageFlashList) using the FlashList V2 which seemingly consumes less memory and is better from the Flatlist atleast on our initial runs. Keep in mind, this will come as a experimental release for you to try out and point any obvious bugs if you find any. We will share it with you soon. We are working on fixing some of the obvious bugs that are noticeable as of now. 😄
Hi @arekkubaczkowski !
Sorry for the relatively late reply here. We've spent the better part of the last 2 quarters chipping away at performance issues for our MessageList component; and as you can probably imagine that process is very slow and painful (especially when having to introduce breaking changes).
After quite a bit of work, we're finally ready to introduce a FlashList variant of our MessageList, as Khushal already mentioned.
This is still an experimental feature and you may read a bit more about it here.
It is still a bit rough around the edges in certain scenarios (i.e scrolling to a specific message in some cases, replacing data inline etc.) however we are surely going to iterate over this as time goes on. A few months ago we had a go at both LegendList and FlashList and decided to stick with FlashList for the time being as it felt to be a bit more ahead (especially in v2.0 and onwards), especially in the context of using it in an SDK where you can absolutely bet that every single edge case that can happen will happen.
We would be very very happy to hear your feedback here for anything you might find and we'll be working on the couple of outstanding issues we know of further in the coming months.
Additionally, today I released a version that includes 2 new props to the default MessageList that you might find useful if you're using the SDK for livestreaming (or well, a high traffic of messages anyway - livestreaming is the best example for that but surely not the only one). Those would be this one and this one. If you indeed have such a use-case and are interested, please let me know here and I'll be happy to dive into the technical specifics.
Also, last but not least - please keep in mind that none of these things will act as silver bullets to fix performance overnight. We'll however continue working on it as we have in the last bunch of months and more improvements will arrive gradually. Deep re-architectures are never as seamless as they might look. Thanks for understanding and being patient !
I'll keep this issue open as a platform to provide your feedback to for FlashList related stuff.
All of these changes are available since version 8.6.2.
@isekovanic thanks for sharing this! I’ve already given it a try, and it seems to work smoothly and as expected. However, I noticed that the maximumMessageLimit prop doesn’t seem to have any effect. What behavior should I actually expect here? Should it limit the number of messages loaded to the specified value, or allow loading more by scrolling up? At the moment, I don’t see any difference - it still loads the entire chat.
Hey @arekkubaczkowski !
I would suggest not using maximumMessageLimit with FlashList at all, since it's both not really needed (FlashList handles references towards the native views differently) and pretty harmful for the MVCP aspect of FlashList. I've yet to explore this and debug specifically, but it might be fixed in the future when we have some more time to dedicate here.
The prop is supposed to simply prune the underlying MessageList if one of these two statements is true:
- We are not near the top
- We have more messages than the set limit (i.e if it's 100 the number of messages should never go above this and older messages will be pruned)
It's important to note (and possibly good feedback for our docs) that pruning will not happen until the next message arrives, as this was designed to cater to livestreaming setups where messages arrive like crazy. Are you not seeing this happen ?
@isekovanic well, I tried for both FlatList and FlashList and it always loads all the messages regardless of the limit
Hmm, that's interesting - I just tried it out with a limit of 100 and it worked fine. Could you show me how you pass it on your screen ?
And also how you're testing ?