Boolean + Responsive variants overriding with `false` have unexpected behaviour
See original GitHub issueBug report
Describe the bug
Hello ^^ Firstly thanks for developing and maintaining stitches, it’s a great library for doing CSSinJS and I’ve enjoyed using it at my work 😃
I’ve spotted a weird bug with using responsive variants in combination with variants which expect boolean values.
In our codebase, we were trying to get a Button to be fullWidth
on mobile but revert to its natural width on >sm
breakpoints.
We were using code like so <Button fullWidth={{'@initial': true, '@sm': false}} />
which should be working to do exactly what we wanted, but what we were actually getting was the button just staying as fullWidth=true
and ignoring the @sm
false
value.
We debugged it a bit and noticed that adding an explicit false
version for the variant in the <Button />
component was making this work correctly and the button was reverting to non-fullWidth in sm.
I have replicated this behaviour to demonstrate the point in the codesanbox attached below.
To Reproduce
Reduced case code sandbox: https://codesandbox.io/s/jovial-wozniak-msfzhf?file=/src/App.js
- Go to App.js
- Resize the preview window
- Notice that the first
<Button />
is not respecting thefullWidth=false
override on the@sm
breakpoint (<- This is the bug) - Notice how overriding the
@sm
breakpoint with@md
has the same problem in the second button (so the problem is with overriding alltrue
values) - Notice how overriding
@initial
in non-boolean properties seems to work as expected in the third<Button />
. - Go to Button.tsx
- Uncomment the explicit styling for
false
- Resize the preview window
- Notice the first button override of
@initial
now works. (Huh)
Expected behavior
I would expect overriding ‘true’ @initial
to work using the prop syntax alone.
I do not expect to specifically have to ‘unset’ my CSS when I just want a false value of a boolean variant to apply on a breakpoint.
I believe there is a bug with overriding smaller breakpoints setting a true
value on a boolean variant.
Please, do let me know if you’d like me to clarify on anything or if I’ve done something wrong in the code ^^
System information
- OS: macOS
- Browser (if applies) Chrome
- Version of Stitches: latest (1.2.8)
Issue Analytics
- State:
- Created a year ago
- Comments:5
yeah we do that to be efficient with how much css we inject so another (un-realistic on purpose) example would be something like this:
so now if you render the following button
it would translate to something like this:
Hopefully this should better illustrate what happens behind the scenes and why it would be better to have different values of the same variant be setting the same css properties because if the
blue
variant did set thecolor
css property then it wouldn’t have had thered
color leaking from thered
variantThanks for explaining this @hadihallak, I hadn’t realised this is how it worked behind the scenes. I thought it would be adding/removing the class with the breakpoint + some magic; but it makes sense that perhaps that would be more complex than needed for most cases now that you explain it.
In which case adding
false
variations to our boolean variants is probably the way to go. Do you think there’s any problem that could be caused when addingfalse
styles in to variants that actually don’t utilise them to future proof? ie. Do you think there will be lots of unnecessary css generated for the false unused variants? Would you recommend only adding thefalse
when needed?