Skip to content

Conversation

@aduth
Copy link
Member

@aduth aduth commented May 5, 2017

Supersedes #640
Blocked by ellatrix/dom-react#1
Blocked by #686
Partial resolution of #688

This pull request is a step toward treating any attribute which is derived using the children matcher as guaranteed to be an array. Subsequent pull requests will expand upon this to provide default values for existing blocks and eliminate truthy tests on these values in favor of length tests only (see: #684).

Implementation notes:

I'd hoped to use this opportunity to remove the props.children property access I'd lamented about in #667, but unfortunately we can't easily structure the text block as an array of paragraphs, since we need to preserve the text alignment style assigned to the paragraph itself. So for now this remains, but I left some of the general refactoring of the heading "transform from text" I'd explored in the process.

Testing instructions:

Verify that there are no regressions in merging a text block into a heading block.
Verify that there are no regressions in merging two of the same text or heading blocks.
Verify that there are no regressions in switching types between heading, text, and quote.

* Caveat: Note that these testing instructions may be broken until blockers are resolved.

@aduth aduth added the [Feature] Block API API that allows to express the block paradigm. label May 5, 2017
@aduth aduth requested review from ellatrix and youknowriad May 5, 2017 21:07
Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry I missed this PR!

This is testing well for me. When I see this PR, I wonder why we needed the concatChildren in the first place.

@aduth
Copy link
Member Author

aduth commented May 11, 2017

This needs a bit of rebase work, and I'm discovering some problems that are also present in master, particularly around initializing new text blocks with string members, then assuming content as guaranteed to be an array of elements.

In master, try:

  1. Convert heading "A picture is worth a thousand words" to text
  2. Convert same block back to heading
  3. Observe error

https://github.com/WordPress/gutenberg/blob/ca6bd50/blocks/library/heading/index.js#L69
https://github.com/WordPress/gutenberg/blob/ca6bd50/blocks/library/heading/index.js#L42

As a solution, I'm leaning toward one of:

  • Try really hard to eliminate the props.children from the Text -> Heading transform (difficulty noted in original comment)
  • Account for both string and element types in Text -> Heading transform
  • Allow a block to specify an initialize method which is called during creation, to be used by Text block for content normalization
  • Create a different abstraction for children tree shape where we don't have to deal with inconsistencies between element objects and text as string

@aduth
Copy link
Member Author

aduth commented Jul 17, 2017

I'm going to close this as not being pursued for the moment, even some conflicting effort such as #1907. We may want to revisit in the future for consistency's sake.

Also some separate interest in avoiding transforms in general, see #878.

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants