Try: Block API: Remove children source in favor of HTML string #5380
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Author's note: This proposal has been the source of much inner turmoil, as I struggle to come to a decision on whether this is a good thing. At the moment, I have decided not to proceed with these changes, with further explanation below, and will proceed to immediately close it upon opening, with the intention that it could serve as a base for discussion or future reference.
Closes #2750
This pull request seeks to eliminate the
children
source from the block API, favoring instead for block implementer's to sourcehtml
as a string. Thechildren
source was introduced as a means to represent the value of rich text, but is problematic for the reasons as described at #2750.The changes here provide a graceful deprecation for all blocks which rely on the
children
source to upgrade automatically to the equivalenthtml
source. This is demonstrated in not porting any of the core blocks leveragingchildren
, save for a few blocks which are naughty in their implementations, bypassing the abstraction atop React to access inner props (e.g.quote
,list
).I've come to a few conclusions in the work here:
So what next?
class
(DOM) toclassName
(JS property, React), particularly if the element is only ever serialized to a string (no DOM reconciliation of node properties)children
as anarray
type, we have the flexibility to refactor the exact shape of the tree representation laterRichText.Content
component, even if not currently necessary, since it ties us less to the value ofchildren
being a React element which can be inserted directly into a render result.