Introduce the layout prop to InnerBlocks #26380
Conversation
youknowriad
added
[Feature] Block API
youknowriad
requested review from
ajitbohra,
ellatrix,
Soean and
talldan
as code owners
youknowriad
force-pushed
the
add/layout-api
branch
from
ad823ee to
9db2619
Compare
|
Size Change: +32 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
|
Love it. Whether grid or flex or vanilla, just like how HTML and CSS handles it, blocks just like elements are laid out according to rules. Being able to surface some of those in a UI friendly and abstracted way, I believe, can provide some amazing layouts, and as you suggest, even refactor and simplifiy some of the structures currently in place. (CC: @shaunandrews because you were thinking about flex the other day)
This feels like it could be the technical underpinning for the effort being explored in #16998, that ticket suggesting the layout controls being attached to a "Site" or "Area" block. Would you agree? |
Yes, for me any container whether it's the "site", a specific "area" or a random "group" block should be able to "change" the rules for its children. Surfacing these options on the UI is another question though, it could be a "block choice" (choose a group, a flex container or an area) or it could be an option/UI to change the layout per block... these are all things that could be possible here and that we'd have to explore. |
| }; | ||
| } ); | ||
| const layout = useLayout(); | ||
| const supportsAlignments = layout.type === 'default'; |
There was a problem hiding this comment.
Is there a reason to check the type === default and not check explicitly for alignments. I'm trying to understand your changes (haven't thoroughly yet :) )
In my head for now, I understand that we could have the new property layout filled with any property we would like and handle that new property per Block/use case.
For example if I would like to have a grid layout, should I add something like:
__experimentalLayout: { type: 'grid', ...other options }
or just
__experimentalLayout: { grid: { columns: 3 } }
Am I missing the concept entirely?
There was a problem hiding this comment.
exactly and other types of layouts might not have "alignments" support at all, so we bail out early for these.
There was a problem hiding this comment.
I'm not sure where your exactly goes :) That I'm missing the concept or is related in something for the above grid examples? :)
I still didn't understand if for checking alignment, we would need both type and another property alignments, or just one property alignments would be enough.
There was a problem hiding this comment.
alignments might not even exist in some layouts, the shape of the "layout" object depends on the type. Also, alignments on other layouts could have a completely different meaning. Basically the alignments as we know them today only make sense in the default layout, so we need to check the type first.
|
#17275 could also benefit from this. |
|
So what do you think folks? Should we move forward with this experimental API and see how we can leverage it for all these use-cases? |
I am very interested; I’ve been already toying with it a little bit. I can’t assess its reach fully yet, but I’d like to try at least to implement a grid layout with this. |
|
Ok, let's try this. @vcanales please do explore a grid layout with this and let me know how it goes. |
InnerBlocks as they stand today come with a number of assumptions about how their child blocks are laid out:
This PR introduces a new prop/concept to inner blocks called
layoutand absorbs these assumptions into a "default" layout. The idea is that alternative layouts could be introduced to support different ways to layout the children blocks inside a container.The PR also replaces the experimental
AlignmentHookSettingsProvidercontext that was used in the Buttons block to remove alignments from the regular "core/button" block and makes the allowed alignments a property of the default layout: This will allow us to solve the pitfalls mentioned above allowing wide alignments in contexts where they don't make sense.The vision
Positioning and laying out elements in HTML requires two things in general:
1- A definition of the layout strategy at the container level (think display: grid, display: flex or something else)
2- A property per children to define how it is specifically laid out.
Currently, in Gutenberg 1 is assumed as a regular default block container and sometimes tweaked adhoc in CSS. And 2 is in general implemented in blocks using the align attribute (wide, full, left, right). While this decent enough for the "default" layout, I'm thinking this behavior can be made more generic and more controlled:
positionattribute which format differ between layout types: In the default layout, it could correspond to the current "align" attribute use in most blocks, in an absolute layout, it can be a {top, left, width, height} record, in a grid layout, it could be things like (area, start, end). And moving a block outside its current container should reset thepositionattribute.Current state of the PR
It introduces an experimental layout concept, it allows tweaking the available alignments for the default layout per container, It's a starting point that is not engaging for the future as it doesn't introduce any change in behavior, or any public API yet.