RichText: Ensure HTML can be created from serialized object

[ellatrix]

Description

We should make sure the format references are created before converting to HTML so it works correctly. This makes it possible to use the value in the HTML comments.

How has this been tested?

This blocks should work correctly:

wp.blocks.registerBlockType( 'test/test', {
    title: 'test',
    description: 'test',
    category: 'common',

    attributes: {
        content: {
            default: wp.richText.create(),
        },
    },

    edit( props ) {
        return wp.element.createElement( wp.editor.RichText, {
            value: props.attributes.content,
            onChange: ( value ) => props.setAttributes( { content: value } ),
        } );
    },

    save() {
        return null;
    },
} );

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[youknowriad]

I know normaliseFormats is performant at the moment but this is the kind of function that can hurt the editor's performance pretty quickly if we made a not-good-enough change. How can we ensure it doesn't happen? Any ideas.

(don't require an immediate answer)

[ellatrix]

That's an interesting question, but it's valid for any change within this package.

[youknowriad]

👍

[youknowriad]

Thanks for the updates Ella. Seems fine to me, I'll try to do some tests to approve.

What do you think about adding docs for the format and some higher level docs on how these toTree, toDom, create... fit together.

If we’re to support it for a long term, just make it explicit.

[ellatrix]

What do you think about adding docs for the format and some higher level docs on how these toTree, toDom, create... fit together.

Yes I definitely plan to write some documentation on this and the format in general, just haven't been able to prioritise it so far.

[youknowriad]

While testing, I noticed this being saved in the HTML

<!-- wp:test/test {"content":{"formats":[null,null,null,null,null,[{"type":"strong"}],[{"type":"strong"}],[{"type":"strong"}],[{"type":"strong"}],null,null,null,null,null,null,null,null,null,null],"text":"test test test test"}} /-->

It feels a bit weird to have a format for each character (all these nulls)

It also produces this error:

[ellatrix]

@youknowriad I fixed the problem.

Explanation:

When a value object is created, the formats are put into a sparse array, meaning that any space where there are no formats is just empty (not null or undefined, but empty). JSON does not have this concept, so JSON.stringify will create null values for the empty spaces. JSON.stringify( [ , [ format ], , ] ) would equal [ null, [ format ], null, null ].

normaliseFormats so far assumed that the array is sparse, expecting only arrays when it loops over the formats. E.g. [ , [ format ], , ].forEach() will skip the empty spaces.

When the serialised object comes back in, the empty places are null, so we have to account for them in the loop: [ null, [ format ], null, null ].forEach() will loop over the null values. So the solution is to check for the null value and delete it.

I hope this makes sense!

It feels a bit weird to have a format for each character (all these nulls)

Yes, so that's because of JSON.stringify. As I said before, this format is not meant for saving, but for manipulation, though I agree it should still work if someone does save the serialised form. For saving it is best to use HTML.

[gziolo]

Superseded by #10439.