-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style engine: rename main public function to reflect functionality #42140
Style engine: rename main public function to reflect functionality #42140
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This rename looks good to me @ramonjd, and tested that the border, colors, elements, spacing, and typography supports still work for server-rendered blocks 👍
One potential issue with the naming is that gutenberg_style_engine_generate_block_styles
shares the name block styles with the block styles feature, where this function generates the styles for block supports, which is semantically slightly different, but tricky to neatly fit into a name!
I don't feel too strongly about the naming, though, and I agree with the premise behind this PR, which is that it'd be better for the public function name to be a little more specific to this particular use case of the style engine, so that we're freed up to explore calling the style engine in a different way if need be for when we tackle global styles.
So, not a blocker from me if you (or anyone else) think we should just stick with block_styles
for now 🙂
This is a great point @andrewserong, thanks for raising it. I was hoping that the In my mind, I consider block styles (for the purposes of the style engine) to mean not only the object that blocks have in Proof that this definition works is over in #42143. So maybe we need another term to cover that "styles" object. Possibly just I'm very open to add It's enough that we differentiate the methods from whatever use for global styles later, e.g., One thing to note is that I'm experimenting with splitting getting classnames from getting CSS, so |
Thanks for the extra detail @ramonjd! Would |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've given this a run as well.
✅ Unit tests pass
✅ Border, color, spacing, and typography supports still work for dynamic blocks
✅ Couldn't see any missed references to gutenberg_style_engine_generate
✅ Switching references from styles to declarations makes sense
I had similar thoughts as @andrewserong regarding the overlap between the new naming here with block styles and the concept of Block Styles in the Block API. I wouldn't be opposed to making the new name slightly more verbose to distinguish the two more. Certainly not a blocker for me either though.
Thanks for your input @aaronrobertshaw and @andrewserong Since you both had the same idea, I'll err on the side of verbosity to avoid confusion.
|
+1 for block_supports_styles |
…yles to better describe the first (and required) argument: a single block style object. Renaming references from styles to declarations for clarity. Adding PHP doc comments to tests.
…k styles, which is an existing paradigm that pertains to "style variations".
e515464
to
d1532cc
Compare
What?
Renames
wp_style_engine_generate
towp_style_engine_generate_block_styles
to better describe the first (and required) argument: a single block style object.I also took the opportunity to rename some references from styles to declarations for clarity.
Why?
One day we'll likely one to pass the theme.json styles object and return a stylesheet. Something like
wp_style_engine_generate_global_styles
Or not. Whatever.
This change ensures we won't be stuck with a generic name for a function that specifically deals in block styles.
How?
With a keyboard.
Testing Instructions
Run the tests!