-
Notifications
You must be signed in to change notification settings - Fork 250
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
Responsive variant order is applied incorrectly #885
Comments
@hwhmeikle Hey 👋 Styles are generally injected by the order of rendering (with a few exceptions that we’ve introduced recently) so for this case, when multiple variant values might show up on different breakpoints, our recommended approach is to make use of ranged media queries so that the different breakpoints aren’t fighting with each others based on the order that they are injected in. Please see this modified codesandbox and let me know if it matches the output you would expect. I’ve modified |
Hey, thanks for the quick reply! That definitely seems to solve this scenario. This might be a contrived example, but what would you suggest if we were skipping a breakpoint e.g. Perhaps that's just part of the discipline of using ranged media queries inside your responsive variants, you have to ensure you're defining a value at every breakpoint between your base/highest variant. |
Yes, what you suggested is probably how I would do it. We're also thinking about ordering the responsive variants styles by the order of breakpoints in the media object so that your original code would work without defining ranged media queries since |
Hey all, jumping into this conversation. I also understand the suggested solution of having range medias to target specific medias, but that is not really the solution because the "bad" css selector is already injected in the DOM in the order it was injected, so another Basically what I'm saying is that an instance of To finish up on the range medias approach: yes, you could use range medias everywhere, and that would solve the problem, but that is not how you usually write css/styles. It'll be pretty annoying having to specify the styles for all medias all the time (because you can't really use normal medias, ex: Ok, so, what could we do?I haven't looked at the internals of stitches, but perhaps, instead of creating css classNames for each component + variant + value combination, we could try to create unique css classNames for the whole variant per se. So for example, say this is the prop
We could generate a unique className for the group, example Performance? |
@hadihallak I have to agree with @csantos1113 that defining ranged media queries everywhere isn't the best developer experience. I like your solution around ordering the responsive variants by how they're defined in the |
I 100% agree with that statement — Rendering order should never produce different visual results. we've also experimented with the idea of generating unique hashes but as you mentioned, this is likely to cause performance implications so we're not set on that yet. All in all, I do think that this is a bug, and the recommended approach for now is to use ranged media queries as a workaround until we provide a fix for it which is likely land once we figure out React 18 and concurrency support. |
I've hit the same issue when developing a grid-system. The problem occurs when a combination of media/variant is used a second time – as the combo was found before, its rendering is market as cached, and therefore it isn't rendered again. Not a problem generally, but a problem if there are other media selectors on the same component which would match as well and weren't rendered before: then, the last found is rendered last, and gains specificity. SolutionsNo automatic solution is possible, as this is how CSS works. If you are doing mobile-first, this might be a pain and seems possible to fix, but you could as well be using other kinds of media queries or even top-to-bottom media selectors, and therefore Stitches cannot assume it. 1) Configuration:I would suggest stitches renders media styles in split up style tags – following whatever order is found on the
2) Workaround:Avoid using variants, and use local variables instead: // From
const Component = styled('div', { variants: { color: { blue: { color: 'blue' }, red: { color: 'red' } } } })
<Component color={ { '@bp1': 'blue', '@bp2': 'red' } } />
// To
const Component = styled('div', { $$color: 'initial', color: '$$color' })
<Component css={ { '@bp1': { $$color: 'blue' }, '@bp2': { color: "red' } } } /> 3) Dynamic styled-components:Create a wrapper component that generates one new styled-component per media/variant combos found. This is probably not performant, but could serve as a workaround. Here is a codesanbox example for 2) and 3). |
stitches folks, are there any updates on this? maintainers are so quiet lately. Started to worry about this lib not longer being maintained? 😟 |
@csantos-nydig not currently this is going to be fixed but not as a minor update as it requires some decent re-work of the internals and rigorous testing before this is fixed. so, rest assured that Stitches is maintained and we're working on some exciting things that we hope to share very soon |
Hey @hadihallak, Is there a status update? Unfortunately, we are now running into exactly the same problem. Thanks! |
Bug report
Describe the bug
I have a
Stack
component that is using the responsive variant syntax to define an@initial
value, a@md
, and a@lg
value for itsgap
variant. At the@lg
breakpoint, the@md
value is being applied instead.It looks like it is being caused by the fact that a parent
Stack
component is using the same breakpoint -> value variant. In my example, I have a parentStack
that has{ '@initial': 8, '@lg': 20 }
for itsgap
variant, and a descendentStack
with{ '@initial': 8, '@md': 10, '@lg': 20 }
for itsgap
variant. The@lg
values seems to be clashing. You can verify this by changing the parentStack
's@lg
value to something other than20
, or by removing it completely, and the variants are applied in the correct order.I imagine what is happening is that the
@md
class is generated and injected after the@lg
class, and the cascade does the rest.To Reproduce
Code Sandbox reproduction
Expected behavior
Responsive variants are applied in the correct order.
Screenshots
Here's the variants being incorrectly applied:
System information
The text was updated successfully, but these errors were encountered: