Previous short discussion with @rogovdm and @oliviertassinari :
https://github.com/callemall/material-ui/pull/5808#issuecomment-272288692
I would like to revisit the idea of showing or hiding <Layout item/> based on the grid breakpoints. In my sample screenshot:
lgmdsmxs
<Layout container>
<Layout item align='center' container xs={1}>
<ContactAvatar contact={c} className={classes.avatar} />
</Layout>
<Layout item align='center' container xs>
Kevin Ross
</Layout>
<Layout item align='center' container sm>
[email protected]
</Layout>
<Layout item align='center' container md>
+16155551212
</Layout>
<Layout item align='center' container lg>
AlienFast, LLC
</Layout>
<Layout item align='center' container justify='flex-end' lg={2} direction='row' lg>
<IconButton>
<Icon>edit</Icon>
</IconButton>
<IconButton>
<Icon>more_vert</Icon>
</IconButton>
</Layout>
</Layout>
As-is, I would expect that <Layout item align='center' container lg> would only show up on large screens, and would disappear on anything smaller. This doesn't occur though, all items remain visible.
There could be many ways to tackle this, but we should first agree that the ^^example seems like an intuitive way to show items responsively.
xs). xs md={false} it will show on xs and up, but _not_ on mdAssuming the proposed solution above makes sense, I've been looking at implementation. It seems that while Layout could handle this, and indeed should from an API brevity standpoint, the idea that we could use helper components makes much sense. Again, assuming the proposed solution above is how Layout will behave, I think we should implement:
Visible and Hidden similar to react-grid-system. It seems like we could make use of withWidth in these and avoid rendering entirely (don't use css) if children shouldn't show. The only question is if a ton of withWidth components would be more or less of a performance burden than css media queries.The xs, sm, md, lg, xl properties have never been designed with the hide/show use case in mind. They are solving a positionnement problem, for instance pushing an element at the end:
<Layout container>
<Layout item xs>
Left
</Layout>
<Layout item>
Right
</Layout>
</Layout>
What about using a different property for that hide/show use case?
It seems like we could make use of withWidth in these and avoid rendering entirely (don't use css)
I would rather not use withWidth because of the server-side rendering constraint. This HOC don't play well in that case. He has to render nothing in order not to break SSR.
Visible and Hidden similar to react-grid-system.
Oh, I like that solution! What about having a <Responsive /> component with the API you are describing?
LOL, I just got your message - I was coding the withWidth solution and spec. Here is Visible.
Similar to withWidth, I render nothing. Are you saying this is bad for SSR?
I like the idea of having visible or hidden. But why is it necessary to create a new Component for that. Why just not additional props to the Layout component like hide-xs, hide-sm ... or visible-xs, visible-sm, visible-md ... similar to material.angualar
@rosskevin What I'm saying is that when using withWidth with SSR, nothing will be rendered by default on the server, we wait to actually know the size of the window to render the content. That means you gonna have one flash of moving content.
Still, what do you think of supporting both implementations?
One using JS and the other one using CSS. They both of their weakness. We have seen the one of the JS implementation.
Now, let's consider you want to display a Google Map only for your desktop users, using the CSS implementation would mean paying credit for mobile users too while you don't need it (a specific need @julien-meichelbeck had at the office).
@stunaz A new component would provide more flexibility, similarly to what Bootstrap is doing, a hide/show logic can be needed independently of the Layout.
Some other cool thing I have seen on my twitter feed yesterday.
Actually, Bootstrap API is pretty smart:
There are no explicit “visible”/”show” responsive utility classes; you make an element visible by simply not hiding it at that breakpoint size.
No need for a Visible and Hidden component. We only need one of the two. So, which one is the most intuitive? I think that it's the one that breaks with the default behavior (visible), hence hidden. What about a <Hidden /> component with the following properties?
xsUp, smUp, mdUp, lgUp, xlUp (default to false)xsDown, smDown, mdDown, lgDown, xlDown (default to false)implementation: ['css', 'js']The second nice thing about this API is that you don't have to enable each screen size you want to show or hide, you will most of the time needs a single property switch to true.
@oliviertassinari you right, never thought of that
Hidden component submitted as PR.
With regard to exposing it with Layout what are the thoughts on the API?
xsUpHidden and xsDownHidden?hiddenXsUp and hiddenXsDown?Other thoughts?
I have no idea what's best here, sorry I'm not good at naming things, I can't help.
PR'd implementation. Watchers please look at the API exposed.
Some stuff we could do to go further
FYI -
Filed issues, working on the demo and finished the only expansion.
@rosskevin Hi, I wanted to know if this feature is already available to use on material-ui v1. Thanks!
@andreacornaglia Yes, it's. You can find the docs here https://material-ui-next.com/layout/hidden/.
How to programmatically set xsUp and xsDown in Hidden element?
Most helpful comment
Actually, Bootstrap API is pretty smart:
No need for a Visible and Hidden component. We only need one of the two. So, which one is the most intuitive? I think that it's the one that breaks with the default behavior (visible), hence hidden. What about a
<Hidden />component with the following properties?xsUp,smUp,mdUp,lgUp,xlUp(default tofalse)xsDown,smDown,mdDown,lgDown,xlDown(default tofalse)implementation: ['css', 'js']The second nice thing about this API is that you don't have to enable each screen size you want to show or hide, you will most of the time needs a single property switch to
true.