-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[WIP] Block Editor Store: Allow management of block inspector tabs #46271
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1842,6 +1842,55 @@ export function temporarilyEditingAsBlocks( state = '', action ) { | |
return state; | ||
} | ||
|
||
/** | ||
* Reducer returning the current configuration for block inspector tabs. | ||
* | ||
* @param {Object} state Current configuration state for block inspector tabs. | ||
* @param {Object} action Dispatched action. | ||
* | ||
* @return {Object} Updated state. | ||
*/ | ||
export function blockInspectorTabs( state = {}, action ) { | ||
switch ( action.type ) { | ||
case 'ENABLE_BLOCK_INSPECTOR_TABS': | ||
if ( ! action.blockName ) { | ||
return { ...state, enabled: true }; | ||
} | ||
|
||
return { | ||
...state, | ||
[ action.blockName ]: { | ||
...state?.[ action.blockName ], | ||
enabled: true, | ||
}, | ||
}; | ||
|
||
case 'DISABLE_BLOCK_INSPECTOR_TABS': | ||
if ( ! action.blockName ) { | ||
return { ...state, enabled: false }; | ||
} | ||
|
||
return { | ||
...state, | ||
[ action.blockName ]: { | ||
...state?.[ action.blockName ], | ||
enabled: false, | ||
}, | ||
}; | ||
|
||
case 'SET_DEFAULT_BLOCK_INSPECTOR_TAB': | ||
return { | ||
...state, | ||
[ action.blockName ]: { | ||
...state?.[ action.blockName ], | ||
defaultTab: action.defaultTab, | ||
}, | ||
}; | ||
Comment on lines
+1881
to
+1888
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The default tab could be a separate reducer, and it'd simplify the code quite a bit.
Or you could use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for highlighting this.
I think we'll need to tweak the proposed structure a little further to allow for overriding the default display of tabs for all blocks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is an all block setting definitely needed? I do wonder if that could be explored as a user preference (especially as an accessibility option), but worth taking this one challenge at a time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. During some recent discussions, it was requested that plugins be able to disable/enable tabs across all blocks but that it shouldn't necessarily be something controlled by end users. I'll have another think about it. It could also be something we expanded upon in the future. |
||
} | ||
|
||
return state; | ||
} | ||
|
||
export default combineReducers( { | ||
blocks, | ||
isTyping, | ||
|
@@ -1865,4 +1914,5 @@ export default combineReducers( { | |
lastBlockInserted, | ||
temporarilyEditingAsBlocks, | ||
blockVisibility, | ||
blockInspectorTabs, | ||
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an interesting one, because reducers are usually used for values that are likely to change at runtime. I wonder if there will be a use case for changing these values while the editor is running.
My feeling is that these values will probably be set as an initial configuration of the editor, which is often the job of the block editor settings (although technically they can change at runtime too, but often don't).
I think the only pain point will be that it's a little more difficult to handle deeply nested objects, but I think the data structure could be simplified (as mentioned in my other comment).
Editor settings can also be set in PHP, so that another advantage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to note we have a use case for the Nav offcanvas experiment whereby we'd need to programmatically select the default tab as a result of an interaction with the "edit" button.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appreciate the feedback 👍
The desire to set the default tab for the Navigation Link block, depending on if it was edited via the parent Navigation block's list view, drove the need for these values to change at runtime.
Splitting the management of the block inspector tab display so the default tabs are handled separately would open up the possibility of using the block editor settings. I'll be happy to explore that approach as well.
In the meantime, I wonder if this is reason enough to reconsider disabling tabs entirely for the Navigation Link block in the short term. It would allow us to avoid adding anything to the store related to the tabs or navigation experiments and all tab management settings would still be contained in a single location.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@getdave Aaron explained this to me in a private message. My mistake for not reading the PR description thoroughly.
The main problem is that I don't think a stable API should be introduced for two experimental features. There is a proposal for experimental selectors/actions, which would help:
I don't know if the
__experimental
prefix is still allowed? cc @adamzielAlternatively the prefix could be used, but the selectors/actions would need to be stabilized or removed for alternatives before 6.2, so that they're not released with WordPress core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scruffian If we go down this route then will this compromise the user testing of the Nav offcanvas experiment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think as long as we can put the link settings above the color ones then this should be an ok interim solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is what the navigation link block currently looks like with the tabs disabled. The label input is the first much like I imagine is desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the tooling is merged it will be safe to stop introducing new prefixed APIs entirely, but we're not there yet. Ideally there wouldn't be anything
__experimental
in public exports, but at the moment we cant avoid it sometimes.