-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Augment and improve Nav Editor (and block) documentation #31891
Conversation
Size Change: 0 B Total Size: 1.62 MB ℹ️ View Unchanged
|
@Mamaduka Is there any chance you'd be able to help document the If not then should we consider removing this section? Does it provide any value? |
@noisysocks I'd really appreciate a review of the part regarding the two "Modes". I noticed you wrote the original functionality that allowed for block based rendering/saving. |
@talldan @gwwar @draganescu If you have time I'd really appreciate your experienced 👀 on this one. |
I was just looking into that section. 😄 #23033 removed currently documented hooks. I think we can document I will work on the doc update tomorrow. |
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 updating documentation @getdave. I'll defer to feedback from others working on the Navigation Editor, but I think changes look reasonable to me.
|
||
#### Object Types | ||
|
||
- Menu Item objects which represent "Tags" are stored in WordPress as `post_tag` but the block expects their `type` attribute to be `tag` (omiting the `post_` suffix). This inconsistency is accounted for in [the mapping utilities methods](https://github.com/WordPress/gutenberg/blob/7fcd57c9a62c232899e287f6d96416477d810d5e/packages/edit-navigation/src/store/utils.js#L279-L281). |
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.
As an aside, I think we can still change this to prefer post_tag
before the navigation block is finalized. (We'd still need to account for older data that has tag
though).
|
||
By default, `core/navigation-link` items are serialized and persisted as `nav_menu_item` posts. No serialized block HTML is stored for these standard link blocks. | ||
|
||
_Non_-link navigation items however, are [persisted as `nav_menu_items` with a special `type` of `block`](https://github.com/WordPress/gutenberg/blob/7fcd57c9a62c232899e287f6d96416477d810d5e/packages/edit-navigation/src/store/utils.js#L159-L166). These items have an [_additional_ `content` field which is used to store the serialized block markup](https://github.com/WordPress/gutenberg/blob/7fcd57c9a62c232899e287f6d96416477d810d5e/lib/navigation.php#L71-L101). |
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.
Non-blocking note: I think this is useful to walk through, along with the table below, but I also wanted to note that docs here are pretty likely to get out of sync over time. Probably not worth automating, until things are more finalized for navigation but just something to keep in mind 🤔
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.
One other thing that might help might be some sort of diagram/table of the backing stores, rather than pointing to the conversion code.
39d74ed
to
b7441f4
Compare
@Mamaduka @talldan I've left this a few days to see if you or anyone else had any additional feedback or points you wanted to include. I'll leave it over the weekend and Monday. If not I'll go ahead merge and additional updates can be done in follow ups. |
Sounds good. I'll update hook documentation in follow-up PR. |
Description
Since the
README
for the Navigation Editor was created it has evolved significantly.This an effort to provide high level documentation of its behaviour (and the decisions that have guided us), in the hope that we can transfer the project's domain knowledge into written form (and out of contributors' heads!).
If there is any information missing that you feel ought to be documented here please say and I will investigate and write it.
How has this been tested?
Reading words. Comparing against implementation.
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.js
files for terms that need renaming or removal).