Replace the renderBlockMenu prop with a Slot #7199

youknowriad · 2018-06-07T09:15:33Z

Related #7192

This PR replaces the renderBlockMenu Prop with Slot/Fill.

Testing instructions

Open the block menu and toggle the inspector (Show Block Settings)
It should work.

youknowriad · 2018-06-07T09:17:21Z

editor/components/block-settings-menu/index.js

-								count === 1 && <SharedBlockSettings key="shared-block" uid={ firstBlockUID } onToggle={ onClose } itemsRole="menuitem" />,
-								<BlockTransformations key="transformations" uids={ uids } onClick={ onClose } itemsRole="menuitem" />,
-							] } ) }
+							<PluginsBlockSettingsMenuSlot fillProps={ { onClose } } />


Questions:

This adds the menu items to the top of the list, should we add another slot after the menu items?

We don't use any prop (aside onClose) in our current usage, but I guess if we want to expose this to plugins, we'd probably need uids?

Thoughts?

This adds the menu items to the top of the list, should we add another slot after the menu items?

I don't know what is the exact use case in here, but I don't feel very good about having two slots only to have a way to pick whether we should prepend or append menu items. I'm wondering if we shouldn't rethink the way all slot operate. There are a few things we can explore. First of all, we could convert all menu items into fills to have better controls over them and:

Introduce priority prop for fills.

Add a filter for a slot which would allow reordering or modifications of fills.

...or maybe use a filter instead of Slot/Fill in the first place.

In general, there is an expectation from plugin developers to have a way to remove some of the fills that are rendered. We can provide an API for that, or find a way to guard fills with the check which allows preventing their rendering if the given condition is met.

We don't use any prop (aside onClose) in our current usage, but I guess if we want to expose this to plugins, we'd probably need uids?

count might make sense, too.

Yes, I agree it's not perfect, Slots are limited to specific positions. A priority/order support makes sense. That said, I think it's a bigger problem than what this PR is trying to solve and it concerns all the other slots.

Like you said, I think we should move on like this, for now, it's way better than the renderBlockMenu prop and address the slots flexibility in a dedicated issue/PR.

youknowriad · 2018-06-07T09:17:59Z

editor/components/block-list/block.js

@@ -86,8 +86,7 @@ export class BlockListBlock extends Component {
 	}

 	createInnerBlockList( uid ) {
-		const { renderBlockMenu } = this.props;
-		return createInnerBlockList( uid, renderBlockMenu );
+		return createInnerBlockList( uid );


I didn't want to refactor further here because it's taken care of in #7192

I didn't want to refactor further here because it's taken care of in #7192

By refactoring, do you include removal of the unused-as-of-these-changes renderBlockMenu argument of createInnerBlockList?

gziolo

In general, I like the flexibility Slot & Fill gives, but there are a few limitations I described in my detailed comment. It helps to remove renderBlockMenu from the BlockEditContext which is great. If it works exactly as before, I would proceed. @aduth should have a much better idea if it fits.

gziolo · 2018-06-07T18:49:31Z

editor/components/block-settings-menu/index.js

@@ -23,6 +23,11 @@ import BlockTransformations from './block-transformations';
 import SharedBlockSettings from './shared-block-settings';
 import UnknownConverter from './unknown-converter';

+const { Fill: PluginsBlockSettingsMenu, Slot: PluginsBlockSettingsMenuSlot } =


Nit: it should land in its own file.

This is how files with Slot/Fill look like: https://github.com/WordPress/gutenberg/blob/master/edit-post/components/sidebar/plugin-post-publish-panel/index.js.

I personally don't like the pattern of assigning the .Slot into the Fill because we don't want to expose the Slots but I'm following the pattern now, we can change that later.

It is what it is, I followed what was in code before ...

gziolo · 2018-06-07T19:06:57Z

editor/components/block-settings-menu/index.js

-								count === 1 && <SharedBlockSettings key="shared-block" uid={ firstBlockUID } onToggle={ onClose } itemsRole="menuitem" />,
-								<BlockTransformations key="transformations" uids={ uids } onClick={ onClose } itemsRole="menuitem" />,
-							] } ) }
+							<PluginsBlockSettingsMenuSlot fillProps={ { onClose } } />


This adds the menu items to the top of the list, should we add another slot after the menu items?

I don't know what is the exact use case in here, but I don't feel very good about having two slots only to have a way to pick whether we should prepend or append menu items. I'm wondering if we shouldn't rethink the way all slot operate. There are a few things we can explore. First of all, we could convert all menu items into fills to have better controls over them and:

Introduce priority prop for fills.

Add a filter for a slot which would allow reordering or modifications of fills.

...or maybe use a filter instead of Slot/Fill in the first place.

In general, there is an expectation from plugin developers to have a way to remove some of the fills that are rendered. We can provide an API for that, or find a way to guard fills with the check which allows preventing their rendering if the given condition is met.

We don't use any prop (aside onClose) in our current usage, but I guess if we want to expose this to plugins, we'd probably need uids?

count might make sense, too.

gziolo · 2018-06-11T12:19:20Z

Can you see this , (comma) in the menu?

it works properly for nested blocks

gziolo · 2018-06-11T12:21:04Z

editor/components/block-settings-menu/index.js

+							{ count === 1 && <UnknownConverter uid={ firstBlockUID } role="menuitem" /> }
+							<BlockDuplicateButton uids={ uids } rootUID={ rootUID } role="menuitem" />
+							{ count === 1 && <SharedBlockSettings uid={ firstBlockUID } onToggle={ onClose } itemsRole="menuitem" /> }
+							<BlockTransformations uids={ uids } onClick={ onClose } itemsRole="menuitem" />,


Found this , :D

gziolo · 2018-06-11T12:23:17Z

editor/components/block-settings-menu/plugin-block-settings-menu.js

+
+const { Fill: PluginBlockSettingsMenu, Slot } = createSlotFill( 'PluginsBlockSettingsMenu' );
+
+PluginBlockSettingsMenu.Slot = Slot;


We should document it somewhere. In general, we should document all Slot/Fill pairs from editor. Let's open a follow-up task.

yes, I was not sure if we wanted to document it now or wait until we figure out #7199 (comment)

gziolo

I tested it locally and it works as expected. The comma needs to be removed and it's a very good improvement.

aduth · 2018-06-11T14:14:27Z

I don't know what is the exact use case in here, but I don't feel very good about having two slots only to have a way to pick whether we should prepend or append menu items. I'm wondering if we shouldn't rethink the way all slot operate. There are a few things we can explore. First of all, we could convert all menu items into fills to have better controls over them and:

Introduce priority prop for fills.

Add a filter for a slot which would allow reordering or modifications of fills.

...or maybe use a filter instead of Slot/Fill in the first place.

While it's tempting to give developers full control over these items so far as the flexibility it provides, to me it seems like this isn't something a developer should want to be concerned with, and in its impact on opening the potential for inconsistent user experience (or even abuse), not something that has a net benefit for anyone involved.

Ultimately, what is a developer trying to do, and in what ways does order matter? For plugin developers, it seems like the mere presence in the list of options should be sufficient (though I'm open to hearing use-cases to the contrary). The complication for us here is that "Show Block Settings" is part of a core (post editor) behavior, and we do agree its sensible to be shown in a specific order (i.e. first in the list).

So how do we distinguish between:

Core behavior menu options vs. plugin extensions
- Does this distinction need to be presented in the UI for the user? (e.g. a line separator, like with "Transform into:")
- I tend to dislike special treatment of core, but this seems one area where its sensible to the user to perceive where a line is drawn.
What are the core behaviors that ought to be implemented as extensions
- All of them?
Does order matter?
- Would it be bad if "Show Block Settings" was not the first option? (Maybe yes)

Among plugin extensions proper, I personally don't think it's in the interest of anyone to introduce a concept of ordering. A single slot should be sufficient. To the user, its order in the list should be consistent (deterministic), but aside from that, I'd not care what metric is used for ordering.

For core behaviors, maybe it should be a separate slot from that of plugins, which prompts other questions:

How do avoid plugin authors from accessing it? Awkward and obvious naming akin to dangerouslySetInnerHTML / __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ? Somehow prevent it from being exposed at all?
How do assure "Show Block Settings" as the first menu item? It's odd to me that this is both an extension, but one which the editor is expected to respect as a primary item. I could imagine even a third slot for a single "critical" fill, if we'd agree that other options don't have as much importance to their specific ordering. If we do want a fixed order, then maybe your suggestion of a priority on a fill could be a valid option to explore. But toward general usage, it introduces the same concerns about what ordering a plugin ought to be concerned with (of course I think my plugin menu option should show first, so I'm going to set priority={ -Infinity }).

youknowriad · 2018-06-11T14:44:04Z

Good thoughts @aduth we're often tricked by the fact developers want to extend everything for better and for worse. And often for worse in terms of UX for the user.

What's the way forward here, should we just rename the slot something like __CoreBlockSettingsMenu?

aduth · 2018-06-11T14:52:36Z

@youknowriad There's precedent here with core PHP function naming (e.g. _set_preview).

This function’s access is marked private. This means it is not intended for use by plugin or theme developers, only in other core functions. It is listed here for completeness.

I'd prefer if it was not available at all, though I cannot think of a solution for this currently. Seems reasonable to have as a naming convention for now, and since it's intended to be private, can be open for future backwards-incompatible refactoring.

aduth · 2018-06-11T14:53:38Z

But there's still a question: Even for core behaviors, would the expected behavior of the slot be to append or prepend? Do we need to reflect this in the name of the slot? Something like _BlockSettingsMenuFirstItem ? 🤷‍♂️

youknowriad · 2018-06-11T14:56:03Z

I think _BlockSettingsMenuPrepend is more accurate?

aduth · 2018-06-11T15:01:16Z

I guess I don't like thinking of these as prepend and append behaviors, but rather within slots, each fill should be agnostic to its ordering. This is a strong "IMO" and is partly influenced by the complications which result by trying to introduce ordering / prioritization (though elsewhere we've relented, e.g. core block registration and transforms). Where the menu is effectively a set of slots / default items:

+------------------------------+
| BlockSettingsMenuFirstItem   |
| BlockSettingsMenu            |
| PluginBlockSettingsMenu      |
| (Transforms)                 |
+------------------------------+

youknowriad · 2018-06-11T15:04:43Z

My reasoning is that if we use it twice to another UI button, it won't act as "First Item"

aduth · 2018-06-11T15:06:10Z

At that point (and only if it's considered reasonable) we ought to consider whether a formal ordering system should be implemented.

gziolo · 2018-06-12T14:24:28Z

At that point (and only if it's considered reasonable) we ought to consider whether a formal ordering system should be implemented.

We could try to implement it by leveraging filters from wp.hooks as an internal mechanism to calculate the order of fills.

youknowriad self-assigned this Jun 7, 2018

youknowriad requested review from gziolo and aduth June 7, 2018 09:15

youknowriad commented Jun 7, 2018

View reviewed changes

gziolo mentioned this pull request Jun 7, 2018

Block List: Remove createInnerBlockList utility / context #7192

Merged

gziolo reviewed Jun 7, 2018

View reviewed changes

youknowriad force-pushed the update/replace-render-block-menu-with-slot branch from 76038ad to e0f28fd Compare June 8, 2018 10:16

gziolo reviewed Jun 11, 2018

View reviewed changes

Replace the renderBlockMenu prop with a Slot

d9ec524

youknowriad force-pushed the update/replace-render-block-menu-with-slot branch from e0f28fd to d9ec524 Compare June 11, 2018 12:23

gziolo approved these changes Jun 11, 2018

View reviewed changes

gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Jun 11, 2018

gziolo added the [Feature] Blocks Overall functionality of blocks label Jun 11, 2018

gziolo added this to the 3.1 milestone Jun 11, 2018

Rename the BlockSettingsMenu Slot to _BlockSettingsMenuFirstItem

d45ac48

youknowriad force-pushed the update/replace-render-block-menu-with-slot branch from 9e38b71 to d45ac48 Compare June 11, 2018 15:10

youknowriad merged commit 3504ae7 into master Jun 11, 2018

youknowriad deleted the update/replace-render-block-menu-with-slot branch June 11, 2018 15:21

This was referenced Jun 22, 2018

Block More Options menu: arrows navigation doesn't work any longer #7443

Closed

Fix arrows navigation in the block more options menu #7480

Merged

aduth mentioned this pull request Jul 2, 2018

Add "Convert to blocks" option in HTML block #7667

Merged

gziolo mentioned this pull request Jul 16, 2018

Block settings extensibility #7895

Merged

2 tasks

gziolo mentioned this pull request Aug 3, 2018

Editor: Stop exposing internal components starting with underscore #8421

Closed

noahtallen mentioned this pull request Oct 25, 2019

Allow block creators to disable block deletion via block support. #18118

Closed

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace the renderBlockMenu prop with a Slot #7199

Replace the renderBlockMenu prop with a Slot #7199

youknowriad commented Jun 7, 2018

youknowriad Jun 7, 2018

gziolo Jun 7, 2018

youknowriad Jun 8, 2018

youknowriad Jun 7, 2018

aduth Jun 9, 2018

gziolo left a comment

gziolo Jun 7, 2018

gziolo Jun 7, 2018

youknowriad Jun 8, 2018

gziolo Jun 8, 2018

gziolo Jun 7, 2018

gziolo commented Jun 11, 2018 •

edited

Loading

gziolo Jun 11, 2018

youknowriad Jun 11, 2018

gziolo Jun 11, 2018

youknowriad Jun 11, 2018

gziolo left a comment

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

gziolo commented Jun 12, 2018


		const { Fill: PluginBlockSettingsMenu, Slot } = createSlotFill( 'PluginsBlockSettingsMenu' );

		PluginBlockSettingsMenu.Slot = Slot;

Replace the renderBlockMenu prop with a Slot #7199

Replace the renderBlockMenu prop with a Slot #7199

Conversation

youknowriad commented Jun 7, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented Jun 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo left a comment

Choose a reason for hiding this comment

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

youknowriad commented Jun 11, 2018

aduth commented Jun 11, 2018

gziolo commented Jun 12, 2018

gziolo commented Jun 11, 2018 •

edited

Loading