Skip to content
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

Merged
merged 7 commits into from
May 10, 2021

Conversation

marcaaron
Copy link
Contributor

@marcaaron marcaaron commented May 4, 2021

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

  1. Switch to a chat
  2. Wait for the chat messages to load
  3. Verify the timing log eventually shows with the time it took for all chat messages to render

QA Steps

No QA

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

@marcaaron marcaaron requested a review from a team as a code owner May 4, 2021 19:15
@marcaaron marcaaron self-assigned this May 4, 2021
@MelvinBot MelvinBot requested review from MonilBhavsar and removed request for a team May 4, 2021 19:15
@marcaaron marcaaron requested a review from Julesssss May 4, 2021 19:17
@@ -122,7 +125,7 @@ class ReportActionItem extends Component {
{this.props.shouldDisplayNewIndicator && (
<UnreadActionIndicator />
)}
<View style={getReportActionItemStyle(hovered)}>
<View style={getReportActionItemStyle(hovered)} onLayout={this.props.onLayout}>
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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...)

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 😄

Julesssss
Julesssss previously approved these changes May 5, 2021
Copy link
Contributor

@Julesssss Julesssss left a 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.

@Julesssss
Copy link
Contributor

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,
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor

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 👍

Copy link
Contributor Author

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

@MonilBhavsar
Copy link
Contributor

@Julesssss, the code looks good to me.
You can merge after your conversation

@Julesssss
Copy link
Contributor

@Julesssss, the code looks good to me.
You can merge after your conversation

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 NAB if a particular comment or change request is not essential and should not block the merge.

@MonilBhavsar
Copy link
Contributor

Yes sure, Approving it, From today only I got PR Reviews and I got a lot
and NAB makes sense now

MonilBhavsar
MonilBhavsar previously approved these changes May 5, 2021
@Julesssss
Copy link
Contributor

Julesssss commented May 5, 2021

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.

@marcaaron marcaaron dismissed stale reviews from MonilBhavsar and Julesssss via 778400c May 5, 2021 20:54
Julesssss
Julesssss previously approved these changes May 6, 2021
@Julesssss
Copy link
Contributor

I'm leaving the denounce time increase up to @marcaaron, feel free to merge.

@Julesssss Julesssss merged commit 04d9caa into main May 10, 2021
@Julesssss Julesssss deleted the marcaaron-chatSwitchTest branch May 10, 2021 08:56
@OSBotify
Copy link
Contributor

🚀 Deployed to staging in version: 1.0.41-2🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to production in version: 1.0.44-0🚀

platform result
🤖 android 🤖 failure ❌
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Chat Switch timing does not accurately reflect the test we want to perform
5 participants