Simplify the way we create a link UI control in the offcanvas editor #46744
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 22, 2022
|
Size Change: +120 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
getdave
reviewed
Jan 3, 2023
Contributor
There was a problem hiding this comment.
Update
See my next review.
Thanks for working on this one. I started on exactly the same thing before Xmas and it seems you've hit the same bug as I did...
Screen.Capture.on.2023-01-03.at.14-00-47.mp4
Basically despite the fact that you've "committed" your changes the Link UI can reopen for the last inserted block under certain conditions.
We probably need to track the "current" item and then check whether that item has been committed. However that would require storing the data in a component that won't be unmounted, or within global application state.
| position="bottom right" | ||
| isAppender={ true } | ||
| selectBlockOnInsert={ false } | ||
| onSelectOrClose={ maybeSetInsertedBlockOnInsertion } |
Contributor
There was a problem hiding this comment.
If we get rid of this perhaps we can also revert the changes I previously made to Inserter. If and when we merge this PR I can make a followup.
packages/block-editor/src/components/off-canvas-editor/block-contents.js
Outdated
Show resolved
Hide resolved
getdave
reviewed
Jan 3, 2023
packages/block-editor/src/components/off-canvas-editor/block-contents.js
Show resolved
Hide resolved
getdave
approved these changes
Jan 3, 2023
Contributor
There was a problem hiding this comment.
I worked on the problem a little and I reasoned that the condition for showing the Link UI was based on whether the current block already has a link or not. If it doesn't then we show the UI otherwise it should remain hidden (as per trunk).
I decided to use the id attribute of the block as a proxy for the concept of "has a link value" (although we could just as easily use url) and used that to conditionalise the call to setIsLinkUIOpen(true) in the effect.
This fixes the issue and I believe we are now ready to merge.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What?
This is a small refactor as suggested in #46503, which should simplify the code that creates the LinkUI.
Why?
Simple code is easier to understand and maintain. This will also allow us to display the link UI alongside the relevant block when we are inserting a submenu at a different point in the tree (see #46582).
How?
Testing Instructions
3. Attempt to add a block using the block inserter 4. Check that the block is added correctly and that the inserter closes when you have selected a link.Testing Instructions for Keyboard
As above
Co-authored-by: Dave Smith [email protected]