Block Editor: Add useEditorFeature hook to simplify access to editor features #21646
Conversation
gziolo
added
[Package] Block editor
|
Size Change: +79 B (0%) Total Size: 845 kB
ℹ️ View Unchanged
|
gziolo
added
the
[Type] Technical Prototype
| const isDisabled = useIsLineHeightControlsDisabled(); | ||
| const isDisabled = useEditorFeature( | ||
| '__experimentalDisableCustomLineHeight' | ||
| ); |
There was a problem hiding this comment.
I like the API a lot, and the fact that we can implement any heuristics to get the value of that config in the hook without changing how the API is used.
I'm not sure yet about the naming. useEditorFeature, useEditorSetting, useEditorConfig ? How will it scale to nested configs like typography, colors? Why is __experimentalDisableCustomLineHeight a top level config and not nested under "typography" (same for drop cap).
There was a problem hiding this comment.
I like the API a lot, and the fact that we can implement any heuristics to get the value of that config in the hook without changing how the API is used.
🤘
There was a problem hiding this comment.
I'm not sure yet about the naming.
useEditorFeature,useEditorSetting,useEditorConfig?
If the thing we're referring to here is the same thing we assign via <Editor settings={ ... } />, or block_editor_settings filter, I'd very much like to see "setting" or "settings" as part of the name.
How will it scale to nested configs like typography, colors? Why is
__experimentalDisableCustomLineHeighta top level config and not nested under "typography" (same for drop cap).
Do we have nested settings? Can we not? 😛
There was a problem hiding this comment.
If we fly with useSetting then we need those nested groups to make it all easier. We discussed groups like typography, colors so far. I'm sure we need more. The only question is whether we name it feature, setting, support or whatever :)
There was a problem hiding this comment.
for context, this hook is supposed to get its values from the "config" property in the proposed format in the end. #21583 (comment)
This config is probably going to end up in the block-editor getSettings selector somehow, I haven't give it much though yet about how, whether it's just 1 - 1 or if there's some intermediate mapping that happens.
I don't think the block-editor settings and the "config" of a block-editor are the exact same things, block-editor can have more settings and themes can have more "config" though.
There was a problem hiding this comment.
It feels like all we need is proper namespacing to make it easy to inject all settings from the theme.json config. Wherever we have duplication, we can find a nice way to migrate it behind the scenes before sending it to the front.
To give an example, the following would still work on PHP side:
$settings = array(
'disableCustomColors' => get_theme_support( 'disable-custom-colors' ),
'disableCustomFontSizes' => get_theme_support( 'disable-custom-font-sizes' ),
);You could also override it with theme.json:
{
"config": {
"colors": {
"disableCustomColors": false
},
"typography": {
"disableCustomFontSizes": false
}
}
}The challenge would be to pick what takes precedence, theme.json or get_theme_support here, or the top-level disableCustomFontSizes vs typography. disableCustomFontSizes. Before sending it to the client, we would remove duplicates from the top-level using some conflict resolution strategy.
On the client, we need to keep old settings for backward compatibility but I would solve it by doing internal mapping in the getSettings selector:
const mappings = {
disableCustomColors: 'colors.disableCustomColors',
disableCustomFontSizes: 'typography.disableCustomFontSizes',
};I hope I didn't miss anything.
gziolo
requested review from
ajitbohra,
ellatrix,
jorgefilipecosta,
Soean,
talldan and
TimothyBJacobs
as code owners
|
We just need to settle on the name of the hook and it should be ready to go. I picked Aside: should we expose those settings from the server using REST API endpoint to make it possible to use it with standalone clients like the mobile app? |
gziolo
removed
the
[Type] Technical Prototype
Description
Implements the ideas shared in https://make.wordpress.org/core/2020/01/23/controlling-the-block-editor/.
Part of #20588.
Supersedes: #20623.
Related to: #21490, #20290.
Work in progress, all APIs are experimental.
This PR introduced a new experimental setting for drop cap:
__experimentalDisableDropCap. It follows conventions used for other settings that were added recently like:__experimentalDisableCustomLineHeight__experimentalDisableCustomUnitsIt also replaces existing hooks used for the listed settings with the new
useEditorFeaturehook.For the initial pass, the implementation of
useEditorFeatureis a tiny wrapper over thegetSettingsselector.The first next step would be to add a way to define block specific overrides and tackle it internally inside the hook based on the detected
BlockEditContext.There is also this general challenge about creating a good naming schema for all the features we plan to support. We also should seek ways to integrate it with Global Styles and
theme.jsonconfig.How has this been tested?
Set the setting for
__experimentalDisableDropCaptotrueon the server and make sure that there is no drop cap control displayed in the sidebar for Paragraph block.I also tested that the drop cap feature when enabled still works as before. The same applies to custom line hight and custom units.
Types of changes
New feature (non-breaking change which adds functionality).
Checklist: