Style engine: rename global function

[ramonjd]

What?

Rename wp_style_engine_get_block_supports_styles to wp_style_engine_get_styles and document a 'context' option that will determine how we treat incoming style object.

Why?

We'll potentially have multiple origins of styles, even though those style object will be similar. For example, the value of a block's attributes.style object or the top level styles in theme.json.

To avoid having multiple, specifically-named global functions, why not one that can handle everything?

Better for future compatibility, flexibility and better for our brains!

Props to @aristath for the idea.

How?

Renaming.

Testing Instructions

Run npm test-unit-php

Smoke test a site to ensure nothing breaks.

[aristath]

LGTM 👍
Right now there's only block-supports, but in the future I assume we'll need to add a $context arg in the function to differentiate between global-styles, block-supports and any other implementations we may have.
For now since block-supports is the only one, just renaming the function will be enough 👍

[ramonjd]

I assume we'll need to add a $context arg in the function to differentiate between global-styles, block-supports and any other implementations we may have.

Yeah, I documented it in the PHP doc but assumed that 'block-supports' would be default for now.

Thank you for looking at this 🍺

[andrewserong]

Thanks for putting this up, and +1 thanks for the suggestion @aristath!

✅ Rename looks good
✅ Smoke tested the block supports still work correctly on the site frontend

Right now there's only block-supports, but in the future I assume we'll need to add a $context arg in the function to differentiate between global-styles, block-supports and any other implementations we may have.

Agreed — since the implementation doesn't yet enqueue the styles and use the store, this PR as-is looks good to merge to me, and we can add the $context arg once we start enqueuing as in #42452?

LGTM!