Global Styles: Client-side render variables as styles in Gutenberg

[ItsJonQ]

This is required as part of the Global Styles focus for the first phase (aka "Red" phase)

This effort supports the initial render of global styles. These mechanisms are also responsible for subsequent live-renders upon any changes made to global style values.

These style renders happen within the context of the Gutenberg editor ("backend"). Not the "frontend" of the user's site.

Requirements

• Read style meta data provided by the database
• Consolidate styles within the Store (wp.data)
• Render styles into the DOM on store updates
• Re-render styles into the DOM on applicable global style changes

Considerations

• Memoization (shallow or deep compare) to prevent unnecessary re-renders
• Usage of hooks
• Proper handling of mounting/unmounting. Cleaning up DOM nodes and/or listeners/subscriptions

Preparing data for wp.data (Redux)

The (merged) data from theme.json and the database will need to be prepared and hydrated into the Redux store (wp.data).

Rendering

Either using pubsub and/or hooks, the merged/flattened styles need to be transformed into a CSS string, that is to be rendered into a style tag that's been injected into the DOM.

---

@nosolosw Has created a working implementation in this branch: (still WIP)

https://github.com/WordPress/gutenberg/commits/try/global-styles-client-resolver

📹 Video demo:
https://d.pr/v/n9xrlr

How to test it:

• Uncomment the code within gutenberg_global_styles_experimental_settings the first time you load a post. It'll create a new record for the GlobalStyles CPT in the database. Comment back after that.
• In the console, change the text color by doing: wp.data.dispatch( 'core' ).editEntityRecord( 'postType', 'wp_global_styles', wp.data.select('core/block-editor').__experimentalGetGlobalStylesId(), {'core/paragraph':{color:{text:'blue'}}} )

Due to current the lack of an Editor interface as well as Control UI, the action needs to be dispatched manually (via the function invoke above).

At this stage of prototyping/development, I think it works okay!
For the sake of testing, if needed, I think we can great an easier dev-only method of controlling Global Styles.

[ItsJonQ]

Thoughts re: hooks.

I looked into the editor.js component. Since hooks can't be used in React class components (according to their docs), we may need to do something that looks like this:

// global-styles-renderer.js
const useGlobalStylesRenderer = () => {
	// Pretend this hook exists
	const styles = useGlobalStylesData()
	// Inject the style by creating/update style DOM node
}
export const GlobalStylesRenderer = () => {
	useGlobalStylesRenderer()
	return null
}

// editor.js
import { GlobalStylesRenderer } from './global-styles-renderer'
class Editor extends Component {
	render() {
		return (
			<StrictMode>
				...
				<GlobalStylesRenderer />
			</StrictMode>
		)
	}
}

[gziolo]

Requirements

• Read style meta data provided by the database
• Consolidate styles within the Store (wp.data)
• Render styles into the DOM on store updates
• Re-render styles into the DOM on applicable global style changes

Quick observation, the way you described it resembles CSS in JS a lot.

How do you plan to tackle frontend styles? It seems like they would have to be cached. Is the process different from the one outlined for the backend (editor).

What’s the planned scope of application of all those CSS variables? Is it limited only to the content generated? In that, I mean save and edit functions in all block definitions? Is it something you would use in SCSS files only or it’s fine to use them in JSX as style props?

[oandregal]

Closing this as per #19611 (comment)