Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Reusable Blocks: Reimplement reusable block as embedded editor #7119
At the moment, fetching reusable blocks also parses their content and insert them to the
I tried simplifying the state in #7080 but it fails at dealing with the nested blocks.
The idea of the PR is to avoid having to parse the reusable blocks (content property) when loading them, and when we insert a reusable block into the editor, don’t parse it and add the parsed blocks into the editor’s state because these parsed blocks are not part of the post content but just a property of the reusable block and is already present in the state in its serialized form.
So when we insert the reusable block, its edit method is responsible of parsing the content and updating it when the user saves the reusable block’s form.
But the problem happens when we have inner blocks because the way we render the
The path forward is not clear:
Something like this was also explored for nested blocks (i.e. idea of an embedded editor) and ultimately decided against with all the complications it proved to surface.
Related: #3745 (comment)
Is there really a dependency from blocks to shared blocks? As implemented,
Seems like there's a couple things we could be doing better here, not specific to state shape:
Just thinking in terms of modules. I believe Shared blocks belong to
As considered at #14408 (comment) , when considering reusable blocks as an embedded editor, there are a few conflicts in the form of shared state between editors:
For these reasons, I reflected back on nested blocks, and how there were similar early explorations of an embedded editor, until a point where it was abandoned due to the fact that inner blocks benefit from being part of the same editor state (#3745 (comment)).
Further, I contemplated on the point that an editor still needs to have some awareness of the concept of a reusable blocks in some form, in order to enable that these blocks be presented as options in various inserters. Tangentially, I wondered whether needs to be what we consider today as reusable blocks; or instead, if it could be considered as a form of "preconfigured block" (a reusable block is just
Considering then why we want reusable blocks as an embedded editor, there's a few existing points of redundancy we aim to eliminate:
For the first point, it's a very valid reason for wanting to use EditorProvider, specifically in managing post parse/save lifecycle (not included with #14367). However, most of these operations aren't very difficult to recreate with a combination of
To the second point, I wonder if we could be doing more to remove redundancies without necessarily treating reusable block data as part of a separate editor store. For example, could we consider reusable blocks as just a container for InnerBlocks ? The problem here is that there is no inner blocks markup saved with a reusable block, to which I'd say (a) should there be, as some form of cached markup value ? and (b) could it be the responsibility of the block implementation to fetch and parse the post blocks and update itself using
There's still the other question as well: What exactly is a reusable block, from the perspective a WordPress-agnostic block editor? The
Ultimately, I think an ideal implementation would be one where the bulk of the logic was contained within a very self-sufficient block type