refactor: Avoid private useBlockEditorSettings API#108
Conversation
The `useBlockEditorSettings` function is not exported, even as a private API. Using it is brittle, at best, and the approach is not possible when sourcing WordPress package scripts from remote sites. These changes still patch the `@wordpress/block-editor` package to (1) allow the "quick inserter" to open the primary inserter and (2) enable the Media tab in the inserter. Long-term, we should remove these patches and replace them with changes to core.
When a post object is unavailable, we must ensure the raw title and content fields have fallback values. Otherwise, the host bridge logic throws while referencing values on an undefined object.
Now that we rely upon `EditorProvider` over `BlockEditorProvider`, we can no longer configure the former with the `hasFixedToolbar` prop. Instead, we must rely upon the preference store configuration.
We now render `EditorProvider` rather than `BlockEditorProvider`, so we no longer configure the latter with explicit settings. We also do not have explicit settings we need to pass to the former, so we pass an empty object to avoid exceptions from referencing values on an undefined object.
dcalhoun
added
the
[Type] Task
| - stripExperimentalSettings: true, | ||
| + stripExperimentalSettings: false, |
There was a problem hiding this comment.
Patch manually enables populating the Patterns and Media tabs within the inserter. As outlined in the PR description, this is a workaround that works for the local editor, but not the remote editor.
Ideally, we seek the Gutenberg project exposing the APIs we need to avoid this patch.
| preferenceDispatch.setDefaults( 'core', { | ||
| fixedToolbar: true, | ||
| } ); |
There was a problem hiding this comment.
Since we can no longer set hasFixedToolbar on the BlockEditorProvider, we must rely upon the preferences store.
| title: { raw: '' }, | ||
| content: { raw: '' }, |
There was a problem hiding this comment.
Ensures draft posts do not throw exceptions when referencing values on undefined objects—this only occurred in development environments.
|
@kean would you mind reviewing this when you have time please? |
kean
left a comment
kean
left a comment
There was a problem hiding this comment.
I smoke tested the changes – looks good.
2 participants
What?
Remove use of
@wordpress/block-editor's private, non-exporteduseBlockEditorSettingsfunction. This reintroduces changes originally implemented in #24, but extended to address a disappearing block toolbar and empty Patterns/Media inserter tabs—effectively reverting #50.Why?
First, using private APIs is inadvisable and not a sound, long-term solution.
Second, we were actually patching
@wordpress/block-editorto exportuseBlockEditorSettingsas a private API. While patching "works" for the editor bundled with the app, we cannot patch the "remote"/site-specific editor—i.e., one that relies upon WordPress packages sourced from a user's site (see pbArwn-763-p2).How?
First, remove the
@wordpress/block-editorpatch.Second, we now rely upon
@wordpress/editor'sEditorProviderrather than@wordpress/block-editor'sBlockEditorProvider. The positive is that this approach negates our need to accessuseBlockEditorSettingsas its usage is now managed by theEditorProvider. The negative is that theEditorProviderstrips other experimental features—e.g., populating content for the Patterns/Media inserter tabs—by default, which leads to the next change...Third, we introduce a
@wordpress/block-editorpatch disablingstripExperimentalSettings. This means the Patterns/Media tabs now function as desired in the bundled editor. As noted previously, this patch cannot be applied to the remote editor, meaning the tabs do not populate in that environment. We are trading one patch for another, but the outcome is the remote editor, at least, functions, albeit without a few features requiring patches.Lastly, since we can no longer set
hasFixedToolbaron theBlockEditorProvider, we rely upon settingfixedToolbarin the preferences store.Testing Instructions
Tip
Installable prototypes are available for testing:
1 - Formatting options remain present within the block toolbar
options—e.g., bold, italic, etc.
2 - The Patterns/Media tab populate with content from the current site
Accessibility Testing Instructions
N/A, no user-facing changes.
Screenshots or screencast
N/A, no user-facing changes.