Remove withBlockEditContext internal higher-order component#22942
Remove withBlockEditContext internal higher-order component#22942youknowriad merged 1 commit intomasterfrom
Conversation
|
|
||
| let { completers = EMPTY_ARRAY } = props; | ||
|
|
||
| completers = useMemo( () => { |
There was a problem hiding this comment.
Note: There's a bit more intensive refactoring here than just a direct port. I observed the prior logic was fairly unoptimized if editor.Autocomplete.completers, since it would create a new copy of the array on every render. It's also not necessary to consider the filtering on every render, if we're already managing this memoization.
| } | ||
|
|
||
| export default compose( | ||
| withBlockEditContext( ( { clientId } ) => { |
There was a problem hiding this comment.
Another interesting observation with migrating from higher-order components to hooks: With higher-order components, it's fairly easy to overlook when something is totally unused!
There was a problem hiding this comment.
Yes, I've often seen left over selectors :)
|
Size Change: -69 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
|
Noting here that we have used Mentioning it here because I've noticed it's considered internal (from the PR title) but is also being leveraged at least in one plugin. |
Related: #22905
This pull request seeks to remove the
withBlockEditContextinternal helper of the@wordpress/block-editorpackage. The motivation here is (a) to flatten the common block React element hierarchy and (b) to favor hooks-based implementations over higher-order components.withBlockEditContextwas a useful and expressive helper at the time it was originally implemented, due to the cumbersome nature of using React Context<Consumer>elements. WithuseContext, it's much simpler now to get direct access to the context object properties relevant for this behavior.Testing Instructions:
Verify no regressions in the behavior of affected components. For example, block-based autocomplete and alignment toolbar.