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

Try refactoring the reusable blocks to use a separate block editor #14367

Merged
merged 14 commits into from Sep 10, 2019

Conversation

@youknowriad
Copy link
Contributor

commented Mar 11, 2019

Closes #7119
Closes #12272
Closes #12596
Closes #15087
Closes #15979
Closes #16427
Closes #16808
Closes #17370

This is the third attempt (and hopefully the last one) to use an embeddable editor to edit the reusable blocks.

Todo

  • Extract the parent registry support to its own PR #14369
  • Extract the withRegistry HoC to its own PR #14370
  • Support reusable blocks without inner Blocks or with multiple inner blocks
  • Support the block inspector
  • Remove the useless core/template block.
  • Tests
onChange={ this.setBlocks }
onInput={ this.setBlocks }
>
<BlockList />

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 11, 2019

Author Contributor

Support for the inspector sidebar is missing.

return false;
}

const referencedBlockName = getBlockName( state, reusableBlock.clientId );

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 12, 2019

Author Contributor

Since a reusable block can have contain blocks, no blocks or a single block, I don't think it makes sense to validate if the content is "includable" in the inserter, we should only validate if core/block is allowed.

This was inconsistent before because of the core/template trick we had.

This comment has been minimized.

Copy link
@aduth

aduth Mar 19, 2019

Member

Out of curiosity, is it something which could be extracted to its own pull request, if you're suggesting it ought not have been implemented this way in the first place?

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 19, 2019

Author Contributor

No, I don't think it can because right now the reusable block edit function uses this parsed block with BlockEdit component to render it and update. It's very much tied to the way the reusable blocks are edited today as part of the global editor.

@aduth

This comment has been minimized.

Copy link
Member

commented Mar 18, 2019

In thinking about this by my related comment at #14491 (comment) , I might have thought that the purpose of editor as a module would align quite well to what the implementation of the reusable block should be: coordinating an underlying block editor as being sourced from and saved to a backing post, where the post happens to be of type wp_block. Was this considered? I note here that the implementation renders BlockEditorProvider directly.

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

commented Mar 19, 2019

Was this considered?

No I didn't consider this but I can see how it could make sense. I feel that using BlockEditor instead can be more flexible/simple but that's just a guess.

@@ -17,11 +17,15 @@ import controls from './controls';
*/
const MODULE_KEY = 'core/block-editor';

const store = registerStore( MODULE_KEY, {
export const storeConfig = {

This comment has been minimized.

Copy link
@aduth

aduth Mar 19, 2019

Member

An alternative here to exposing all the implementation details (which, on the surface, is not exceedingly worrisome) is, as in #7453, exposing a createStore which registers the store given a registry (and I suppose some optional options object for the default case in applying the persist option).

https://github.com/WordPress/gutenberg/pull/7453/files#diff-adc2d694b934c0d37f4ae99f4595afc8L26

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 19, 2019

Author Contributor

My ideal API is this:

const store1Config = {};
const store2Config = {};
const store1 = createStore( store1Config );
const store2 = createStore( store2Config );
const registry = createRegistry( [ store1, store2 ] );
const store3 = createStore( store2Config );
const subRegistry = createRegistry([ store1, store3 ]);

Unfortunately, this is not possible because the current createStore is dependent on the registry it's being used in. I explored whether we can completely separate the two but it's hard to do with the namespace stores.


This doesn't reply directly to your comment I guess but yeah, I feel that sharing configs is the way to go in general and registering should be part of the components mounting... The global registry makes this hard to achieve at the moment.

@aduth aduth referenced this pull request Mar 20, 2019
8 of 8 tasks complete
};
}

this.registry = createRegistry( { 'core/block-editor': storeConfig }, registry );

This comment has been minimized.

Copy link
@aduth

aduth Mar 20, 2019

Member

Working locally in a separate branch, I observe a few more issues with the cloned registry:

  • The copied store will not include the custom middlewares we apply. As I remarked at #14513, we should probably plan to do away with those middlewares altogether.
  • The copied registry will not (at least with the current implementation of parent registries) include the plugins used for the parent, so generator actions (controls plugin) will fail. It's unclear to me whether we should (a) inherit plugins from a parent registry or (b) force the implementer who creates a child registry to re-declare the plugins (i.e. include a few following this.registry.use here).

If we choose to go the "B" route in the second point, it should also be noted that we couldn't pre-load the store configuration when calling createRegistry, as the control plugin is implemented to only handle controls for a store configuration after it's been included as a plugin, not retroactively.

In other words, we'd have to implement it something like:

this.registry = createRegistry( undefined, registry );
this.registry.use( controls );
this.registry.registerStore( 'core/block-editor', storeConfig );

Aside: I think it could be a reasonable enhancement for the controls implementation to retroactively handle already-registered stores, so that this wouldn't need to be written so awkwardly. It would be fine for a future change, if desirable.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 20, 2019

Author Contributor

This just reinforces my ideas that:

  • createNamespaceStore would be better if it's independent from the registry (no need for registry argument)
  • use is not as useful as it seems and both the controls and persistence plugins should be bundled as opt-in features in the createNamespaceStore
@paaljoachim

This comment has been minimized.

Copy link

commented Aug 27, 2019

I am really looking forward to seeing this merged!
Thanks.

@youknowriad youknowriad force-pushed the try/refactor-reusable-blocks-v3 branch from 04a27ce to d83e8fd Sep 9, 2019
@youknowriad

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2019

Good catch @mapk it should be fixed now.

@senadir

This comment has been minimized.

Copy link
Contributor

commented Sep 9, 2019

this fixes #17370

@senadir
senadir approved these changes Sep 9, 2019
Copy link
Contributor

left a comment

I've manually tested this PR against each issue it indicate and it fixed each one of them, also it close other related PRs, it works fine, I cannot see any immediate problems for now, it would close some issues that makes reusable blocks actually reusable (appending, moving, previewing).
fundamentally I think we're all approving this approach, so I'm all in into merging this and seeing what could surface later

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2019

Let's try this. Thanks all.

@youknowriad youknowriad merged commit 50fb29b into master Sep 10, 2019
2 checks passed
2 checks passed
pull-request-automation
Details
Travis CI - Pull Request Build Passed
Details
@youknowriad youknowriad deleted the try/refactor-reusable-blocks-v3 branch Sep 10, 2019
@youknowriad youknowriad added this to the Gutenberg 6.5 milestone Sep 14, 2019
@talldan

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

This also seems to fix #17178 🎉

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.