Android - Scrolling conversation is not smooth - Reported by: @parasharrajat

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open the app in a Android device
2. Navigate to a conversation that has a long history
3. Scroll the chat and try to reach the top of the convo

Expected Result:

Scrolling should be smooth.

Actual Result:

Scrolling is janky, history is not loaded at the same speed the user is scrolling creating the need to scroll several times to reach the desired message.

Workaround:

No need for workaround, the scrolling is working.

Platform:

Where is this issue occurring?

• Android

Version Number: 1.1.16-6

Reproducible in staging?: Yes
Reproducible in production?: Yes

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Screenrecorder-2021-11-25-11-38-26-925.mp4

Expensify/Expensify Issue URL:

Issue reported by: @parasharrajat
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1637820731002300

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @marcaaron (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[MelvinBot]

@marcaaron Whoops! This issue is 2 days overdue. Let's get this updated quick!

[marcaaron]

I don't quite understand this issue. Was this recently introduced as a regression? @parasharrajat does this happen if you want for the content to render? Or only when you immediately start to scroll back when opening a chat?

[marcaaron]

Would a workaround be to wait for the content to render a bit before scrolling?

[parasharrajat]

Steps:

1. Open a chat.
2. Wait for the first 50 messages(Not sure how many will render on the switch but it seems all stored) to render.
3. Scroll back in history.
4. A loader is shown.
5. wait for the loader to go away.
6. start scrolling in history to see the loaded messages.
7. Message load one by one.
8. have to scroll multiple times and wait for the messages to render. They were already loaded.

I can reproduce the same on the web as well.

[marcaaron]

Sorry, I'm confused by the premise of the issue. If I wait for messages to load then I can scroll them fine. If you don't wait for them then you can only scroll as far as however many messages have rendered. That seems normal to me, but maybe I'm not understanding what the expected behavior should be here.

[marcaaron]

Can you figure out if what you're experiencing was a regression?

[marcaaron]

Unsure if there's anything actionable here so adding a planning label for now.

[parasharrajat]

I think the actionable items could be

1. Find the issue which is causing a delay in rendering. 50 messages should render in ms. not one by one as we are using Onyx cache. (Optional)
2. Messages Loader should vanish only after messages are rendered.

[MelvinBot]

Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[MelvinBot]

Still overdue 6 days?! Let's take care of this!

[parasharrajat]

Not sure about the next steps here. @MelvinBot

[MelvinBot]

8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[MelvinBot]

12 days overdue. Walking. Toward. The. Light...

[MelvinBot]

This issue has not been updated in over 14 days. eroding to Weekly issue.

[kidroca]

The reason for loading messages one by one when you scroll up is

App/src/components/InvertedFlatList/BaseInvertedFlatList.js

Line 154 in 2b7d6d0

maxToRenderPerBatch={1}

VirtaulizedList#maxToRenderPerBatch (FlatList inherits those props)

The "virtual window" only keeps a certain count of "screens" pre-rendered. Once you get near or reach the end it starts to add more items (to the top) and remove items from the other end. A maxToRenderPerBatch={1} means it would be throttled to happen 1 at a time

This effect is observed only on 1 side of the list - the side where items are appended
In our case since it's a inverted list as we scroll to the past more items are added to the top

[kidroca]

Related ticket: #2629

Scrolling to the top of the list adds data message by message instead of a whole page

Possible improvements from changing the virtualization config:

• Chat works the same way or faster while consuming significantly less memory
• Scrolling to the past is faster

[parasharrajat]

I agree with @kidroca It'smaxToRenderPerBatch={1} I asked this question a few days back. How is this giving us a performance boost? I think batching the render will have better performance.

For better UX, we should eliminate the dead space as much as possible.
Dead space : Area which remains blank during the scroll. The view should be prepared and presented before the user reaches that scroll position.

[marcaaron]

Open to experimenting with these values to see if there are improvements for different platforms by tweaking them.

IIRC the maxToRenderPerBatch={1} gave the best looking performance for desktop/web at the time and in my opinion - but a lot of changes have been made since then so perhaps a better configuration would serve Android specifically.

[roryabraham]

Just throwing something out there – I'm currently working on switching us from FlatList to RecyclerListView for the main chat component, so I don't think now is a good time to work on optimizing the FlatList implementation we have.

[parasharrajat]

OMG, It's used by Flipkart. I can say it would be fast undoubtedly. Awesome @roryabraham. Could you please tag me on the PR? I would like to observe the development and learn.

[roryabraham]

Yeah, all my work has been local so far but I'll tag you in the PR.

[marcaaron]

Just throwing something out there – I'm currently working on switching us from FlatList to RecyclerListView for the main chat component, so I don't think now is a good time to work on optimizing the FlatList implementation we have.

Just curious, but if we only just forked react-native-web here are we going to undo that change if we succeed at switching us from FlatList to RecyclerListView? Not knowing what the progress is with the flipkart stuff it looks like FlatList optimizations are still on the table.

[kidroca]

Even if we eventually give up on the FlatList, these tweaks maxToRenderPerBatch, windowSize and updateCellsBatchingPeriod are a low hanging fruit that would be a day's work 🤞

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[MelvinBot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[melvin-bot]

@isagoico, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.