Rendering duotone presets in pattern preview

[matiasbenedetto]

What?

Fixing duotone rendering in the pattern selection panel.

Why?

This is necessary to make the pattern preview accurate.

How?

In this PR we render the duotone svg filters default and theme filter inside the pattern preview iframe.

Previously we were rendering just the custom duotone applied to the current block but if the block has a filter applied globally using theme.json, the duotone doesn't work because the preset filters were not rendered.

Testing Instructions

1. Use a theme that supports duotone for example Skatepark
2. Create a new post or page
3. Open the add pattern panel
4. See the patterns that include blocks without a custom duotone applied but with duotone presets in theme.json for example "Full-width image with aside caption" from Skatepark.

Screenshots or screencast

Before:	After:

[ajlende]

Just a couple minor things. This is looking great!

[ajlende]

Looking good! Give it a rebase/merge to see if that fixes the failing tests—they don't look related to the changes here

[matiasbenedetto]

I found the problem that is causing the test failures. It is related to the import of this component import { PresetDuotoneFilter } from '../../hooks/duotone';. When we import that component from the file packages/block-editor/src/hooks/duotone.js the filters are called and I think we should not do that.

addFilter(
	'blocks.registerBlockType',
	'core/editor/duotone/add-attributes',
	addDuotoneAttributes
);
addFilter(
	'editor.BlockEdit',
	'core/editor/duotone/with-editor-controls',
	withDuotoneControls
);
addFilter(
	'editor.BlockListBlock',
	'core/editor/duotone/with-styles',
	withDuotoneStyles
);

For that reason, I'm considering moving the definition of thePresetFilter component to another file.

[ajlende]

@matiasbenedetto This change would be making the API public, and I want to make sure the API is a little more friendly before we do that. I'm planning on changing the API for InlineDuotone and DuotoneFilter in #39564: values will be replaced with colors (string[]) so getValuesFromColors can be inlined into DuotoneFilter.

For now can we export them as __unstable to indicate that they are for internal use only right now? This should also stop the documentation from generating.

I think DuotoneFilter with the new API and DuotoneStylesheet could become the two exported things eventually. I think that's probably the smallest subset of components to expose since they need to be used separately sometimes. PresetDuotoneFilter could be in use-global-styles-output.js and InlineDuotone could be in duotone.js like before.

[matiasbenedetto]

@matiasbenedetto This change would be making the API public, and I want to make sure the API is a little more friendly before we do that. I'm planning on changing the API for InlineDuotone and DuotoneFilter in #39564: values will be replaced with colors (string[]) so getValuesFromColors can be inlined into DuotoneFilter.

Thanks for the context!

For now can we export them as __unstable to indicate that they are for internal use only right now?

Yep, done.

This should also stop the documentation from generating.

Good, I deleted the additions to the docs. By the way, the docs are not autogenerated but there is a check before commit that fails if the docs are not there. Despite I exported the components as __unstable the linter complained that we need to update the docs.

PresetDuotoneFilter could be in use-global-styles-output.js

This component is also used in packages/block-editor/src/components/block-preview/auto.js, and at a glance packages/edit-site/src/components/global-styles/use-global-styles-output.js doesn't seem to be the best place for it. Do you think we should move it from the current location (packages/block-editor/src/components/duotone/components.js)?

and InlineDuotone could be in duotone.js like before.

Done!

[matiasbenedetto]

Updated with the latest changes from #39564