Access global styles from the post editor#46894
Access global styles from the post editor#46894tellthemachines wants to merge 2 commits intotrunkfrom
Conversation
|
Size Change: -167 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
| ### findInPresetsBy | ||
|
|
||
| Undocumented declaration. | ||
|
|
There was a problem hiding this comment.
I'll add docs for this once we've determined that this is, in fact, the best place for these utils 😅
|
Flaky tests detected in 37445c0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3871236151
|
noisysocks
left a comment
There was a problem hiding this comment.
I think we need to rethink the API boundaries surrounding global styles 😀
It's strange to me in this PR that @wordpress/block-editor exports fairly low level functions that are then used by the global styles code in @wordpress/edit-site. Also ideally we wouldn't have two similar but different implementations of useStyle.
Three proposed features have come up recently that hint towards a need for BlockEditor to have the ability to work with global styles. 1) Displaying default theme settings as a placeholder; 2) Showing newly created style variations; and 3) Implementing 'Push to Global Styles' in the post editor.
I'm therefore thinking that we ought to make global styles a first class citizen of the block editor and move the high level global styles APIs to @wordpress/block-editor. That is: useGlobalStylesReset, useStyle, useSetting, useGlobalStylesOutput, and GlobalStylesProvider. GlobalStylesUI can remain in @wordpress/edit-site. GlobalStylesProvider could be made generic so that @wordpress/block-editor doesn't have to know about the globalStyles CPT.
| PRESET_METADATA, | ||
| findInPresetsBy, | ||
| getValueFromVariable, | ||
| } from './style-variable-resolution'; | ||
| export { getTypographyFontSizeValue } from './typography'; |
There was a problem hiding this comment.
I think these functions are too low level to export as @wordpress/block-editor APIs. In my mind they're implementation details of useGlobalStylesOuptut and useStyle. If we export them then it makes it difficult in the future to change the implementation of useGlobalStylesOuptut and useStyle without breaking backwards compatibility.
| * const backgroundColor = useStyle( 'color.background' ); | ||
| * ``` | ||
| */ | ||
| export default function useStyle( path ) { |
There was a problem hiding this comment.
If you squint this looks the same as the useStyle hook in @wordpress/edit-site. It would be nice to have only one implementation.
| 'description' => __( 'Styles consolidated from core, theme, and user origins.', 'gutenberg' ), | ||
| 'type' => 'object', | ||
| 'context' => array( 'mobile' ), | ||
| 'context' => array( 'post-editor', 'widgets-editor', 'mobile' ), |
There was a problem hiding this comment.
What is this change for? I don't see this REST API endpoint used in this PR.
Sounds sensible, let's try that 👍
Yeah, these are essentially utils that are needed across packages because we're converting presets to valid CSS and vice-versa a bit all over the place. There are a few instances of duplication of functions between packages that I think happened in an attempt to avoid this problem, but it would be good to be consistent in how we handle these values. Not wanting to suggest a |
|
Closing in favour of #47098 |
What?
This is an updated version of #34178 as that PR had too many merge conflicts 😅
Why?
For post editor block design tools to reflect values from global styles, and to allow us access to newly created style variations as a follow-up from #46343.
How?
See #34178 for foundational work.
useStylefunction that gets the relevant styles from the block editor settings;Testing Instructions
This only works for block-specific styles, not site-wide styles. See #34178.
Testing Instructions for Keyboard
Screenshots or screencast