Move Reusable Block definition from blocks module to editor module

[noisysocks]

Inspired by this comment by @youknowriad, I though I'd try moving the Reusable Block block definition from the blocks module to the editor module.

The benefit of doing this is:

• It illustrates that core/block is tightly coupled to the redux state that lives inside the editor module.
• We are able to re-use the selectors and actions defined in editor/selectors.js and editor/actions.js.

I chose editor/library as the place where these tightly coupled block definitions live so as to closely mirror blocks/library. Happy to change this though.

To test:

1. Convert a static block to a reusable block
2. Convert a reusable block to a static block
3. Edit and save a reusable block
4. Insert a reusable block
5. Preview a post with a reusable block in it

cc. @youknowriad @aduth

[youknowriad]

I actually think all the blocks should be defined outside of the "blocks" module which should contain only the "API" and the "reusable pieces" :)

What about the stylesheets? should we update the webpack config to extract the block styles properly from this new folder (separate style.scss and editor.scss same as we do in the blocks module). Though I wonder where "editor/library/block/edit-panel/style.scss" would have been loaded, it should be loaded in the editor's stylesheet but I wonder if it works because its name is "style.scss"

[noisysocks]

Though I wonder where "editor/library/block/edit-panel/style.scss" would have been loaded

We import that SCSS file into ReusableBlockEditPanel:

gutenberg/editor/library/block/edit-panel/index.js

Line 10 in f1fc7b6

import './style.scss';

And our CSS loader will pick up anything with the .scss extension:

gutenberg/webpack.config.js

Lines 124 to 130 in f1fc7b6

	{
	test: /\.s?css$/,
	exclude: [
	/blocks/,
	],
	use: mainCSSExtractTextPlugin.extract( extractConfig ),
	},

[youknowriad]

@noisysocks I guess since we do not have any "frontend" block style in the "editor" module, this would work right now but if ever we introduce some of these styles later, this would break. I'm ok leaving this for later.

[youknowriad]

maybe editor/blocks instead of editor/library. The thinking here is that "library" doesn't indicate that we're defining blocks.

This works well for me. Any thoughts @aduth @gziolo

[gziolo]

Shouldn't we treat Reusable Block as another edit mode and move the handling to <BlockListBlock /> instead? At the moment it's promoted to its own block type which nests another block type. It isn't bad itself but leads to a few subtle bugs that are getting more prominent as we move next pieces to extensibility layer.

I discovered 3 bugs when working on #4009:

1. Reusable Block doesn't get wrapper props applied so some styles don't get properly applied:
   
2. Edit as HTML doesn't work properly:
   
3. The anchor setting isn't added to the Block Settings, which means that filters weren't applied, the class name setting comes from the Reusable Block (not from the Heading block):
   

I'm not convinced what it the best solution, but it definitely needs some further thinking how to tackle it to make it easier to maintain together with other moving pieces.

[gziolo]

I actually think all the blocks should be defined outside of the "blocks" module which should contain only the "API" and the "reusable pieces" :)

This is a quite interesting idea. I'm sure they shouldn't be bootstrapped as part of importing wp.blocks. It should happen when Editor or everything else needs them to render content. Where their definition should leave is another question. I don't have a good answer to that question.

[youknowriad]

Edit as HTML doesn't work properly:

Reusable blocks should just disable the HTML support IMO

[noisysocks]

Shouldn't we treat Reusable Block as another edit mode and move the handling to <BlockListBlock /> instead?

I think this is worth exploring. I've also noticed some weird behaviour with using the keyboard to move between and edit Reusable Blocks. It might be that our approach of keeping everything compartmentalised within the core/block component is untenable.

[gziolo]

Another issue related to Reusable Blocks I stumbled upon today:

The wrapper component gets added to the recent blocks list. It isn't useful without nested block...

@youknowriad, @aduth: How do you feel about the idea of refactoring Reusable Blocks as an editor feature build upon hooks API? Let's say each block could opt out of being reusable using:

support: {
    reusable: false,
},

We would detect if the block is set as reusable using existing connect logic and wrap BlockEdit with all needed wrapper code using blocks.BlockEdit hook. We would also have to completely override save method using what the block implementation has at the moment. I guess there is more work necessary, but it would be an excellent opportunity to confirm that our extensibility API is robust enough.

[noisysocks]

Another issue related to Reusable Blocks I stumbled upon today: The wrapper component gets added to the recent blocks list. It isn't useful without nested block...

This bug was filed here: #3793

[noisysocks]

Going to close this PR for now as it's very stale. Let's revisit this later.