Try: Customize navigation block behavior using block context #35351
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
adamziel
requested review from
draganescu,
getdave,
kevin940726,
talldan and
tellthemachines
as code owners
adamziel
force-pushed
the
try/navigation-context
branch
from
6514f77
to
c51e06b
Compare
adamziel
added
[Block] Navigation
|
Size Change: -215 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
|
cc @gziolo and @youknowriad – I'm curious about your perspective on that. |
getdave
reviewed
Oct 7, 2021
There was a problem hiding this comment.
I've got to confess I wasn't fully aware that the block context feature existed but it makes total sense.
Based on this we can:
- Define a set of attributes on the block which configure it (and/or its child blocks) to have different behaviours (we do this already but we'll need to augment these).
- Override the attributes via context in specific circumstances where we need more control (eg: Navigation Editor).
That said, having explored Dan's PR which saves the Navigation block items (only) to a Template Part I'm wondering whether this functionality will be required.
Indeed, if - using that PR - you create a Navigation and then load the resulting template part within the Isolated Template Editor then there is no wrapping Navigation block. Therefore we don't have anything to override/config at all. It's just the raw inner blocks (e.g. core/navigation-link).
However, it might be that we still include the Navigation Block within the Navigation Editor, in which case we'll need functionality such as you propose here to configure the block.
This is how other editor screens work and it would be great to align. It removes all the need you have to tweak the block UI through the block implementation. |
@getdave @gziolo Would that mean essentially copying and pasting the code from the current navigation block into the navigation editor and maintaining the two separately? I'd rather not have two functions to keep in sync 😅 Edit: #35418 seems to address that and doesn't look bad at all. I'll take a deeper dive there. |
|
I want to second that if the block saves as a template part we'd likely not need this sort of customisation. |
I think there's an opportunity to move code out of the Nav block and into a shared space. In terms of styling having dedicated styles for the Nav Editor would free us from the specificity wars and constant battling against breaking visual style changes coming from the upstream Nav block. That's been a constant struggle and one I'd be happy to avoid with some duplication of CSS. Again, if (and it's looking increasingly likely) we pursue the saving of Navigation links into a CPT (or similar) the Navigation block will become a wrapper solely concerned with presentation (much like a Template Part). Therefore the Nav Editor screen will simply include the inner navigation link blocks with no wrapping Nav block. That will give us a "raw" view of the data onto which we can sprinkle some styling and functionality to customise the experience as required. Still subject to discovery though... |
|
I think given the changed context of what "navigation editor" means, this can be closed. @adamziel ? |
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.
Description
This is an attempt at solving #30007 by enabling contextual customization via the block context API. The advantage is that any editor may easily customize the features of the navigation block depending on the contextual needs.
Here's how this PR addresses the "Removing features" section of @getdave's comment:
✅ Remove unsupported Nav block features
I replaced the related filters with context entries.
✅ Allow only Nav blocks in inserter
I replaced the related filter with a context entry.
❌ Remove unsupported Nav block settings
At the moment, block settings such as variations or supports are not contextual. You can only change them for the entire editor, but not for a specific context or a subtree:
gutenberg/packages/blocks/src/store/selectors.js
Lines 264 to 276 in 102b944
Changing that would require reasoning about block instance, not block type.
❌ Create vertical orientation Nav block
We use attributes for now, and I think that's fine. If it will get in our way, we can easily add a context property such as
allowedOrientations: [ "vertical" ].As for the Menu name editor – a filter looks like a good fit for me because of how layout-specific this is. As for customizing nav block CSS, this is being worked on separately in #35149.
cc @talldan @tellthemachines @noisysocks @draganescu