-
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
Extract navigation link rendering code from the navigation block #21075
Conversation
Size Change: +182 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
This is gonna sound a bit weird, but I forgot why is navigation-link a block? The same goes for column. These feel more like components inside their parent blocks since once can't use them by themselves anyway. Also this Server Side Rendering Parent Attributes Context should help with colors and fonts set on the Navigation block, right? |
@draganescu Yes, that looks like it'd be helpful.
For column, that's needed because columns are multi dimenional, but inner blocks only has a single dimension. Using two nested inner blocks is/was the solution for that. For navigation link, I suppose that could be implemented without using inner blocks, but that seems like it's going against the grain. The block would have to re-implement appending, moving, duplicating etc. |
Indeed, we need column and nav-item to be able to use the innerBlocks api but they look a lot like private components of the "real" blocks, columns and navigation. Perhaps a more complex innerBlocks API could allow us to use arbitrary components too (since they're all react components) not only blocks and hence not pollute the library with private components disguised as blocks. |
3272099
to
c2d2a8a
Compare
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 good! I left some questions and relatively minor comments.
This breaking the ability to set a background colour is a bummer. Is #19572 close to being merged? It's probably worth waiting for that or to help push it forward.
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 tested this and it behaves very nicely. My opinion is that we should merge this asap as it brings refactoring to the whole block. Considering all the work going on with this block maintaining the PR will be very hard.
We can fix the background color for nested menu items later.
Also most of @noisysocks 's comments to navigation-item/index.php
also apply to navigation/index.php
.
#19685 will bring the needed updates and then many of the issues still present here will be fixed properly, but the base will be covered by how the Navigation
block works.
6da847b
to
e0bb9f8
Compare
@noisysocks I've addressed the code review comments. I've avoided making code quality improvements though, as most of the code was only moved and the issues already exist in I'm happy to bring those in a follow-up PR though, I think that'd make the git history cleaner to follow and would avoid making this PR more complicated than it already is. I'm with Andrei in that I think it'd be good to merge sooner, but I do also feel like #19685 might not be straightforward. |
I'm concerned that we don't have an approach in mind for how to fix background colours that doesn't involve #19685 which might not eventuate into anything. Any ideas? |
63b7312
to
9b1231c
Compare
Is this one is ready for testing/review after the recent changes? |
Move code around with TODOs where needed Migrate away from block.json Filter out empty blocks Minor tweaks Add navigation link to core dynamic block types Temporarily comment out code in nav-link block that is coupled to nav block Minor fixes Actually render the inner blocks This is probably fine Render nav link inner blocks in a <ul> Make the Show Submenu Icon feature work using CSS Ensure default attributes work correctly on nav and nav link blocks Fix has-submenu-icon classname application in render function Make color styles inherit Move navigation link styles to the navigation link style.scss Fix & being used in base level style Remove TODO that has now been TODONE Fix PHP linting Update navigation link snapshot test Fix PHP doc block comments Co-Authored-By: Robert Anderson <robert@noisysocks.com>
c44169b
to
fbc0695
Compare
It is now! ✌️ I've rebased it, addressed remaining comments, and did some side-by-side testing and fixing against |
👍 I gave this a good test, and as far as I can tell all the features of the block are still working. This change improves the code quite a bit. Removing the render block filters and bringing the rendering under the responsibility of the navigation link will be important for the code quality as the blocks continue to be developed. I'm unable to approve as I'm the PR author, but I think given we've both peer reviewed one another's changes we should merge this. |
Asynchronous pair programming FTW! 🤩 |
Description
Fixes #20178. Makes the Navigation Link block dynamic and relocates much of the rendering to this block.
For this PR, I've had to change how some features work:
display: none;
style when turned off. Previously they weren't rendered at all.All of the above points could be resolved/improved by pushing forward the proposal in #19685.
Server side rendered blocks could declare a context for child blocks, which would allow passing attributes to child Navigation Link blocks, and the rendering could work much as it did before.
How has this been tested?
Screenshots
Types of changes
Code quality improvement
Checklist: