Add support for block variation styles #49728
Conversation
ntsekouras
added
[Type] Enhancement
ntsekouras
requested review from
youknowriad,
gziolo,
ellatrix,
ramonjd and
tellthemachines
ntsekouras
requested review from
spacedmonkey,
ajlende,
ajitbohra,
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
|
Size Change: +386 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
|
It’s an interesting decision to make, whether block variations should know about style variations, or as proposed in this PR, it’s the style variations that are aware of block variations. Either way, if both get extended, it’s going to be difficult to tackle it for newly added options as there is no simple way to edit existing entries. |
That's a great note! My take on this is that with the alternative approach technically the internal structure(how we keep the styles in store) would be the same, because there is the need to have a connection of a style and the main block - or at least similar with an addition to store with something like So while I was exploring this, I think this is an API with small additions and enables registering a style for multiple variations at once. I'd love to hear others thoughts though! So, how can we move this forward by either accepting/modifying the current proposal or rejecting it? --cc @WordPress/gutenberg-core , @mtias |
ntsekouras
force-pushed
the
try/block-variation-styles
branch
from
42f6ad6
to
7dfd9b2
Compare
There was a problem hiding this comment.
This is an interesting problem! How would we make these variations styles editable from the global styles UI, similarly to what was done in #46343?
The idea with that PR is that going forward, block style variations should be editable both from theme.json and from the UI, and once #49602 is done, it will be possible to add new ones in the same way. This aims to move away from using stylesheets for the block styles, and get them using block supports/design tools instead.
The main issue with introducing style variations for block variations as this PR does is that block variations don't have a presence either in theme.json's styles.blocks object or in the global styles UI for editing block styles. Could we perhaps make variations behave more like blocks and allow editing their styles from theme.json and from global styles?
| @@ -552,6 +552,12 @@ | |||
| "isDefault": { | |||
| "type": "boolean", | |||
| "default": false | |||
| }, | |||
| "variations": { | |||
There was a problem hiding this comment.
This isn't working for me when testing this branch - I'm still getting a warning in VSCode that this property isn't allowed when adding it to block.json 🤔
There was a problem hiding this comment.
Sometimes I had that warning too in VSCode when I first check out the branch, but it goes away if I reopen that file. Probably some VSCode cache? 🤔 . Even with the warning it still works though for me? What do you mean not working?
That's an issue that needs discussion and evaluate the pros and cons(also see disucssion). While block variations usually change some minor things(like pre-setting specific attributes etc..), for more complex cases they are combined with extending the blocks. That way they can still reuse the main functionality of the block and add some, possibly making it seem like a completely different block. In the simple cases though too, there could be value for differentiating them like In my mind the lack of better handling for block variations in various places is not by design, but more like we haven't done this yet. I understand though that there are many connected pieces with all the APIs and we should be cautious with the APIs introduced or augmented, as we need to have a clear vision of where we want to go. I haven't seen much of the new API for adding/editing the |
|
What if the variation itself declares the styles it supports? For example, in the variation metadata, you'd just add In PHP: register_block_style(
'core/query-block/posts-list', // THE NAME OF THE BLOCK VARIATION
array( 'name' => '...', 'label' => '...' )
);In JS: wp.blocks.registerBlockStyle(
'core/query-block/posts-list', // THE NAME OF THE BLOCK VARIATION
{ name: '...', label: '...' }
);As I understand block variations, they provide a mechanism to "variate" certain aspects of a block. My first instinct is to think that the same mechanism that allows me to define the As I see this, it's about how do we want to scale the block variations API. For example, what if we want to do the same for |
|
I like the proposal from @oandregal here. It's also not clear to me, will Block Variations be able to have the style variation set independently of the main block? A few ways this question applies:
|
Yeah, that was the main ask from #40621 as I understood it: that block variations can each have their own style variations. |
This could work for registering variation-specific styles! How would it be handled in
I feel like I've seen an issue about this already, but can't find it right now 😅 Definitely wouldn't rule it out! |
My take on this is in my above comment .
I think that's a good question, but in general all these are subject to various different APIs(block, variation, style, etc..). I think these might or might not share some concepts, and would need separate evaluation. IMO the combination |
What?
Resolves: #40621
If the approach is deemed good, I'll add tests and docs.
This PR adds support for block styles, for specific block variations.
Testing Instructions
In PHP:
In
block.json. Go togroup/block.jsonand add:In JS:
Notes
If you're adding the style variations with block.json or in JS you should also add the styles in
group/styles.scssGroupblock and some block variations. Observe that the specific styles are shown only on the selected variations(if you have used my examples above, it would bestackandrow).groupvariation)Screenshots
Screen.Recording.2023-04-11.at.8.27.17.PM.mov