Cannot reference sizes that have keys with decimals

[dalhaan]

🐛 Bug Report

Incorrect sizes are given when using size keys that have decimal places when using w and h utility props. Instead of the setting the width or height value to the value defined in the theme, it sets the value to the key as a pixel value.

This issue doesn't seem to arise when referencing size keys that do not have decimals.

To Reproduce

Steps to reproduce the behavior:

1. add a sizes key to the theme with a number with a decimal as the key with a value. For example:

   const theme = {
   ...
   sizes: {
   ...
   12.5: '3.125rem',
   }
   }

2. reference that size key in a w or h utility prop. For example:

   <x.div w={12.5} h={12.5} />

Expected behavior

I expected the div to have a width and height of 3.125rem instead of 12.5px.

Link to repl or repo

Code Sandbox: https://codesandbox.io/s/xstyled-v2-playground-forked-iu87j?file=/src/App.js

[dalhaan]

I also noticed that if I have the size key 3.5:

const theme = {
  sizes: {
    3.5: '0.875rem',
  },
};

and set the w & h utility props to w={3.5} h={3.5} the width and height both become e, which is invalid css. I feel that this may be related. If it's not it should be another issue.

I have also added this example to the Code Sandbox linked in the original issue.

[iManu]

Hi Greg,

We encounter the same case using CSS properties in a styled component, with padding declaration in our side.

https://codesandbox.io/s/young-sea-peeur?file=/src/App.js

padding-top: 1;
padding-left: 0.5; 

outputs:

padding-top: 0.25rem;
padding-left: 0.5px;

Note that reverting from 3.1.2 to 3.1.0 resolve it for us in our project. This is not the case in the Codesandbox linked upper: it need to use 2.5.0 to fix

[tkhquang]

Any progress on this bug?

[quantizor]

What if you make the key a string instead? Wondering if there’s some floating point stuff happening that is breaking comparison