Ensure named breakpoints don't overlap when using the Display component

[sarahpads]

This didn't quite feel like an issue because everything works as intended. But it also doesn't quite feel like a feature request, as it's an adjustment to an existing system. Let me know if I should move this elsewhere.

We recently ran into an odd-feeling behaviour when trying to support mobile/tablet views. Take the below mqs for example:

mq.only.width('mobile', 'tablet')

mq.only.width('tablet')

When you load the app on a device whose width exactly matches tablet, both of the above mqs will evaluate to true. This makes it a little awkward to use named tokens for responsive design. It would be nice if there was a way to configure mq for exclusive handling to ensure the above do not overlap.

In the meantime, I suppose we could introduce additional named breakpoints to avoid the overlap:

mq.only.width('mobile', 'maxTablet') // 0 to 1023

mq.only.width('minTablet') // 1024 and up

A little clunky, but it should do the trick. Has anyone run into this and solved in a different way? Is the community interested in adjusting mq so that upper bounds could be treated exclusively? Maybe something like mq.only.width('mobile', 'tablet', { exclusive: true }?

I put together a little repro that demonstrates the existing behaviour: https://github.com/sarahpads/unistyles-breakpoints

[jpudysz]

Hey!
This is by design since v.2.0. TBH i don't want to change it.

One question though, why you use mq for such cases? You should use breakpoints instead:

mq.only.width('mobile', 'tablet')

vs

{
  backgroundColor: {
      mobile: 'red',
      tablet: 'blue'
  }
}

I can see the problem, but you can always map it to second enum that holds number + 1.

[sarahpads]

Our layouting requirements are too complicated for StyleSheet breakpoints. For example, on mobile we want a carousel and on tablet a wrapping grid. We're relying on the Display component to conditionally render the appropriate experience based on breakpoint.

I understand not wanting to change how it works (it's ergonomic and it works well), but I do think there's a nice path forward with some simple options. Regardless, we'll move forward with additional breakpoints. Thanks for the consideration!