Rich Text: Move RichTextShortcut and RichTextInputEvent into @wordpress/rich-text#79828
Conversation
…ss/rich-text These format helper components and their contexts have no block-editor specific logic, so house them in the rich-text package where any rich text field owner (not just the block-editor canvas) can provide the contexts. The block-editor files re-export them from the rich-text private APIs for back-compat, since format-library and third-party formats import them from @wordpress/block-editor. The move also fixes the react-hooks/refs suppression in both components by keeping the latest callback in a ref updated inside an effect instead of during render. Extracted from #78471 per review feedback.
|
Size Change: +172 B (0%) Total Size: 7.67 MB 📦 View Changed
|
andrewserong
left a comment
There was a problem hiding this comment.
This looks like a good move to me (and sets up re-use nicely for the larger rich text control PR).
Smoke tests appropriately in the editor via bold, italic, inline code shortcuts.
LGTM!
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ntsekouras
left a comment
There was a problem hiding this comment.
Looks good, thanks! I've left a small comment.
I still think that we could also move the listeners (as mentioned here), but we can still consider it afterwards.
Replace the useRef + passive useEffect pattern with useEvent from @wordpress/compose, which syncs via useInsertionEffect and guards against reading stale data. Addresses review feedback.
|
The new Another Nit: Let's use React's component naming convention (PascalCase) for context as well; it's recommended. |
| // `keyboardShortcutContext` with standalone rich text fields. Re-exported here | ||
| // for back-compat (e.g. `@wordpress/format-library` imports it from | ||
| // `@wordpress/block-editor`). | ||
| export const { RichTextShortcut } = unlock( richTextPrivateApis ); |
There was a problem hiding this comment.
Do we need these two files? I think we can export directly from index.js, no?
There was a problem hiding this comment.
Fixed in 15b546f - the two files are gone, both components are now exported directly from the rich text index.
+1 to that. What I had in mind by saying move the listeners was to actually absorb more of the glue needed for consumers. I prototyped with Claude Fable 5 something along the lines of what I had in mind. Noting I haven't reviewed that in depth though.. In the above changeset --cc @ellatrix |
React contexts are components, so follow the component naming convention as suggested in review.
The two standalone files only re-exported the components from @wordpress/rich-text private APIs; export them directly from the rich text index instead, as suggested in review.
Brings over the review changes from the extraction PR and applies the same rename to the consolidated-branch consumers.
|
Flaky tests detected in 15b546f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/28887952369
|
|
Tbh, I wish we could get rid of RichTextInputEvent and RichTextShortcut and move it outside React the format object. |
What?
Moves
RichTextShortcut,RichTextInputEvent, and their shared contexts (keyboardShortcutContext,inputEventContext) from@wordpress/block-editorinto@wordpress/rich-text, exposed via the rich-text private APIs. The block-editor files become thin back-compat re-exports.Extracted from #78471 per @ntsekouras's review suggestion so it can land first as a smaller, self-contained refactor.
Why?
These format helper components have no block-editor specific logic: they only register callbacks into a context that the rich text field owner provides and dispatches.
@wordpress/rich-textis their natural home, and housing them there lets any rich text field (not just the block-editor canvasRichText) provide the contexts. #78471 (RichTextControl, the standalone rich text form control) is the first consumer outside the block editor.How?
@wordpress/rich-text(private APIs):src/contexts.js-keyboardShortcutContextandinputEventContext, previously created in block-editor'srich-text/index.js.src/keyboard-shortcut.js/src/input-event.js-RichTextShortcutandRichTextInputEvent, moved as-is except the "latest callback" ref is now updated inside an effect rather than during render, which also resolves the tworeact-hooks/refseslint suppressions the old files needed.@wordpress/block-editor:rich-text/shortcut.jsandrich-text/input-event.jsre-export the moved components from the rich-text private APIs, keeping the existing public import paths working (@wordpress/format-libraryand third-party formats import them from@wordpress/block-editor);rich-text/index.jsand the block-fieldsRichTextControlread the contexts from the rich-text private APIs.No behavior change. Everything stays private/internal: the components were only ever public via the block-editor re-export, which is unchanged.
Testing instructions
npm run wp-env start && npm start.RichTextShortcut).formatStrikethroughinput event and list-outdent behavior still work (e.g. delete at the start of an indented list item), which exerciseRichTextInputEvent.npm run test:unit -- packages/rich-text packages/block-editor/src/components/rich-text- 218 tests pass.Types of changes
Code quality / refactor (non-breaking, no behavior change).