-
Notifications
You must be signed in to change notification settings - Fork 479
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
Header: disable level switching if lab loading #51858
Header: disable level switching if lab loading #51858
Conversation
@@ -71,6 +72,10 @@ class LessonProgress extends Component { | |||
} | |||
} | |||
|
|||
if (this.props.isLabLoading !== nextProps.isLabLoading) { |
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.
can you add a comment as to why this check is needed?
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.
Does the code make sense in the context of the shouldComponentUpdate
function? Basically everything here is just checking changed props that should result in doing a re-render...
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.
I guess I'm wondering if there's ever a case where we would still want to render a change, even if the lab loading state hasn't changed. Maybe not? But worth explaining why.
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.
fwiw, we will still render a change for other props changing. This just makes sure we also render a change if the loading state changes.
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.
ah gotcha, makes sense!
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.
🎉
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.
Nice! Agreed that this is a good mitigation for now, and indeed may be the behavior we want to have long term.
To make things simpler for a lab that supports switching levels without a page reload, this is a proposal to disable switching levels using the header bubbles if a level is currently loading.
Without this change, we would have some issues with level switching initiated by pressing the header bubbles, in which we could end up with multiple requests (for level data, saved code, etc.) arriving asynchronously and potentially out of order. The solution would be to wait for the right set of responses to arrive for the last-selected level, and might also involve waiting for all in-flight requests to be completed before settling on a level to show, and would be non-trivial to get right.