Block API: Remove HTML source string normalization

[aduth]

Related: #10678 (specifically https://github.com/WordPress/gutenberg/pull/10678/files#r225838572)

This pull request seeks to remove string normalization in the block factory method, which had been added in #10678 as a tolerance to avoid issues where an undefined value would not concatenate, relevant largely in merging the RichText values of two blocks.

The argument made is that while this provides some convenience, it does so inconsistently from the behavior of any other attribute source/type, where the block developer is otherwise responsible for assuring its specific value form before operating on it.

Implementation notes:

The process here was in auditing each block using a source: 'html' for any operations which assume a string shape (like the quote merge concatenation in #10678), ensuring the default value. This does not mean a default is provided for every occurrence of source: 'html', and as such no guarantee is made for safety of concatenating attributes of source: 'html'.

Changes also include adding the missing type for HTML-sourced attributes. I expect this may be a remnant of when the attribute was of the un-typed abstracted rich-text source.

Testing instructions:

Repeat testing instructions from #10678

[ktmn]

Changes also include adding the missing type for HTML-sourced attributes. I expect this may be a remnant of when the attribute was of the un-typed abstracted rich-text source.

Does this apply for rich text values that are stored in block comments as well?

If an old block is storing the rich text value as an array in the comments (when it's not possible to take the value from the HTML via a selector due to complexity/dynamic nature of the block):

<!-- wp:custom/block {"content":["Content"]} -->
<div class="wp-block-custom-block">Content</div>
<!-- /wp:custom/block -->

and you add the type: 'string' to the attribute it will invalidate the block.

Would it be possible to add backwards compatibility code that converts the array in the comments into a string rather than remove it since it doesn't match the type?

[aduth]

I should have been clearer in the description that the missing type was only added specifically for the core blocks which had been changed to use source: 'html', and not in the broader sense of any custom registered block.

If a block is updated to use the string shape of a RichText value and changing its attribute to source: 'html', it could use a deprecated migration to upgrade to the new variation. I'm not sure what's expected so far as deprecating the array form, but I might imagine such a deprecation process might include some sort of automated migration. Certainly not within scope of what's intended to be covered her.

[jorgefilipecosta]

I did a series of block merges and evertything went well on my tests 👍 In #10678 an end 2 end tests was added so this change seems tested (manually & automatically ).

[jorgefilipecosta]

We have some docs with samples very similar to this.
https://github.com/WordPress/gutenberg/blob/master/docs/block-api/attributes.md#text

I think it may be worth it to add type: 'string', in these docs.

[aduth]

Added in 9a6276b

[ellatrix]

Sounds good to me too.