Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Migrate AutoUpdateTime to functional component #16968
Migrate AutoUpdateTime to functional component #16968
Changes from 7 commits
303480b
6fcfd98
8a6e225
8761775
d251915
ea17bd6
81684b1
da57dbe
c58507d
64df919
4fd9db3
0ae7b9f
c3fdb16
7fa46af
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If we want this code to be equivalent to what it was before we should maybe remove all the dependencies. Since
updateCurrentTime()
after every update before. Now it only runs when the reference forupdateCurrentTime
changes (i.e.useCallback()
returns a new function because thecurrentUserLocalTime
changed).Putting it all together that would end up just looking like this:
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.
That said, what you have here might work the same - but I didn't think too much 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.
I agree that this may be an equivalent of the previous class implementation, but I believe while creating functional component we should slightly change the mindset and instead of mapping class component's functionality into functional one we should try to re-write the same functionality from scratch using new tools.
Previously the above code was called on
componentDidMount
andcomponentDidUpdate
lifecycle events - we should forget about lifecycle (not completely, just keep it in mind it exists and may have an impact on our code) and think when (on what prop/state change) this effect should be called.So in the proposed code, I would add the dependency array - maybe empty one will be enough, maybe it should depend on some props changes (excluding
currentUserLocalTime
- please see my other comment). But leaving it without the deps array at all will cause it to be called on every single re-render which should be avoided.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 actually do think we want an infinite loop here. Because for as long as the user stays on this page, we want to keep updating the clock. So I think the behavior is correct where:
Can y'all double-check me that the function makes sense now?
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 think it's kind of strange actually now that I've looked at it and taking into consideration @burczu's notes. Maybe we should use a
setInterval()
instead to run the logic once per minute?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.
We can see what @burczu thinks as well.
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 haha I see it now. Looks like it can work. Yeah I don't really have super strong feelings but think some kind of interval makes more sense than a timeout.
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.
Ach, you guys are right - using
setInterval
makes much more sense in this scenario! And i like the idea of extracting it into separate hook.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 thought about it more and while I think the separate hook works, I think I prefer the other method for two reasons:
If y'all strongly disagree with that, let me know. Otherwise, this is ready for re-review!
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.
tbh I'm fine with whatever. we kinda over-engineered it because the component is only used on the Details page. It's hard to imagine anyone is going to sit there for minutes at a time or that anyone will notice that the time is updated at the precise top of the minute.