Skip to content
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

Discussion: Block attributes initialization #865

Closed
aduth opened this issue May 22, 2017 · 1 comment
Closed

Discussion: Block attributes initialization #865

aduth opened this issue May 22, 2017 · 1 comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor.

Comments

@aduth
Copy link
Member

aduth commented May 22, 2017

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.

  1. A block's initial attributes are a combination of explicit markup parsing from hpq matchers and implicitly from values serialized into the comment demarcations. The latter is determined at time of save by comparing the current attributes of a block with those explicitly defined in its attributes. This makes it difficult to determine, at a glance, all of the attributes a block is handling.
  2. The 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 retrieved
  3. We might need a mechanism to provide static (shared reference) default values of an attribute, particularly for complex values. See Text Block: Fix updating the content of an empty text block #512, where destructured defaults in edit resulted in new references on each render, resulting in performance loss by inability to strictly compare. This pull request introduced defaultAttributes. Since then, however, Editable has been refactored to better accommodate an undefined value, so this default may not be necessary at all. Instead, we may want to push block implementers to better handle an undefined value.
  4. The 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's state 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.

@aduth aduth added [Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor. labels May 22, 2017
@youknowriad
Copy link
Contributor

I think for clarity, the attributes property should declare all the block attributes and any metadata about them. This could be a bit "verbose" sometimes because it's not always needed but I'm opting for clarity here.

attributes: {
  align: {
    source: metadata(),
    default: 'left',
    type: 'string',
    // choices: [ 'left', 'right' ],
    // description: 'Text Align'
    // showInInspector: true
  }
}

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. [Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants