List View: Add a rootClientId prop #49475
Merged
Conversation
This file contains 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
scruffian
added
the
[Feature] List View
|
Size Change: +3.6 kB (0%) Total Size: 1.35 MB
ℹ️ View Unchanged
|
|
Because we can pass Also there is a |
|
Flaky tests detected in 3332b43. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4624780477
|
|
The |
scruffian
commented
Mar 30, 2023
There was a problem hiding this comment.
All of the changes in this file must be reverted before merge
There was a problem hiding this comment.
I really like this idea, and it's testing nicely for me! We might also want to update the Readme for the component, just to clarify that the list view will show all the block in the editor or all blocks in a tree based on a rootClientId, allowing interfaces for working with one part of the block tree. E.g. around here:
Not a blocker for this PR, but one issue I'm hoping to look into is with dealing with drag-and-dropping on container blocks, and being able to drop at any level of the hierarchy (this issue: #33678). When this PR lands, it's good to know that whatever logic we might introduce there needs to be aware of how many levels of hierarchy are visible within the list view, and not just check the real block hierarchy. But that sounds fine to me 👍
Were there any issues that needed to be resolved with the appender? This code change looks good to me, and I see that the rootClientId is passed down to ListViewBranch so it sounds like the appender should respect it correctly?
Consider this comment a cautious LGTM from me! 😄
Yeah you can see it working in #49417 |
|
I see what @draganescu is saying. You can get into some interesting situations with the API:
I think this is why I prefer the idea of deprecating/removing the If we want to stick with this approach though, it should be documented clearly. |
|
Makes sense, I'll deprecate blocks. I can't see a situation where we'd ever want a list of blocks that isn't derived from a parent. |
|
I have tried to deprecate the |
talldan
reviewed
Mar 31, 2023
Co-authored-by: Daniel Richards <daniel.richards@automattic.com>
andrewserong
reviewed
Apr 3, 2023
Co-authored-by: Andrew Serong <14988353+andrewserong@users.noreply.github.com>
talldan
approved these changes
Apr 5, 2023
andrewserong
approved these changes
Apr 6, 2023
bph
added
the
Needs Dev Note
What about in the Navigation in the Browse Mode sidebar where we want to display the blocks that are part of a Navigation Menu without any relationship to a Navigation block. |
|
Why do you need to remove the 'ghost'? Isn't that going to cause a lot of issues? |
|
Yeh I was just wondering whether it's worth any effort. It just stuck out to me as a bit of a hack and I thought why can't we just use an entity block editor, but it turns out it's far from simple. My main concern was coupling Navigation to requiring a Navigation block. For example, what happens if the user deregisters the block in order that they can provide their users with a custom block to handle navigation. Now a key part of the editor interface doesn't work because the block isn't there. Edge case sure, but possible nonetheless. I'm trying to work out what the block provides other than entity saving flow. |
That's a very good point 😄 Possibly the browse mode navigation menu also shouldn't be available.
I think the main things are the inner blocks settings, that require the block edit to render (allowed blocks is the main one). |
|
Ah thanks for that context. Right so basically it's critical to allow the whole thing to work 😅 I suppose the block is central so maybe it's ok? I'm not sure... I wonder whether we could make use of this "wrapper" Nav block in the preview canvas, as we will need to have a wrapper Nav block for focus mode for Navigation Menus. |
|
I think you're right that it is coupling that ideally wouldn't be there, but not an easy one to solve. The other thing that List View for browse mode needs is its own instance of a block editor store. This store will have an isolated tree of the blocks in a menu, and so the |
24 tasks
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 adds a
rootClientIdprop to the list view component, so that it can display a subset of blocks from the canvas.Why?
This functionality is required by the OffCanvasEditor. If we add it to the List View then we are one step closer to removing the OffCanvasEditor.
It's not enough just to provide
blocks, as the appender needs to know the clientId of the parent block to which it will add the new block.How?
Adds a new prop called
rootClientId.I have also added some code to force the list view to only show the contents of the first block in the canvas. This should be removed before merging, it's just here to demonstrate that it works.
Testing Instructions