-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
Product Collection: Migrate displayLayout
To supports.layout
#46255
base: trunk
Are you sure you want to change the base?
Changes from 6 commits
2d59a39
e842e92
e847a6d
97ea00a
2e4ad27
cc126cf
991b5f9
e9b45f1
2d0a30f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When switching between Auto and Manual modes, there is a noticeable flickering in the UI, as captured video below. Is it possible to fix it? 🤔 Screen.Recording.2024-04-05.at.2.22.27.PM.movThere was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be honest, I'm not sure what causes this! @kmanijak had an idea but that didn't seem to make a difference. For what it's worth, regarding Karol's comment, I don't think this ever caused unnecessary re-renders in the first place. Do you have any ideas about what might be happening here? We're changing the control based on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we can fix it while addressing #46255 (comment) below. For example, refactoring the code as follows could potentially resolve the flickering issue: <ToolsPanelItem
label={ minimumColumnWidthLabel }
hasValue={ () => true }
isShownByDefault
>
{ isAutoColumnLayout ? (
<UnitControl
label={ minimumColumnWidthLabel }
value={ templateLayout.minimumColumnWidth as string }
onChange={ onMinimumColumnWidthChange }
/>
) : (
<RangeControl
label={ columnCountLabel }
onChange={ onColumnCountChange }
value={ templateLayout.columnCount as number }
min={ 2 }
max={ 6 }
/>
) }
</ToolsPanelItem> I haven't delved deeply into it, but my initial thought is that the flickering may result from the conditional rendering of the |
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.
Nit: When a new block is added to the post, the default COLUMN MODE is Manual. It would be better if we could change it to "Auto" because we want to keep the block responsive by default 🙂
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 think that currently the caveats to "Auto" warrant using "Manual" by default. As we figure out what responsiveness looks like with this layout option we can re-asses. How does that sound?
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.
Just checking in case I missed it earlier, but could you please clarify the specific caveat you're referring to?
If I recall correctly, we've had this discussion before and decided to make the block responsive by default. With that in mind, I believe we should aim to maintain responsiveness if possible. IMO, sticking with manual might not offer the best user experience across different device sizes.
CC: @kmanijak
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.
As it stands, the
supports.layout
option only supports a staticcolumnCount
or a dynamicminimumColumnWidth
. There is currently no way to combine these two into a minimum width with a maximum number of columns in the way that our custom layout does. I did find a workaround (the custom CSS in the migration) but want to get confirmation from Gutenberg before moving forward with that and getting responsiveness working again.If Gutenberg indicates that the solution won't be supported long-term then we will need to decide whether or not to move forward with this migration. Ultimately, if they don't agree, the only "responsiveness" supported by Gutenberg in this case would be the
minimumColumnWidth
which has no maximum column count.Think of this PR as a deeply researched PoC 😄
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.
🙌🏻
If they don't agree! I believe we will need to discuss this with @jarekmorawski before making a decision 🙂
Yeah! I can see that. Well done! 😀🚀
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.
Yep! I'm just waiting to have some certainty around what that is or whether there is one to make!