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

Fix using the classic block in nested contexts #16477

Merged
merged 3 commits into from Jul 9, 2019

Conversation

@youknowriad
Copy link
Contributor

commented Jul 9, 2019

At the root level, the classic block omits its delimiters in order to support posts written with alternative editors. In nested contexts though, the classic editor should be rendered with delimiters otherwise the parser won't be able to reparse the post properly.

closes #13187

Testing instructions

  • Use a classic block in a columns block
  • Save and refresh
  • Everything should work as intended.
@@ -280,9 +281,12 @@ export function serializeBlock( block ) {
* Takes a block or set of blocks and returns the serialized post content.
*
* @param {Array} blocks Block(s) to serialize.
* @param {Object} options Serialization options.

This comment has been minimized.

Copy link
@aduth

aduth Jul 9, 2019

Member

We should document these options. I think the "best" way would to define a JSDoc typedef of something like WPBlockSerializationOptions with each property described. Unfortunately docgen won't yet output these, but it seems prime for a future enhancement.

*
* @return {string} Serialized block.
*/
export function serializeBlock( block ) {
export function serializeBlock( block, { isNested = false } = {} ) {

This comment has been minimized.

Copy link
@aduth

aduth Jul 9, 2019

Member

Nit: I think we should try to consolidate our vocabulary around "inner blocks". Do we have many other references of "nested" in code? I know there's a tendency to refer to them this way in casual conversation. Is isInnerBlock reasonable as an alternative here?

switch ( blockName ) {
case getFreeformContentHandlerName():
case getUnregisteredTypeHandlerName():
switch ( true ) {

This comment has been minimized.

Copy link
@aduth

aduth Jul 9, 2019

Member

At this point, I think we'd just not want to bother with a switch and use if instead. Alternatively, we could intentionally use fallthrough to allow the nested case to fall through to default.

switch ( blockName ) {
	case getUnregisteredTypeHandlerName():
		return saveContent;

	case getFreeformContentHandlerName():
		if ( ! isNested ) {
			return saveContent;
		}

	default: {
		const blockType = getBlockType( blockName );
		const saveAttributes = getCommentAttributes( blockType, block.attributes );
		return getCommentDelimitedContent( blockName, saveAttributes, saveContent );
	}
}

It's pretty confusing though. Maybe less-so if default was just code following the switch instead of a case, but still confusing I think.

@aduth

aduth approved these changes Jul 9, 2019

Copy link
Member

left a comment

Pretty simple fix 👍

*
* @return {string} Serialized block.
*/
export function serializeBlock( block, { isNested = false } = {} ) {
export function serializeBlock( block, { isInnerBlocks = false } = {} ) {

This comment has been minimized.

Copy link
@aduth

aduth Jul 9, 2019

Member

Should be singular isInnerBlock?

Edit: Oh, I guess in the context that this is an option just passed along from serialize which is for multiple blocks, it makes sense as written, unless we wanted to rename the option as it applies to the context of the singular block being serialized. I think that comes with its own confusion. I'll leave it to you to judge, but I'm fine either way.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Jul 9, 2019

Author Contributor

I think I'd leave it as is.

@youknowriad youknowriad merged commit 403fa51 into master Jul 9, 2019

1 of 2 checks passed

Filter merged Filter merged
Details
Travis CI - Pull Request Build Passed
Details

@youknowriad youknowriad deleted the fix/class-block-nested branch Jul 9, 2019

jg314 added a commit to jg314/gutenberg that referenced this pull request Jul 19, 2019

@youknowriad youknowriad added this to the Gutenberg 6.2 milestone Jul 26, 2019

sbardian added a commit to sbardian/gutenberg that referenced this pull request Jul 29, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.