You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally, Gutenberg blocks should be small, unique representations of content with very simple functionality.
In keeping with this philosophy, we must try to break up common block patterns into smaller component parts.
We'll start to notice the pattern of selecting and looping through stored data, which is entirely configured and implemented separately for any block that needs it, like Latest Posts or Archive.
I suggest that we split this functionality into a separate Query block, where a query can be built in a consistent way for any block that needs a query.
If Gutenberg had its own intuitive, feature-complete query building mechanism, then other plugins wouldn't have to reinvent the wheel, which causes bugs and usually lacks features.
Description
A query block, when selected, would show query building settings in the block settings sidebar.
A query block can wrap any other block(s).
In order to inject data from the loop (post title/meta, etc.), we'll need to have an inline "slot" mechanism where the necessary attributes can be specified and injected.
A query block will repeat the child block layout once all necessary slots have been filled.
So, if we have a query block with 3 columns and each column contains a "post title" slot, then we get n / 3 rows with 3 columns, each column containing a post title.
Or, if we have query block with just a single "post title" slot child, then we'll get n rows of post titles.
Slots
Slots should render to some sort of template string (like %post.title%), which can be string replaced by the loop at runtime.
The benefit of using a template string is that advanced users can manually inject these template strings into existing block content/settings/attributes and they will be string replaced in the exact same way.
For example, you could create a query with a nested Link block and set the link URL to /example/%post.type%/
Some blocks, like images, don't have a string parameter to easily inject a slot into, so there's no way to tell the image block to show the current post thumbnail for example.
This could be solved by allowing a slot block to accept a child.
An image block could be placed inside a slot and the slot would take on the image block's attributes, allowing them to be slotted out.
This would also allow us to put a query block inside a slot, which gives us a powerful means of building nested queries.
The text was updated successfully, but these errors were encountered:
Hi @rchipka I am going to add a question label to this as I feel that it would be good to get others input on this. Thanks for thinking about how blocks work.
Thanks for the suggestion. The idea is we consolidate this in the component for query controls but without exposing it as a block to the user (which would be too technical). All blocks showing posts in some form could use the underlying Query component and expose consistent set of attributes for manipulation. Furthermore, a single "post" or "page" block would be a nice addition for phase 2.
Ideally, Gutenberg blocks should be small, unique representations of content with very simple functionality.
In keeping with this philosophy, we must try to break up common block patterns into smaller component parts.
We'll start to notice the pattern of selecting and looping through stored data, which is entirely configured and implemented separately for any block that needs it, like Latest Posts or Archive.
I suggest that we split this functionality into a separate Query block, where a query can be built in a consistent way for any block that needs a query.
If Gutenberg had its own intuitive, feature-complete query building mechanism, then other plugins wouldn't have to reinvent the wheel, which causes bugs and usually lacks features.
Description
A query block, when selected, would show query building settings in the block settings sidebar.
A query block can wrap any other block(s).
In order to inject data from the loop (post title/meta, etc.), we'll need to have an inline "slot" mechanism where the necessary attributes can be specified and injected.
A query block will repeat the child block layout once all necessary slots have been filled.
So, if we have a query block with 3 columns and each column contains a "post title" slot, then we get
n / 3
rows with 3 columns, each column containing a post title.Or, if we have query block with just a single "post title" slot child, then we'll get
n
rows of post titles.Slots
Slots should render to some sort of template string (like
%post.title%
), which can be string replaced by the loop at runtime.The benefit of using a template string is that advanced users can manually inject these template strings into existing block content/settings/attributes and they will be string replaced in the exact same way.
For example, you could create a query with a nested Link block and set the link URL to
/example/%post.type%/
Some blocks, like images, don't have a string parameter to easily inject a slot into, so there's no way to tell the image block to show the current post thumbnail for example.
This could be solved by allowing a slot block to accept a child.
An image block could be placed inside a slot and the slot would take on the image block's attributes, allowing them to be slotted out.
This would also allow us to put a query block inside a slot, which gives us a powerful means of building nested queries.
The text was updated successfully, but these errors were encountered: