-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Chat Switch timing in Grafana so it waits for all messages to layout #2684
Conversation
@@ -122,7 +125,7 @@ class ReportActionItem extends Component { | |||
{this.props.shouldDisplayNewIndicator && ( | |||
<UnreadActionIndicator /> | |||
)} | |||
<View style={getReportActionItemStyle(hovered)}> | |||
<View style={getReportActionItemStyle(hovered)} onLayout={this.props.onLayout}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nice, didn't know that View has an onLayout
prop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://reactnative.dev/docs/view#onlayout
The docs do say
This event is fired immediately once the layout has been calculated, but the new layout may not yet be reflected on the screen at the time the event is received, especially if a layout animation is in progress.
I think this is maybe as close as we can get to treating an individual chat message as "rendered". There might be a better indicator to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey I thought that as well, I don't mean to get you sidetracked but here's what I've found looking for an alternative:
viewabilityConfigCallbackPairs
List of ViewabilityConfig/onViewableItemsChanged pairs. A specific onViewableItemsChanged will be called when its corresponding ViewabilityConfig's conditions are met. See ViewabilityHelper.js for flow type and further documentation.
And in ViewabilityHelper.js
Minimum amount of time (in milliseconds) that an item must be physically viewable before the
viewability callback will be fired.
I've never used this but it seems you can configure this and wait for the callback to get called for all the items or just the first 5-10 (Thought what about when there are less than 10...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway I think onLayout
is close enough maybe 1-2 frames before the item is rendered so that like 16-32ms which is probably too little to care about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that's interesting! The docs are kind of sparse on that stuff so I'm not too sure if I'll go down this road right now. I think it will maybe be slightly more complicated to use this then to do the naive idea I had.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly because onViewableItemsChanged
is called not just when the items first appear, but when things scroll etc. And I don't want to think about it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Will keep in mind for future render timing.
All yours @MonilBhavsar |
src/CONST.js
Outdated
@@ -64,6 +64,7 @@ const CONST = { | |||
HOMEPAGE_REPORTS_LOADED: 'homepage_reports_loaded', | |||
SWITCH_REPORT: 'switch_report', | |||
COLD: 'cold', | |||
REPORT_ACTION_ITEM_LAYOUT_DEBOUNCE_TIME: 1000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAB, but is it true that a slow child component taking longer than the denounce time to render would trigger a false measurement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think if we had a child that takes more than a second to render we'd definitely get a funky measurement.
I think it's pretty unlikely for that to happen.
I came across another issue here though that I'm going to look into addressing now.
If we switch chats before thing are done rendering it's possible to get a negative value recorded so I'll look into how to prevent this before proceeding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok figured that one out and we just need to cancel the debounced method in componentWillUnmount()
so it does not incorrectly set the timer end when switching to the next chat.
So, do you think it's OK to have this... or should we perhaps increase the time?
a slow child component taking longer than the denounce time to render would trigger a false measurement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As unlikely as this is, I think it would be better to set a slightly higher debounce time -- just in case. But it's NAB. I'll leave it up to you 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna bump it to 1500
@Julesssss, the code looks good to me. |
Thanks @MonilBhavsar. Don't forget to approve the PR if you are happy with it, else the review won't count towards your total and you'll be auto-assigned more PRs for review :) Also just to let you know, NAB == 'Not A Blocker'. You might see people adding |
Yes sure, Approving it, From today only I got PR Reviews and I got a lot |
I'd like to run the test once more, but unfortunately ran out of time this afternoon. Will make this my first task tomorrow. Once that's one I'll merge. |
I'm leaving the denounce time increase up to @marcaaron, feel free to merge. |
🚀 Deployed to staging in version: 1.0.41-2🚀
|
🚀 Deployed to production in version: 1.0.44-0🚀
|
Details
While A/B testing changes to Onyx cache stuff we discovered that this test does not actually measure the time it takes to tap on a chat and see the entire contents of the chat rendered. What we were testing is the time it takes the
ReportActionsView
to mount, but it might have no chat history available to it yet.This new test will time how long it takes for all the items to render by debouncing a call passed to the
onLayout
of the view enclosing the chat content so it will record the "end" event once no one has called it after 1 second. We'll also then need to offset the timing by 1 second so that we get the true result.This will give us a better sense of when the report is "ready to view".
Note: This test has one downside at the moment which is that @kidroca has pointed out that
VirtualizedList
may be configured incorrectly and rendering many more items than necessary see issue here. Still I think it's valuable to do this test now so we can understand when a report is actually done doing it's "work" to render the UI.Fixed Issues
Fixes #2683
Tests
QA Steps
No QA
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android