-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Site Editor: Only show 'Back' button when user came from an editor canvas #58710
Site Editor: Only show 'Back' button when user came from an editor canvas #58710
Conversation
Size Change: -222 B (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
previousLocation?.params.canvas === 'edit'; | ||
const showBackButton = isFocusMode && didComeFromEditorCanvas; | ||
return showBackButton ? () => history.back() : undefined; | ||
}, [ location ] ); |
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.
Hm. When I add previousLocation
everything stops working as it seems to update too often. Maybe previousLocation
isn't a stable reference....
How much of a "rule" is this lint rule? 😀
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 see lots of // eslint-disable-next-line react-hooks/exhaustive-deps
in the code base. I think it's one of those rules that we should attempt to honour when we can, but if we can't, then it's good to add in that disable
line with a line or two with a Ignore reason
or Disable reason
with a quick explanation 🙂
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 I figured it out. usePrevious
had a flawed implementation in that it returns what value
was the previous time that the component rendered. This is different to what we want, and what I think most consumers want, which is that usePrevious
should return what value
previously was.
If the component updates for some reason unrelated to value
changing (e.g. its state changed) then we'll get the current value
instead of the previous value
.
I found this article which explains the problem and solution really well:
https://www.developerway.com/posts/implementing-advanced-use-previous-hook
I also saw that the implementation that we based our version of usePrevious
on has been changed to be similar to the approach suggested in the article above:
https://github.com/uidotdev/usehooks/blob/main/index.js#L1017
So, I updated our implementation of usePrevious
to follow. I also added a unit test since there was none. Now, when I set deps
to be exhaustive, the back button updates properly.
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.
Great catch — I think this is probably the kind of flaw that the folks who introduced that linting rule were hoping we'd uncover!
It looks like the unit tests are failing now, in particular some ToolsPanel tests, which use usePrevious
internally. If that winds up being complex to solve, since usePrevious
/ the compose package is a bit lower level than the proposed change in this PR, would it be worth splitting out the idea into two parts — 1) add in the eslint-disable-next-line
for this PR to get things working for now, and 2) open a separate PR for usePrevious
where we can debug the ToolsPanel
test, and see if there were components that expected the previous implementation?
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.
Yeah, bugger, let's do that.
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core SVNCore Committers: Use this line as a base for the props when committing in SVN:
GitHub Merge commitsIf you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
packages/edit-site/src/components/block-editor/use-site-editor-settings.js
Show resolved
Hide resolved
…of value from previous render See https://www.developerway.com/posts/implementing-advanced-use-previous-hook for a good explanation of the problem.
…instead of value from previous render" This reverts commit 8068fe3.
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.
Works nicely and the code change LGTM! ✨
Thanks for the back and forth!
What?
Follow up to #58528. In particular, addresses this comment: #58528 (comment).
In
trunk
we show the "Back" button in the site editor whenever you're in "focus mode" e.g. when looking at a template part, pattern, or editing a page's template. The back button appears even when you navigate to the current screen via the W menu.This PR changes the behaviour so that the "Back" button only appears when you navigate to to the current screen via the site editor canvas e.g. by clicking "Edit" in the toolbar of a template part.
Why?
We don't want to overuse the "Back" element. If a user navigates to a screen via the W menu then they can navigate back by clicking on W again.
How?
Track the previous location using
usePrevious
and only show the back button if the previous location is an editor canvas (canvas=edit
).Testing Instructions
Screenshots or screencast
Before:
before.mp4
After:
after.mp4