Query block setup with block patterns integration #28891
Conversation
ntsekouras
added
Needs Design
|
Size Change: +3 kB (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
|
@jameskoster we might need to prioritize this one #28735 I think what we have in this PR is a great starting point, but I was thinking it'd make sense to have "Patterns + Blank" and when you pick Blank you see the "variations". |
|
This is an excellent start, thanks for integrating patterns! |
| @@ -22,6 +22,9 @@ export const settings = { | |||
| edit, | |||
| save, | |||
| variations, | |||
| isMatchingBlockPattern: ( pattern ) => { | |||
| return pattern.categories?.includes( 'core/query' ); | |||
There was a problem hiding this comment.
Is this something we should make implicit? cc @youknowriad
In the original issue I suggested patterns: [ ...patternCategories ]
There was a problem hiding this comment.
By having a matching function will help us fine-tune the behaviour for different use cases. One thing that I'm almost certain will be needed for different contexts (ex. transforms with patterns) will be to also pass the block's attributes.
In addition, if we proceed with this approach and usage of patterns for initializing blocks, we should probably make a convention about the pattern's category name or even consider to augment the block patterns API to have some more properties. Maybe include the block's name somehow? 🤔
It must be clear for theme/block pattern authors how to make their block patterns shown in this view (block setup)
There was a problem hiding this comment.
For blocks, we have this parent field that allows the author of the block to tell where this block can be inserted. If the idea is similar here, we should try the same approach first. For patterns, it might context or target or something like that. It all depends on how we want to treat this type of pattern that might not make much sense outside of the given block.
One thing that I'm almost certain will be needed for different contexts (ex. transforms with patterns) will be to also pass the block's attributes.
We can always add such a function in the future, for now, it feels like a simple match between the pattern and block should be enough.
One idea to consider in the future, similar to how it works with block variations. We could always register patterns together with a block but with PHP:
register_block_type_from_metadata( __DIR__, array(
'patterns' => array(
$my_pattern, // and so on
),
) );There was a problem hiding this comment.
We can always add such a function in the future, for now, it feels like a simple match between the pattern and block should be enough.
I agree 100% :)
For blocks, we have this parent field that allows the author of the block to tell where this block can be inserted. If the idea is similar here, we should try the same approach first. For patterns, it might context or target or something like that.
For now, without having it explored in depth yet, the augmentation of Patterns API with a new prop makes more sense to me too. One thing that I have in mind is that we will have block patterns that will be used only on block setup, others on transforms etc..
I mention that because there are discussions about transforming a single block to a block pattern which might contain other blocks as well. I think the result would be to replace selected block in pattern and keep the others with their demo content.
This makes it similar with block variations about their scope attribute too. I think we could create a new property in patterns to include block name and such context. An example would be:
[ 'core/query-setup', 'core/buttons-setup', 'core/buttons-transforms'
I'll explore this a lot better after the designs.
lib/load.php
Outdated
| // Demo query patterns. | ||
| register_block_pattern_category( | ||
| 'core/query', | ||
| array( 'label' => __( 'Core Query block', 'gutenberg' ) ) |
There was a problem hiding this comment.
I think the patterns should be called "Post List" or something to that effect
There was a problem hiding this comment.
These are just demo patterns that will not be included in the final code.
|
@tellyworth this one is good to keep an eye on for the pattern directory integration into blocks. |
We could use some design about this and also have in mind how it could be reused by other blocks. |
|
This is what I see:
Powerful! It's also a big placeholder. I'm going to take a quick stab at both a near term and longer term visual for this. Hopefully the near term mockup I can help push some CSS for directly. I'll be back. |
|
Here's a quick exercise. Based on your feedback I will adjust, and when we're happy, I can help push some CSS and we can get a V1 out. Initial setup
"Start empty" state You click "Start empty" in the first step, and you get this screen which you may recognize:
"Start with a pattern" state If you had clicked the primary "Start with a pattern" button, we show patterns right in the placeholder:
The argument for a carousel is that it literally makes them bigger, literally bringing them closer to you. Instead of feeling like you pick a pattern, by being a carouse it feels like you've already chosen a pattern, now you're just paging through options before you confirm. Click the arrow keys to page between the available patterns.
Or click the pattern itself to insert it. Questions
I think there's a lot more we can do to make this flow more intuitive. For example I'd love to potentially start with the pattern browser directly — it helps the placeholder pass the "squint test". But for a V1, and per @mtias thoughts on the flow, keeping it two-step might be a good starting point? |
Yes because the main thing here is the Also we need to have in mind that this could be used eventually in other blocks as well, like I'm a bit concerned about the
|
|
I think the carousel is something we need to discuss further on #28735 etc. |
|
Great thoughts. Here's a quick iteration based on feedback. It all still starts here:
The "Start empty" state is the same, but now has a back button:
The "Patterns" state has a back button, and now shows 3 patterns side by side, click one to use it:
I know that this branch features a scrollbar to afford more patterns. But I have a feeling that if we start with about 6 patterns at most, we can probably avoid it, give or take some responsive considerations. But I think this is best tackled directly in implementation. Depending on additional feedback, I imagine next steps could be that I start helping out with some CSS here? |
|
The "start with a pattern" and "start empty" feels a bit redundant as a step. I think I'd prefer to just show patterns and have blank be a choice among them? We'd need to handle narrow spaces, of course. (Maybe in those cases collapse into a button and show the inserter popup with patterns?) |
|
Thanks for exploring the design for this 💯 Just keep in mind that we will definitely need helper information about the specific If we keep patterns/attributes in one step, we should show the attributes always then. Also the attributes seem to me more important than layout, so it makes more sense to me to be on the top at such an approach. |
|
Here's an iteration based on this feedback:
Start empty still takes you here:
Yep we have |
|
After conversing with Nik, here are some tweaks. He noted that we need the help text for the "Inherit URL query" toggle, which currently has a rather verbose help text:
I can appreciate that, but I think there's an opportunity for a much more contextual and brief, but still descriptive help text. Such as:
I may be missing some nuance in the above verbiage, so feel free to suggest. But having the helptext be conditional to the toggle state, that alone will help make it less overwhelming. Nik noted that there are cases where no patterns exist, or they weren't loaded. In that case, could we go directly to the variations screen?
The alternative becomes rather bare:
Nik also noted that some of the "back button" changes to the placeholder are non trivial to implement. Specifically referring to this screen you get to if you press "Start empty" on the first screen:
An alternative has a non-integrated back button:
Here's what the setup state could look like on mobile, or in narrow contexts (such as inside a column):
|
|
cc @shaunandrews @tellthemachines |
To an extent, we have it with this:
The tricky challenge is that we can't use a giant white sheet for the navigation block, because it's almost never that big itself. Or to put it differently, the setup state should ideally never be bigger than the configured state. I think there's an opportunity to revisit navigation with patterns directly inline, which would potentially be able to resize the setup state based on the size of the pattern you pick. @jameskoster just mocked up such a pattern carousel for the Query block, but presumably it could scale down to the navigation block also. |
I think it could work! But I also think we need to do some dedicated exploration around how the patterns paradigm translates to navigation in general. |
We will probably need a modal at some point anyway, for the narrow viewports or contexts. |
I placed it at the end. |
ntsekouras
requested review from
ajitbohra,
ellatrix,
spacedmonkey and
TimothyBJacobs
as code owners
|
I pushed a fix to put the titles outside of the box:
To address this one:
@ntsekouras can we do this?
|
|
Alright I pushed some polish:
There are so many opportunities to polish this further — the icons aren't all that great, and the two-step layout maybe isn't ideal. But I think it's in a place no where it can be shipped, and be useful for a couple of releases, until we revisit this. |
|
Agreed on getting a baseline in place |
|
cc/ @simison -- The new block patterns API that this PR introduces might make sense for migrating some Gutenboarding (and/or WP.com block patterns) functionality to it. |
Description
Resolves: #27031
Related: #27575
This PR will enhance the initialisation of
Queryblock, by setting up someattributesand selecting a startinglayouteither by usingblock variationsorblock patterns(some blocks to insert in theQuery Loop).For now we can select some basic attributes, which for now is the most important one
inheritglobal query, and set accordingly thepost typeof the Query block.Block patterns integration
Since there are plans to integrate block patterns in different contexts (examples are setup context like the this PR, or transform context in Block Switcher later) we need to make sure it's clear for theme/block pattern authors how to make their block patterns available in each context/view.
The proposed API
There are many similarities here to block variations, so I introduced in block patterns API a new property called
scope.This property will be an object with the available scopes as keys, like
inserter, block(for Placeholder)etc..inserterwill bebooleanand theother scopesarrayswith theblock namesas values. This way patterns could be filtered in a rather generic way, with the new selector__experimentalGetScopedBlockPatterns.example in a pattern:
If a block pattern has not set a
scope, it will be handled as havinginserterset totruefor backwards compatibility.I understand that patterns can have many blocks, but this will make it explicit where to show what and it's going to be more performant.
Let's look at this with an example.
We have a pattern that includes blocks:
Columns, Image, Buttons, Quote , Paragraph.Without an explicit API, we will have to parse patterns to try to find matching blocks (performance).
The above pattern even though it might contain 5 blocks, it might be focused on the
Columns and/or Imageand we don't want to show it in theQuoteblock's related actions. This could be the exact opposite of course by focusing only inQuotefor something like testimonials.I'm not sure though how we will handle transforms eventually as it's a different operation than an initialization.
Showcase
Before
After
Notes
indextemplate. This should be handled with examples probably like thePost Title.Checklist: