-
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
Question: How can we surface expected attributes of a block? #609
Labels
[Feature] Block API
API that allows to express the block paradigm.
[Feature] Blocks
Overall functionality of blocks
[Type] Question
Questions about the design or development of the editor.
Comments
aduth
added
[Feature] Block API
API that allows to express the block paradigm.
[Feature] Blocks
Overall functionality of blocks
[Type] Question
Questions about the design or development of the editor.
labels
May 2, 2017
I like the ideas here. I'd see something like this would be great: attributes: {
content: children( 'p' ).string()
style: metadata( 'style' ).int()
} |
Similarly expressive, but maybe not quite as obvious, is Lodash's attributes: {
style: flow( metadata( 'style' ), toInteger )
} |
Another alternative is a more expanded object of attribute details: attributes: {
style: {
type: 'number',
source: metadata( 'style' )
}
} |
This was referenced Apr 25, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
[Feature] Block API
API that allows to express the block paradigm.
[Feature] Blocks
Overall functionality of blocks
[Type] Question
Questions about the design or development of the editor.
Problems:
At a glance of a block's implementation, there is no easy way to know all attributes that the block uses and manipulates.
The block's
attributes
property allows an implementer to define which attributes are to be parsed from the saved markup of a post. This is not the only state that's available for a block, however, and the default behavior is such that in serializing a block, any attributes which do not have a corresponding key present in theattributes
property are assumed to be encoded into the comment demarcations.There are other issues related to this one, specifically ideas around defining an attribute as required, default values, or providing options for the block implementer to coerce an attribute value to a specific type. For the purpose of this issue, I'd like to keep this targeted at the discoverability worry.
See also:
encodeAttributes
function for granular control which has not yet been implemented)Ideas:
attributes
property are to be encoded in the comment, we could be more explicit.metadata( 'foo' )
matcher?encodedAttributes: string[]
?encodeAttributes
in the above documentation be implemented, so it's more obvious which values are encoded into the comment?The text was updated successfully, but these errors were encountered: