Block API: Allow "array of attributes to be compared" for isActive property in block variations #30913
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +4.04 kB (0%) Total Size: 1.47 MB
ℹ️ View Unchanged
|
david-szabo97
changed the title
david-szabo97
changed the title
david-szabo97
added
[Feature] Block Variations
david-szabo97
requested review from
ajitbohra,
chrisvanpatten and
ellatrix
as code owners
david-szabo97
requested review from
vindl,
jeyip,
mattwiebe,
Addison-Stavlo,
Copons,
creativecoder,
ntsekouras,
gziolo and
ockham
ntsekouras
reviewed
Apr 19, 2021
There was a problem hiding this comment.
Thanks for working on this @david-szabo97! 💯
In general this looks good. I haven't checked the tests you wrote for now, but I will after addressing the main thing about attributes validation.
gwwar
reviewed
Apr 19, 2021
There was a problem hiding this comment.
This looks pretty close @david-szabo97! I think this should be good to go once PR checks are ✅ and folks' feedback is addressed.
| const blockType = getBlockType( state, blockName ); | ||
| const attributeKeys = Object.keys( blockType.attributes || {} ); | ||
| return variation.isActive | ||
| .filter( ( attribute ) => attributeKeys.includes( attribute ) ) |
There was a problem hiding this comment.
Optional: Would it be worth validating this earlier during block registration? It might be nice for folks to know that something isn't quite right when developing blocks.
There was a problem hiding this comment.
Actually that's what I had in mind too in my first comment. This way we will avoid calling this check so many times.
There was a problem hiding this comment.
Good point! First iteration is here: 637b62b
| .every( | ||
| ( attribute ) => | ||
| attributes[ attribute ] === | ||
| variation.attributes[ attribute ] |
There was a problem hiding this comment.
I think we'll still want to return false if either of these values is undefined. Blocks and variations may have optional attributes.
There was a problem hiding this comment.
I can't come up with a case for this 🤔 It seems to be working as expected:
- If both of them are
undefined, then that's correct and should match. - If
variation.attributes[ attribute ] = undefinedandattributes[ attribute ] != undefinedthen it won't match - If
variation.attributes[ attribute ] != undefinedandattributes[ attribute ] = undefinedthen it won't match
There was a problem hiding this comment.
@gwwar can you expand on the use case you have in mind with an example?
There was a problem hiding this comment.
Sorry, I missed 👀 that we were already iterating over variations instead of all possible block attributes, so only the left side may be undefined, eg attributes[ attribute ]. Code here is fine 👍
btw I personally find that code reuse in tests isn't that useful. What's nicer for me is being able to read a single test case without needing to skip to different definitions. (Fixtures/snapshots can also help when things go crazy). Curious if folks had thoughts on that.
Here's a free test case, where I verified this:
it( 'should handle optional attributes', () => {
const testLinkName = 'test/link-block';
const state = {
blockTypes: {
[ testLinkName ]: {
name: testLinkName,
attributes: {
url: { type: 'string' },
type: { type: 'string' },
id: { type: 'number' },
},
},
},
blockVariations: {
[ testLinkName ]: [
{
attributes: { url: 'https://wordpress.org' },
isActive: [ 'url' ],
},
{
attributes: { type: 'foo' },
isActive: [ 'type' ],
},
{
attributes: {
type: 'bar',
url: 'https://example.com',
},
isActive: [ 'type', 'url' ],
},
],
},
};
expect(
getActiveBlockVariation( state, testLinkName, {
type: 'foo',
} )
).toEqual( {
attributes: { type: 'foo' },
isActive: [ 'type' ],
} );
expect(
getActiveBlockVariation( state, testLinkName, {
url: 'https://wordpress.org',
} )
).toEqual( {
attributes: { url: 'https://wordpress.org' },
isActive: [ 'url' ],
} );
expect(
getActiveBlockVariation( state, testLinkName, {
type: 'bar',
url: 'https://example.com',
} )
).toEqual( {
attributes: {
type: 'bar',
url: 'https://example.com',
},
isActive: [ 'type', 'url' ],
} );
expect(
getActiveBlockVariation( state, testLinkName, {
id: 1234,
} )
).toEqual( undefined );
} );There was a problem hiding this comment.
Yeah, I had that in mind too. 😄 That's why the last tests are totally separate. Definitely needs some cleaning. A little bit of reuse doesn't hurt though 😄
There was a problem hiding this comment.
A little bit of reuse doesn't hurt though
Certainly, I wanted to leave a note since I was having a bit of trouble reading what the state shape was without inspecting tests.
gwwar
approved these changes
Apr 21, 2021
There was a problem hiding this comment.
This looks solid to me @david-szabo97 ✨ Thanks for taking this one on!
I found another area where we should update before landing, which is the type definition in
gutenberg/packages/blocks/src/api/registration.js
Lines 104 to 111 in 3e14c5e
🤔 Optional/followup: I wonder if there's a way to get this typedef to help generate the block-variations.md. We do have support for autogenerating other examples with <!-- START TOKEN(Autogenerated API docs) --> and npm run docs:build
@gziolo @ntsekouras were there any other blocking changes needed here?
|
@gwwar, I will do a cross-check shortly. There is one follow-up that I can think of, it's changing API schema for block types in WordPress core to account for isActive as an array. In addition to that, we should be able to know to define |
gziolo
reviewed
Apr 21, 2021
gziolo
approved these changes
Apr 21, 2021
ntsekouras
requested changes
Apr 21, 2021
There was a problem hiding this comment.
Thanks @david-szabo97 ! A last change that is needed and let's land.
david-szabo97
commented
Apr 21, 2021
| dispatch( blocksStore ).addBlockTypes( settings ); | ||
|
|
||
| return settings; | ||
| } | ||
|
|
||
| function validateVariations( settings ) { |
There was a problem hiding this comment.
I'm not really sure where to put this. 😄 I'm also wondering why don't we dispatch( blocksStore ).addBlockVariation( settings.variations ) instead of handling variations here:
For this reason we need to do the variations validation in two functions.
There was a problem hiding this comment.
Can we extract it to another PR? It isn't a blocker really and it requires some more thinking because you can register block variations also through the store directly. I don't remember exactly but most likely they are stored in two places in the store. It's similar to how block styles can be registered, so plugin authors could register styles or variations before the block gets registered so plugins wouldn't have to declare dependencies on each other.
There was a problem hiding this comment.
That makes sense. I didn't know it meant to be that way - registering variation even without an existing block type. This comes with its own challenges 😄
I revert the commit.
There was a problem hiding this comment.
I double-checked, it's stored in one reducer but you can add variations with ADD_BLOCK_TYPES or ADD_BLOCK_VARIATIONS 😄
7 tasks
gziolo
added
the
[Type] New API
gziolo
changed the title
gziolo
changed the title
gziolo
added
[Feature] Block API
gziolo
changed the title
lipemat
added a commit
to lipemat/types-js-boilerplate
that referenced
this pull request
May 19, 2021
Instead of a callback, you may pass an array of attributes which are checked against the block to see if this variation is active. WordPress/gutenberg#30913
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #30739
Description
Extends the variations API by adding one more possible way to define how active variations are recognized.
The only way currently in
trunkis to use anisActivefunction. In this PR we introducearray of stringsforisActiveproperty.Most of our variations use the following pattern:
gutenberg/packages/block-library/src/embed/variations.js
Lines 347 to 352 in 4b14897
As you can see, we are just creating a function for each variation and check for a specific attribute whether it matches or not. Basically, this is what we do for (almost) all of our variations so far.
To reduce boilerplate code, we can now use an array of strings to do the same check behind the scenes:
Every element in the array represents an attribute to be compared. If each attribute matches then it is considered active. For example:
translates to
How has this been tested?
Tests should pass
Smoke test, make sure all blocks using variations are still working as before
Replace
gutenberg/packages/block-library/src/social-link/variations.js
Line 314 in 4b14897
with
Make sure Social Link block still works the same way as before.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).