Fix perf regression in duotone hooks#48401
Conversation
|
Size Change: +156 B (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 2a2efa1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4262120770
|
|
Thanks for the follow-up. |
| const duotoneSupportSelectors = getBlockSupport( | ||
| name, | ||
| 'color.__experimentalDuotone' |
There was a problem hiding this comment.
I found this line confusing because it seems related to block supports but in actual fact it's just retrieving the CSS selectors defined as targets for the duotone. It will be better once we move this support to a dedicated filters.duotone key.
| const selectorsGroup = scopeSelector( | ||
| `.editor-styles-wrapper .${ id }`, | ||
| duotoneSupportSelectors | ||
| ); |
There was a problem hiding this comment.
I know @ajlende has a follow up which uses standard Theme JSON class methods to handle this.
This was a close one!
What?
Fixes a performance regression likely introduced by #48318.
See #48318.
Why?
The refactor in #48318 caused some hooks to be executed for all blocks and not just those which support duotone. This has a big impact on performance, especially as some of those hooks were doing potentially expensive lookups in settings.
How?
Established a component guard pattern where by:
editor.BlockEditeditor.BlockListBlockearlyJSX conditionals to help encourage developers to consider the perf impact of future changes. Ideally this wouldn't be necessary but given that the code is not well covered with tests (and developers are human) it's probably our best bet of avoiding this happening again.returnsTesting Instructions
The goal is that Duotone support in the Editor on blocks behaves exactly as per
trunk(but just with better performance).Manual testing should involve:
"templateLock": "contentOnly").Testing Instructions for Keyboard
Screenshots or screencast