Block Editor: Introduce experimental features API #20623
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
added
[Type] Enhancement
|
Size Change: +289 B (0%) Total Size: 904 kB
ℹ️ View Unchanged
|
youknowriad
reviewed
Mar 4, 2020
| * | ||
| * @return {Object} The block editor feature object. | ||
| */ | ||
| export function __experimentalGetFeature( state, featureName ) { |
There was a problem hiding this comment.
What happens if we decide to introduce block based features in the future, do you think we can write this selector in a future proof way? I guess having an example in a block or something would help clarify things a bit.
There was a problem hiding this comment.
How about the following:
export function __experimentalGetFeature( state, featureName, blockName ) {I didn't want to cover the per block approach in the first iteration because of the legacy considerations with the block editor setting that needs to be addressed first.
How about we land an initial version and then I can branch and open two PRs:
- sync story for existing settings
- drop cap implementation that works also on a block type level?
There was a problem hiding this comment.
Yeah, that works for me if we keep things experimental.
export function __experimentalGetFeature( state, featureName, blockName )
Is the blockName the only thing that could affect the result? Maybe it is, just trying to think ahead.
There was a problem hiding this comment.
The one thing I'm not sure about is whether we always want to return an object with a feature's config.
I'd be interested to see the following as well:
const isDropCapAllowed = wp.data.select( 'core/block-editor' ).__experimentalGetFeature( 'typography.allowDropCap', 'core/paragraph' );I can't think about anything else at the moment.
There was a problem hiding this comment.
How about we land an initial version and then I can branch and open two PRs:
* sync story for existing settings * drop cap implementation that works also on a block type level?
Sounds good.
6 tasks
|
Really excited to see this land! ❤️ |
gziolo
force-pushed
the
add/block-editor-features
branch
from
5870d99 to
13593c0
Compare
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Implements the ideas shared in https://make.wordpress.org/core/2020/01/23/controlling-the-block-editor/.
Part of #20588.
Related to: #21490, #20290.
Work in progress, all APIs are experimental.
How has this been tested?
Tests only at the moment.
Screenshots
Types of changes
Checklist: