[HOLD] LOW: Migrate the main chat list to FlashList
HOLD on:
- Comment linking to be 100% complete
- The new architecture to be enabled (this is not a hard requirement but I have a hunch that this should wait on that too)
Problem
The main chat list is one of the most, if not the most important component in our app. If you scroll far or fast on this list, you may see frames drop. Furthermore, there are some known performance issues with this list (example). We have already migrated almost every other virtualized list in our app from FlatList to FlashList, because its performance is much better.
Solution
Let's build support for bidirectional pagination in FlashList, then enable it on the main chat list in E/App.
Triggered auto assignment to @garrettmknight (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.
I expect this to be on HOLD until sometime in February, if not later, so I'm moving this back to monthly
cc @muttmuure adding this to the New Expensify performance improvements project. I acknowledge that the problem statement is a bit of a reverse-solution but I think it's a good bet that this will provide substantial performance improvements, as FlashList is just much better for performance than FlatList. We've established that elsewhere where we've migrated to FlashList
Still on HOLD
on HOLD for comment linking
HOLD, but could come off HOLD soon. Unclear if we'll prioritize
@roryabraham we good to take this off hold? If so, where do you think it might fit in a wave, if any? I'm not 100% on the significance of this migration beyond general, better performance.
Good question. As far as I know there's no significance beyond general, better performance of chat screens.
@roryabraham, you’re absolutely right about the performance perks we’d get with FlashList—better speed, faster rendering, the whole deal. But there's a bit of a twist when it comes to the bidirectional scrolling we need. Right now, adding that feature to FlashList can lead to some choppy experiences. It might slow us down a bit to get that smoothed out.
There is a PR with the implementation of a bidirectional list, but it is a bit stale (https://github.com/Shopify/flash-list/pull/824) also would be nice to double-check this approach (https://github.com/irisjae/recyclerlistview/blob/master/README.md). This guy added something called preserveVisiblePosition, which claims to fix those choppy scrolling issues. I haven't tried it yet, but worth to try
Still on hold.
@roryabraham any idea where this fits priority wise?
I think this can come off hold now?
@roryabraham can this come of hold?
@janicduplessis is going to investigate this
I will take this :)
After first investigation of this there are 2 main things we need to implement:
- Support
onStartReached. This one is pretty simple, I already have a working prototype. - Support
maintainVisibleContentPosition(or some alternative implementation that does the same thing). I found whymaintainVisibleContentPositiondoes not work with FlashList, it has to do with the view hierarchy it creates. ThemaintainVisibleContentPositionimplementation assumesScrollView -> ContentView -> Cells, but FlashList createsScrollView -> ContentView -> AutoLayout -> Cells.
For #2 I am currently investigating the different approaches we can use to fix this.
I'm headed on parental leave. @mountiny going to reassign to you as this is part of #newdot-quality.
@janicduplessis How is this one looking? What are the next steps and ETA?
Picking up work on this this week. Will provide another update and ETA soon.
Update: I abandoned the maintainVisibleContentPosition route as it isn't really compatible with how recyclerlistview handles virtualization.
Instead I am currently looking at using a redesigned version of flash-list / recyclerlistview, the changes made are described in details here (really suggest going through it, very interesting). In summary it changes the virtualization algorithm to have first class support for keeping the visible content position.
I managed to get it working in expensify app, the main work needed was to get it working on new arch and add support for onStartReached. It seem to work really well except for a pretty big flicker when it adjusts the position of items in one case. I have some ideas on how to fix this. I am pretty optimistic that this is a great solution and will continue working in that direction.
Will post some demo and code later.
@janicduplessis how is this going?
I've been working on some other tasks, but should be good to come back on this soon.
@janicduplessis @hannojg any updates here?
@janicduplessis @hannojg same question! any updates here?
Current status update to using FlashList
We are still in the process of trying to fix maintainVisibleScrollPosition for FlashList.
FlashList is based on recyclerlistview which was not designed in a way that makes it easy to maintain scroll position.
Our current work is split between these branches:
- https://github.com/janicduplessis/Expensify-App/tree/%40janic/chat-flashlist
- https://github.com/janicduplessis/flash-list
- https://github.com/janicduplessis/recyclerlistview
To summarise:
- We are still working on adding the features to FlashList needed / fixing bugs to make it work well for expensify.
- When we have all those changes ready we'd need to make a big patch for expensify + open upstream PRs
- Given how slow the bi-directional support PR is coming along in
FlashListits questionable how fast our changes will go upstream. - It might makes more sense to add the packages as custom modules to expensify and maintain from the code on our own (to be discussed)
- Given how slow the bi-directional support PR is coming along in
Something else we'd like to discuss is trying out a new list library called legend-list. It supports maintainVisibleScrollPosition inherently, is JS only but said to be much better performing than FlatList.
It might be that his library as a "faster FlatList" alternative that already includes the features we need is a better bet than going down the road with our "custom FlashList fork". I will open a separate ticket for investigating this if you agree?
I will open a separate ticket for investigating this if you agree?
I think this is tricky as I bet there is many alternatives to explore. I think we should aim to look at the most popular and supported options.
Feel free to check it out and if its really promising, consider doing some MVP and posting a proposal, but lets try not to spend too much time on it
@hannojg @mountiny any thoughts on this one?
@hannojg @janicduplessis can you please post another update? thanks!
We haven't progressed with that task yet. Janic unfortunately become unavailable for working on this. I am currently trying to reschedule this task in our team! Will keep you posted!
Posted in #expert-contributors
We're looking for someone to take this on. @vit @Hanno Gödecke , any ideas who might be the best fit?