Block Bindings: Docs API reference. #66251
Conversation
cbravobernal
added
the
[Type] Developer Documentation
|
Flaky tests detected in fa3fbe5. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11597084347
|
cbravobernal
requested review from
ajitbohra,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
cbravobernal
force-pushed
the
docs/block-bindings-first-docs
branch
from
472ee5a
to
0cb8c9d
Compare
gziolo
requested review from
justintadlock,
artemiomorales and
SantosGuillamot
There was a problem hiding this comment.
I found a few typos; I'll push a commit to fix those and left a few other suggestions.
One thing: The parameter definitions throughout the document are inconsistent and repeat themselves unnecessarily. I suggest revising the definitions like in this comment using either colons (:) or hyphens (-) between the property name and its description to make these easier to read.
@cbravobernal No worries, I added back the missing bits and added a few more revisions 👍 Feel free to roll back anything you disagree with. |
| The `label` argument will override the one defined on the server if they are different. | ||
|
|
||
|
|
||
| This example will show a custom post meta date in the editor and, if it doesn't exist, it will show today's date. The user can edit the value of the date. (Caution: This example does not format the user input as a date—it's only for educational purposes.) |
There was a problem hiding this comment.
I would polish the example to show an "e2e process" of how a source should be registered, first in the server and then improved in the editor. I'm saying this because I can see we are defining a different usesContext when in most cases label and usesContext shouldn't be defined in the client.
There was a problem hiding this comment.
I added a comment (with the option to skip it). But in my humble opinion, documentation should not follow a tutorial's structure. The developer may access only to this part, skipping previous steps.
Link: 2a6bf13
| - `canUserEditValue`: `function` to determine if the user can edit the value. The user won't be able to edit by default. (optional) | ||
| - `getFieldsList`: Experimental `function` that should not be used yet by third-party developers in production, as it is subject to change and may be removed in upcoming releases. It creates a list for the block bindings UI with post meta. | ||
|
|
||
| The `label` argument will override the one defined on the server if they are different. |
There was a problem hiding this comment.
Should we move this sentence to the label property explanation?
|
This is looking great 👏 We can keep iterating on it once it is merged.
They are already documented in the code, but maybe it makes sense to include something in the docs. |
| @@ -371,6 +371,12 @@ | |||
| "markdown_source": "../docs/reference-guides/block-api/block-attributes.md", | |||
| "parent": "block-api" | |||
| }, | |||
| { | |||
| "title": "Bindings", | |||
There was a problem hiding this comment.
So great to see it exposed here ❤️
Addressed in fa3fbe5 |
What?
Initial draft for Block Bindings
Why?
Documentation is necessary.