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

Standardize on children value as array (step 1) #689

Closed
wants to merge 3 commits into from

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 youknowriad and ellatrix 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.

2 participants