-
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
Expand block list tree on selection. #35817
Conversation
Size Change: +113 B (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
f5ed185
to
9b5e22e
Compare
9b5e22e
to
32ab7ae
Compare
Opening up for review to see if this is a decent approach. 🙇 |
Note that If I can land windowing in List View, it will also matter less if the entire component re-renders, so this isn't necessarily a hard stop on this approach. |
32ab7ae
to
5cac465
Compare
b1c28f7
to
4fb80fe
Compare
packages/block-editor/src/components/list-view/use-list-view-open-selected-item.js
Outdated
Show resolved
Hide resolved
6884770
to
bc16cda
Compare
packages/block-editor/src/components/list-view/use-list-view-open-selected-item.js
Outdated
Show resolved
Hide resolved
bc16cda
to
5869aef
Compare
I've abandoned the scrollTo logic in this PR added in 23c762a. I think it's best suited for a further iteration/exploration. There is an issue for it here: #36583 I still believe the changes in this PR represent a UX improvement. At the moment, after selecting a block in the editor, you still have to expand and find the corresponding list item. |
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.
This is looking great to me, @ramonjd, nice work figuring it out! I definitely think it's worth getting in, it's a nice little enhancement that makes the list view feel a little more natural.
I tested that it's working well in the post, site, and widget editors (that last one using TwentyTwenty classic theme).
With the limitations that you mention, the only one that I ran into (that I noticed) was toggling the list view open and closed with the same block selected results in the block no longer as showing that it's selected within the list view. Is that what you meant with the first limitation, or is there another one that I missed? Here's a quick screengrab:
Kapture.2022-02-01.at.17.36.39.mp4
I don't think that's a blocker for this PR as it's already an improvement over what's on trunk. It might be worth getting another approving review from folks who've also worked with the list view, as a confidence check just in case I'm missing additional context with the component, but it's looking good to me!
There might be a tiny bit of overlap with my WIP PR to add in multiple block selection in #38314 — but I'm happy to rebase / refactor that PR as needed once this one lands, if it gets in first 😀
1990cd7
to
4435683
Compare
Sorry to everyone that got pinged. Bad merge. Bad me. |
@andrewserong I've rebased on top of #38314. If you get time next week it'd be good if you could run your eye over things to make sure I didn't completely bork the rebase (again). |
Sure thing, thanks for updating this one @ramonjd! I'll give it a test on Monday 😀 |
Error: failed to find element matching selector ".block-editor-list-view-leaf:nth-child(2).is-selected a"
138 |
139 | // The block list should contain two leafs and the second should be selected (and be a paragraph).
> 140 | const selectedElementText = await page.$eval(
| ^
141 | '.block-editor-list-view-leaf:nth-child(2).is-selected a',
142 | ( element ) => element.innerText
143 | ); The failing e2e is very strange. In the e2e test browser, I see the old markup, before we switched to a It was passing before the last rebase on top of trunk. e2e testtrunk/ this branchSwapping the |
…t only when a block is selected outside the block list. Using an `useEffect` to loop through parent nodes, and expand them when necessary.
…ng in a new PR. Here we're calculating the top scroll position of the selected block.
…elected block *should* inform us that a block has been selected elsewhere, e.g., the editor. When we know this we can execute the hook logic that expands and scrolls to the selected element in the tree if a block is selected elsewhere. Removing hasFocus.
0c3eb7a
to
33cf482
Compare
It fixed itself :) |
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.
This is still testing nicely for me, @ramonjd! Thanks for rebasing and re-testing after the multi-select behaviour was introduced.
✅ Works well in post editor, site editor, and widget editor
✅ Multi-block selection behaviour is preserved
LGTM! Just left a tiny totally optional suggestion for a potential name change for the hook, but also fine to keep as-is if you prefer the current naming 🙂
Thank again for testing @andrewserong ! I'll let the tests run and merge this one. |
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.
Thanks for changing that! Just looks like there's a bit of lint that needs dusting 😄
packages/block-editor/src/components/list-view/use-list-view-expand-selected-item.js
Outdated
Show resolved
Hide resolved
💯 |
Description
This PR (maybe) resolves #34690
In this change, we expand the parents of nested items in the block list when the corresponding item is selected in the editor.
Oct-21-2021.21-14-34.mp4
Current limitations
Testing
Fire up the editor and insert several patterns with nested blocks, or create your own.
Example content
Open the List View tree and collapse a few nodes.
In the Editor, select an inner block. The tree should expand and reveal the nested block item.
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).