[BreakpointIndicator] Add new component

[dimitropoulos]

see: https://github.com/dimitropoulos/mui-breakpoint-indicator try it out: https://www.npmjs.com/package/mui-breakpoint-indicator

I have been using this component for a while like:

<MyApp>
  {debugMode && <BreakpointIndicator />
</MyApp>

And I bet I'm not alone in finding value in such a tool.

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

When the user changes the viewport such that they enter a new mui breakpoint, the helper updates.

Examples 🌈

https://github.com/dimitropoulos/mui-breakpoint-indicator

Motivation 🔦

It is sometimes difficult to keep mental note, when making a responsive site with mui, what breakpoint the viewport is currently in. This greatly simplifies the development process.

[dimitropoulos]

@oliviertassinari any thoughts?

No rush, just curious what you think when you have a moment. :smile:

[oliviertassinari]

@dimitropoulos This is smart and pretty cool!

https://github.com/dimitropoulos/mui-breakpoint-indicator#can-i-use-this-if-im-not-using-material-ui

I think that this story will change with Material-UI v5.

[oliviertassinari]

What do you think we should do with it? Tweet, link it in the docs, etc?

[dimitropoulos]

I think the options I was suggesting were either merge it in as one of the components (ideally) or link it in the docs. It's such a small amount of code (and useful, I think, to anyone using breakpoints in material-ui) that I think it wouldn't be too too bad to include it directly in the project. Now, I realize that "it's useful" isn't a good enough metric because if so every project would be republishing lodash or ramda :stuck_out_tongue:

All the same, linking to it in the docs could be fine, just the same. I'm open to any ideas - I hadn't though of tweeting it, for example.

[oliviertassinari]

Ok, I don't have any preference. @mui-org/core thoughts? My main concern will be about, how do we teach users about it, and will developers use it?

On this topic of improving the debugging experience, I was wondering about an error boundary:

• https://elastic.github.io/eui/#/utilities/error-boundary
• https://ant.design/components/alert/#Alert.ErrorBoundary

But it could harm the existing DX of CRA, Next.js, and Gatsby.

[dimitropoulos]

(I'm working on writing up an issue for ErrorBoundaries :smile:! I would be happy to contribute this component and I think I have some feedback that could be useful (TLDR; I think it definitely has a use, and I have some rationale to share as to why a library like material-ui has any business including such a component). I should be done writing up the issue in the next few hours.)

[mbrookes]

My main concern will be about, how do we teach users about it, and will developers use it?

One option would be to use it in the docs, and enable it only on the breakpoints page, from where we could mention and link to it.

[dimitropoulos]

That could be a good option! That way it's sort of self-supporting. Someone that's interested in using breakpoints (and therefore looking at the breakpoints page) will be exposed to it that way.

Also, just to say it out loud, I'd rather archive my implementation and just import it into material-ui itself: but I'm more than happy to keep it separated and just link. I just don't want it to (for whatever reason) fall out of use or out of date. If the two (i.e. the BreakpointIndicator and material-ui itself) are bundled together than the user can always be fairly sure any given version of material-ui will work with the corresponding BreakpointIndicator.

[dimitropoulos]

I'm happy to do all the leg work on getting the component added to the Lab and so forth, if there's interest.

[oliviertassinari]

To be honest, I'm not sure I would personally use this component. I would be worried about hiding some parts of my application. Now, I do get this pain point when I need to work on the responsiveness of the page, I have often caught myself trying different breakpoint values until I could find the right one for the current screen width I'm on. I mean, it's like how I handle the light switches, let's say I have two buttons, I will try both, even 2 years in my place, I don't really know which light switch triggers what 😆.

So yeah, I think that they are two important concerns to take into account:

• how do we teach it? @mbrookes idea is really cool. But it might not look pretty, or look disturbing.
• how do we make it not hide relevant information on the screen? (dragging support could help for instance). Maybe at the same spot, Next.js is using for displaying the loading indicator? I wouldn't use any colors here, but rather a minimalist UI, with just the breakpoint value?

[dimitropoulos]

I would be worried about hiding some parts of my application.

do you mean visually hiding? the default position (in any corner or between any corners) is configurable if you know the page you're using it on requires it to be in a particular place. I know exactly what you're talking about I've hit this a lot when using this component, hence making that prop, which, for me at least, completely solved that problem. Just to to really make it super easy for one-off usage I added in a click to rotate feature if you just temporarily need to move it for whatever reason.

I don't really know which light switch triggers what

hahaha same here. well. it was the same until I got a label maker as a gift. I went around and labeled all my switches and just like that the problem went away! give it a try! label makers are one of those things you don't think you'll need much but then when you get one suddenly you realize all the little ways it can improve your life/organization. hahaha.

how do we teach it? @mbrookes idea is really cool. But it might not look pretty, or look disturbing.

I agree, actually, that it may be shocking or disturbing to someone that doesn't know what it is. Although, I've just realized something potentially really important to mention, that it's actually a lot smaller in actual usage than what's shown in the gifs. Maybe

how do we make it not hide relevant information on the screen? (dragging support could help for instance).

The reason the default is "top center" is because I find that, actually, that's the are of the screen that's most open. Again, it can be configured to be anywhere on the screen corners or corner midpoints.

Maybe at the same spot, Next.js is using for displaying the loading indicator?

Could you show me an example of this? I haven't used Next.js in a while. Wherever it is, though, I'm sure we can do it.

I wouldn't use any colors here, but rather a minimalist UI, with just the breakpoint value?

I'm open to whatever, it's completely customizable out of the box. I will say, it's a good visual cue that you get used to quickly when using it. In fact, the project already has something similar https://material-ui.com/customization/breakpoints/#css-media-queries that I wasn't previously aware of. I think this speaks to the underlying point: that the colors changing is actually one of the key features.

---

Overall, I want to comment, that I won't be offended if there isn't enough interest to include this. It's a very very small component that has a very specific use for helping to build material-ui responsive sites. I've used it a good few times and I have shared the code with some other developers I know using material-ui and they've found it useful for what it is.

I used it for many months internal to a project before splitting it out into it's own component and open-sourcing it and it made things a lot simpler for me ESPECIALLY when I was new to material-ui. It was a great learning tool, if nothing else. The alternative, console.log({ breakpoint }), gets old realllllll fast, haha.

Either way, I'm happy to do a proof-of-concept and add it to https://material-ui.com/customization/breakpoints/#css-media-queries if you want to take a closer look or see it in action.

[mbrookes]

I have often caught myself trying different breakpoint values

I do the same. I imagine most people do!

I don't really know which light switch triggers what

When I have this problem, I rewire the switches to be more intuitive. :)

Maybe at the same spot, Next.js is using for displaying the loading indicator?

If it was set to the bottom right by default in the docs, it wouldn't obscure anything.

I wouldn't use any colors here

I agree with removing the colors - they don't add any additional information.

with just the breakpoint value?

Even though it would take up more space, I wonder if, at least for the docs, it should display "breakpoint: md" so that it's clear what it is indicating? (For normal use the dev will know what it is, so that won't be necessary.

[oliviertassinari]

What if we were using the exact same approach than Chrome that displays the current viewport when resizing? This approach solves the visibility issue, as only visible when resizing, to later fade away.

Regarding the discoverability issue, I think that we could document it in the breakpoint parts of the documentation, as well a include it in the examples.

Exciting 😃. I'm all in with such an approach.

@dimitropoulos What do you think?

[dimitropoulos]

I think I must not have well communicated the value of the component if you don't want the colors and you don't want it to always be visible (when wanted, of course) when not resizing.

I'm happy to implement it however you wish, but I think the next step is to just make a demo of it on the docs page.

This isn't the kind of component that you will have on all the time or anything like that. It really shines, though, when you are constantly moving around and doing responsive layouts. The colors really reinforce that as a visual cue and taking the colors away would therefore reduce a lot of the value in the first place, which is that it give you a mental association with the current breakpoint and the color.

It doesn't get in the way, because there are really no situations where every of the 8 position options are of interest to you when making a layout. I can understand how if you haven't used the component it may feel like it might get in the way, but it really doesn't in practice for that reason.

---

I've had less time than usual to do open-source contributions (which I can only do on nights and weekends for the most part), so I'll try my best to get a demo for this up some time sooner than later.

[oliviertassinari]

@dimitropoulos I think that we can take a step back and wait for more feedback from users. In this context, I would propose that we link the component in https://material-ui.com/discover-more/related-projects/#components under a new DX category. We monitory the adoption of the package. Hopefully, such a link will be enough to seed interest in the developers. If they don't use it, nor share it, it might be a sign that it's not something they are desperately needing, hence we could optimize our opportunity cost by investing time on different matters.