Request to expose @wordpress/block-editor styling hooks/utilities into a separate package

[mikejolley]

What problem does this address?

We have an issue in WooCommerce blocks where because blocks are rendered dynamically on the frontend (markup is converted to React components), where we use global styles we need to convert any styling rules stored as attributes into valid inline CSS. For that we need to use the hooks exported from @wordpress/block-editor e.g.

• useBorderProps
• useColorProps
• useSpacingProps

This however is problematic because block-editor is a huge dependency not suitable for the frontend of a site.

To avoid this dependency we're forced to copy some utilities from the @wordpress/block-editor package into our own codebase. This is being worked on here.

What is your proposed solution?

It would be fantastic if the utilities that useBorderProps, useColorProps etc consume were exposed in a separate package. In the PR I'm working on, the utilities we've borrowed include:

• getInlineStyles
• getColorClassName
• getBorderClassName
• getGradientClassName
• getColorClassesAndStyles
• getBorderClassesAndStyles
• getSpacingClassesAndStyles

These utilities seem generic enough to be split out from @wordpress/block-editor into a new or existing package.

[ramonjd]

The style engine, at least on the backend, already generates both classnames and styles for many properties. It returns something like

array(
    'css'           => (string) A CSS ruleset or declarations block formatted to be placed in an HTML `style` attribute or tag.
    'declarations'  => (array) An array of property/value pairs representing parsed CSS declarations.
    'classnames'    => (string) Classnames separated by a space.
);

Also getInlineStyles() is a wrapper for the style engine's getCSSRules function anyway.

Perhaps we could migrate these types of methods over to the style engine, or, better, find a way to create a generic method to return classnames along with the compiled CSS, similar to the way we do it in the backend.

For backwards compatibility, we could let the existing suite of methods hang around and slowly migrate their innards to whatever generic method we create in the style engine and one day deprecate.

cc @andrewserong @youknowriad

[youknowriad]

Kind of a tangent but isn't it the purpose of the Interactivity API to solve this kind of use-cases. Adding dynamic behavior to the frontend without necessarily having the need to recreate the whole block output in the frontend. Meaning you could render the block in php like any other block and just add small bits of interactivity in the frontend.

---

Now, yeah the style engine is not in a great place at the moment and we need to keep expanding its usage (while keeping its API surface small and clear attributes, config => styles). The reality now is that we have different ways of doing the same things.

[ramonjd]

Kind of a tangent but isn't it the purpose of the Interactivity API to solve this kind of use-cases. Adding dynamic behavior to the frontend without necessarily having the need to recreate the whole block output in the frontend. Meaning you could render the block in php like any other block and just add small bits of interactivity in the frontend.

Thanks for making the link to the Interactivity API , it's something I haven't had the time to catch up on since I've been back.

I'm not sure how much overlap there is with the Interactivity API and the issues described in the issue.

I still assume we'll need a way to parse block attributes and generate styles for dynamically-rendered blocks on the frontend, at least on initial render. That's what the style engine does, at least for now 😄

I'd imagine that's a case for porting more functionality to the JS version (?)

The Interactivity API may need to call on helper methods when toggling classes and/or inline styles, or it may not. I'm not yet familiar enough with it to judge so I'll follow your judgement.

Now, yeah the style engine is not in a great place at the moment and we need to keep expanding its usage (while keeping its API surface small and clear attributes, config => styles). The reality now is that we have different ways of doing the same things

Things have stalled on that front. The next big, and most important (and the trickiest), hurdle to overcome is getting it to handle and output global styles. It's my dream that one day, we'll be able to throw a theme.json at it and it generates a stylesheet. It can already handle most things except all the bits like layout, duotone, global padding, and other special cases so it's not far off.

I haven't personally had enough time to kickstart that again.

But to address the "different ways of doing the same things" I believe it might be worth exploring whether the style engine can take over the job of these disparate methods, e.g., useSpacingProps even for consistency and greater accessibility for such dynamic cases.

[youknowriad]

I'd imagine that's a case for porting more functionality to the JS version (?)

No, not really, for the frontend, there's no need to "regenerate the styles" unless you recreate the whole block in JS which is not what the Interactivity API is about.