-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: [Block Library - Social Icons]: Make the block use the new flex
layout
#33987
Conversation
Size Change: -833 B (0%) Total Size: 1.03 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach is looking good to me overall, Left some remarks.
const defaultLayout = useSetting( 'layout' ); | ||
const { layout } = attributes; | ||
// TODO: check if a theme should provide default values per `layoutType`. | ||
// Fow now we use the values from `flow` (content, width). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now the default layout value in theme.json
has not a type
prop. It assumes it is the default/flow
layout and this is how it is used for example in Group
block. With the expansion of new layouts wouldn't we want themes to provide some defaults for other layouts as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my mind, the theme provides a single default layout and chooses its type and doesn't provide defaults for all layouts. The default layout is automatically used in the post editor canvas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the provided by the theme default should be only about flow
layout, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe a theme would want to use a "grid" layout by default or some other layout we didn't build yet but yeah in most cases, it will be a "flow" one I think.
[ clientId ] | ||
); | ||
|
||
const usedLayout = !! layout || getDefaultBlockLayout( name ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this logic is something that I wanted to do automatically in the hook for existing blocks using "layout", the problem is that we don't have a filter for InnerBlocks
to do it. Maybe we should introduce an unstable filter to be able to inject the layout prop into InnerBlocks.
$style .= 'column-gap: 0.5em;'; | ||
$style .= 'align-items: center;'; | ||
$style .= "justify-content: $justify_content;"; | ||
$style .= '}'; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was expecting more changes here to retrieve the "default layout" from the block support config and apply it when the "layout" attribute is empty.
|
||
const usedLayout = layout ? layout : defaultBlockLayout || {}; | ||
const { inherit = false, type = 'default' } = usedLayout; | ||
const layoutType = getLayoutType( type ); | ||
|
||
const onChangeType = ( newType ) => | ||
setAttributes( { layout: { type: newType } } ); | ||
setAttributes( { layout: { type: newType } } ); // TODO needs checking with block defaults. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure yet 😄 . I'm adding some comments to check it more when the time comes. I just thought I should check if we would need to add the defaultBlockLayout
props if exist as well, because this line will trigger a rerender and the logic is if layout
is truthy. Therefore I'm not sure it will behave properly.
Looks like we already landed a few things from this PR, should we try to refresh it maybe? Is this still on your radar? |
Yes it is. I'm catching up with stuff and I plan on working on this soon. |
Per a recent nav block refactor to use gap (#32367), I'd love to take it a step further and leverage the new layout controls and theme.json provided gap definitions. So if you need any of my help on this one, I'd be happy to! |
I've created a new PR for this here: #33987. I'll add to the new PR a couple of comments that were not answered to continue the discussions there. |
Description
Related to: #33359
This PR is in very early stage, super rough 😄 and tries to explore the new
flex layout
to be used bySocial Icons
block. These explorations will result in discussions about finding the best approach to utilizelayout
to existent blocks likeButtons
etc..I'll update the PR's description with my observations and questions. For now I've some comments in the code, for early reviewers.
Notes
Social Icons
block and I'll create a separate issue for it, regardingitemsJustification
attribute which was introduced in Add Items Justification to Social Links #28980 and wasn't declared in block.json.trunk
if you select the block, the alignment is different than the one applied at the end (it usesflex-start
.Early testing instructions
Social Icons
block and in Inspector controls play with the justify content control which has icons for now 😆