Skip to content
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

[Layout] responsive-based visibility of items #6726

Closed
rosskevin opened this issue Apr 27, 2017 · 16 comments · Fixed by #6754
Closed

[Layout] responsive-based visibility of items #6726

rosskevin opened this issue Apr 27, 2017 · 16 comments · Fixed by #6754
Labels
component: Grid The React component. new feature New feature or request

Comments

@rosskevin
Copy link
Member

rosskevin commented Apr 27, 2017

Problem description

Previous short discussion with @rogovdm and @oliviertassinari :
#5808 (comment)

I would like to revisit the idea of showing or hiding <Layout item/> based on the grid breakpoints. In my sample screenshot:

  • display all items for a lg
  • display name/email/phone for md
  • display name/email for sm
  • display name for xs

contact-list

Code

<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>
    kevin.ross@test.fake.com
  </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.

Proposed Solution

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.

  • If you don't specify a responsive breakpoint, it will show on all sizes (effectively xs).
  • If you specify a responsive breakpoint, it only shows on that size and up.
  • If you specify xs md={false} it will show on xs and up, but not on md
@rosskevin rosskevin added component: Grid The React component. next new feature New feature or request labels Apr 28, 2017
@rosskevin
Copy link
Member Author

rosskevin commented Apr 28, 2017

Implementation

Assuming 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:

  1. 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.
  2. Layout will implement behavior outlined in proposed solution by rendering with a helper as needed.

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 28, 2017

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?

@oliviertassinari
Copy link
Member

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?

@rosskevin
Copy link
Member Author

rosskevin commented Apr 28, 2017

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?

@stunaz
Copy link
Contributor

stunaz commented Apr 29, 2017

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

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 29, 2017

@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.

@oliviertassinari
Copy link
Member

oliviertassinari commented Apr 29, 2017

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.

@stunaz
Copy link
Contributor

stunaz commented Apr 29, 2017

@oliviertassinari you right, never thought of that

@rosskevin
Copy link
Member Author

rosskevin commented May 1, 2017

Hidden component submitted as PR.

With regard to exposing it with Layout what are the thoughts on the API?

  1. xsUpHidden and xsDownHidden?
  2. hiddenXsUp and hiddenXsDown?

Other thoughts?

@oliviertassinari
Copy link
Member

oliviertassinari commented May 1, 2017

Nice PR 👍.

I have no idea what's best here, sorry I'm not good at naming things, I can't help.

@rosskevin
Copy link
Member Author

PR'd implementation. Watchers please look at the API exposed.

@oliviertassinari
Copy link
Member

oliviertassinari commented May 2, 2017

Some stuff we could do to go further

  • Add a demo as a guide how to use the feature
  • Implement the CSS version

Sorry, something went wrong.

@rosskevin
Copy link
Member Author

FYI -
Filed issues, working on the demo and finished the only expansion.

@andreacornaglia
Copy link

@rosskevin Hi, I wanted to know if this feature is already available to use on material-ui v1. Thanks!

@oliviertassinari
Copy link
Member

oliviertassinari commented Oct 11, 2017

@andreacornaglia Yes, it's. You can find the docs here https://material-ui.com/layout/hidden/.

@amber-m-o-r-e
Copy link

How to programmatically set xsUp and xsDown in Hidden element?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: Grid The React component. new feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants