question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Boolean + Responsive variants overriding with `false` have unexpected behaviour

See original GitHub issue

Bug 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

  1. Go to App.js
  2. Resize the preview window
  3. Notice that the first <Button /> is not respecting the fullWidth=false override on the @sm breakpoint (<- This is the bug)
  4. Notice how overriding the @sm breakpoint with @md has the same problem in the second button (so the problem is with overriding all true values)
  5. Notice how overriding @initial in non-boolean properties seems to work as expected in the third <Button />.
  6. Go to Button.tsx
  7. Uncomment the explicit styling for false
  8. Resize the preview window
  9. 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:open
  • Created a year ago
  • Comments:5

github_iconTop GitHub Comments

1reaction
hadihallakcommented, Jun 28, 2022

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:

const Button = styled('button', {
    variants: {
      variant: {
        red: {
          backgroundColor: 'red',
          color: 'red',
        },
        blue:  {
          backgroundColor: 'blue',
        },,
      }
    }
  }
)

so now if you render the following button

<Button variant={{"@bp1": "red", "@bp2": "blue"} />

it would translate to something like this:

@media(min-width: 520px){
  .random-hash-variant-bp1-red{
    background-color: red;
    color: red;
  }
}

@media(min-width: 900px){
.random-hash-variant-bp2-blue{
    background-color: blue;
  }
}

// this button will have a blue background and a red text
<button class="random-hash-variant-bp1-red random-hash-variant-bp2-blue" />

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 the color css property then it wouldn’t have had the red color leaking from the red variant

0reactions
LimeWubcommented, Jun 28, 2022

Thanks 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 adding false 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 the false when needed?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Interaction Patterns - Documentation - Akka
Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.
Read more >
Bug descriptions — spotbugs 4.7.3 documentation
A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it...
Read more >
Java static code analysis: Boxed "Boolean" should be avoided ...
Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code · All rules 649 · Vulnerability54 · Bug154...
Read more >
Spiders — Scrapy 2.7.1 documentation
The parse method is in charge of processing the response and returning scraped data and/or more URLs to follow. Other Requests callbacks have...
Read more >
XSL Transformations (XSLT) Version 3.0 - W3C
In the event that future versions of XPath are defined beyond XPath ... The Mode csv:post-process 3.5.7.11 Overriding the Default Behavior.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found