-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat(ResponsiveLayout): nested ResponsiveLayout background takes precedence #909
feat(ResponsiveLayout): nested ResponsiveLayout background takes precedence #909
Conversation
Size stats
|
Accessibility report ℹ️ You can run this locally by executing |
Deploy preview for mistica-web ready! ✅ Preview Built with commit 6b93cc7. |
Screenshot tests report ✔️ All passing |
src/responsive-layout.css.ts
Outdated
@@ -6,57 +6,52 @@ import {vars as skinVars} from './skins/skin-contract.css'; | |||
export const MOBILE_SIDE_MARGIN = 16; | |||
export const TABLET_SIDE_MARGIN = 32; | |||
export const SMALL_DESKTOP_SIDE_MARGIN = 40; | |||
export const LARGE_DESKTOP_MAX_WIDTH = 1224; |
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.
you have broken the large desktop max width:
try this snippet in master and in your branch playroom:
<ResponsiveLayout>
<Placeholder/>
</ResponsiveLayout>
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.
Ok, I'll check, and add a test for this case, to better cover this situation.
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.
yes it would be nice to have some screenshot tests for these cases too
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.
@pladaria this !!
}, | ||
}, | ||
selectors: { | ||
'& &': { |
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.
This causes a bug, that is already broken in master: if you place a <ButtonFixedFooterLayout>
inside a <ResponsiveLayout>
the footer paddings are broken because the internal <ResponsiveLayout>
stops working.
I've detected some cases in webapp, where some developers are trying to workaround it by adding their own paddings by hand 🤦 because they don't know the problem is the nested <ResponsiveLayout>
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.
ok, I'll try to fix that ;)
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 please post here a code snippet for the playroom that reproduces the issue ?
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.
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.
@atabel is it the same problem with sheets?
https://tinyurl.com/yqdcvsuf
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've fixed using couple css variables, I don't know if there is any better option, any advice welcome.
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.
hmmm... I think the css variables approach is too convoluted. I'd prefer a prop in <ResponsiveLayout>
to disable the special nesting behavior in the cases we know we don't want it (fixedFooter, dialogs, etc). If we don't want to make that prop public we could have an InternalResponsiveLayout
that accepts that prop, ResponsiveLayout
would just be a wrapper of InternalResponsiveLayout
without the additional prop
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.
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 would go for a different component, for internal responsive layout, becuase it wont needs to handle large desktop extra margins, for example (that makes everything lot complex).
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.
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.
I didn't see any weird behavior in multiple tests that I tried, LGTM.
Grande, boyscout🌝
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 sorry but I don't like this. These are a bunch of workarounds to allow compositions that should be forbidden.
ResponsiveLayouts shouldn't be nested. This is not an issue of the component, it is a problem from the part that uses this component to compose pages or sections in unexpected ways.
If I understand this PR, now you can place ResponsiveLayouts inside dialogs, sheets, footers, other ResponsiveLayouts... It makes no sense to me.
Perhaps the modules shouldn't use a ResponsiveLayout and it should be added by the piece that composes those modules when needed. I guess I'm missing a lot of context about your needs and your implementation details.
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 agree, I don't like nested ResponsiveLayouts either, and I think we should found a way to avoid that. But this PR is not about that, we already supported nested ResponsiveLayouts but we had a bug with background color that this PR fixes.
If we want to discuss a better approach for modular pages in novum webapp or other use cases where we are nesting ResponsiveLayouts, ok. But I'd keep that discussion outside of this PR
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.
Yes, its another discussion, we can talk about that. This PR gets enmarronated because the large desktop extra margins, this makes everything worse, if we had another component, or a prop to specify that we should add these extra magins, the component would be really small and simple.
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 I understand this PR, now you can place ResponsiveLayouts inside dialogs, sheets, footers, other ResponsiveLayouts... It makes no sense to me.
This is because of the large desktop extra margins :(
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.
Implemented the props approach to fix the button fixed footer layout bug.
{id: 'layout-responsive-layout--default', device: 'MOBILE_IOS'}, | ||
{id: 'layout-responsive-layout--default', device: 'MOBILE_ANDROID'}, |
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'd remove one of these. Testing iOS/Android doesn't give any value in this component, the relevant thing here is the screen size. Having different tests for Android/iOS makes sense in components that change betwen platforms, like the Switch
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.
ok !! fue un copy paste leftover XD
src/responsive-layout.css.ts
Outdated
[mq.desktop]: { | ||
margin: `0 calc(-1 * ${sideMargin})`, | ||
}, |
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.
isn't this mq redundant? it's like the default case
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.
oooh yes, this is a leftover, thanks !!
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.
removed
{id: 'layout-responsive-layout--default', device: 'DESKTOP'}, | ||
{id: 'layout-responsive-layout--default', device: 'DESKTOP', viewport: {width: 1368, height: 770}}, | ||
{id: 'layout-responsive-layout--nested', device: 'MOBILE_IOS'}, | ||
{id: 'layout-responsive-layout--nested', device: 'MOBILE_ANDROID'}, |
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.
remove this one too
🎉 This PR is included in version 14.28.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
No description provided.