Discussion: Block attributes initialization #865
Labels
[Feature] Block API
API that allows to express the block paradigm.
[Type] Question
Questions about the design or development of the editor.
Related: #714
Potentially related: #391
See blocks API documentation for current intended usage of
attributes
Thus far we've encountered a few pain points as it relates to initializing block attributes.
save
by comparing the current attributes of a block with those explicitly defined in itsattributes
. This makes it difficult to determine, at a glance, all of the attributes a block is handling.attributes
property is misleading because it is not intended as a set of values to access, but rather defines how those attributes are to be retrievededit
resulted in new references on each render, resulting in performance loss by inability to strictly compare. This pull request introduceddefaultAttributes
. Since then, however,Editable
has been refactored to better accommodate anundefined
value, so this default may not be necessary at all. Instead, we may want to push block implementers to better handle anundefined
value.attributes
property has multiple signatures in order to allow custom parsing by content string. This is rarely used and easy to overlook (see Add tweet block for embedding tweets #754 (comment))How can we simplify these use-cases to ensure that attributes are obvious to scan at a glance, and avoid confusion around how they're used? One idea that comes to mind is a
getInitialAttributes
single getter function to rule them all (drawing parallels to React'sstate
initialization), but I've not yet settled on what would be a good set of arguments to pass and source matching behavior to expect from such a function.The text was updated successfully, but these errors were encountered: