RFC: Replace array value fallbacks with array value concatenation

The problem

Currently, in emotion when an array value is encountered the values are treated as a primary value with fallback values that are duplicated for the same property.

Example:

<div
  css={{
    backgroundColor: ['hsla(134, 96%, 68%, 1.0)', 'rgb(95, 252, 132, 1)']
  }}
/>

This is a little known feature that is, anecdotally, rarely used. Further, I don’t believe it is as useful as it once would have been due to the current browser css support landscape.

The current parsing behavior for array values prevents the syntax from being used for anything else.

Proposed solution

One of the pain points while leading teams using object styles and using them extensively myself is having to use string concatenation/template literals and/or long hand for properties that support shorthand.

I would like to allow values to accept arrays which would get concatenated by emotion in a somewhat intelligent fashion.

Some examples

padding & margin

potential to automatically append px

All three of these would result in the same padding values

<div
  css={{
    padding: `${space[1]}px ${space[3]}px ${space[2]}px ${space[2]}px`
  }}
/>

<div
  css={{
    paddingTop: space[1],
    paddingRight: space[3],
    paddingBottom: space[2],
    paddingLeft: space[2]
  }}
/>

<div
  css={{
    padding: [space[1], space[3], space[2], space[2]] // <-- new use for array
  }}
/>

border

Properties such as border that have multiple value types would get concatenated.

could detect number types and append px

<div
  css={{
    border: `1px solid ${theme.colors.blue}`
  }}
/>

<div
  css={{
    border: [`1px solid`, theme.colors.border]
  }}
/>

<div
  css={{
    border: [1, `solid`, theme.colors.blue] // Numbers get px added automatically (?)
  }}
/>

Alternative solutions

An alternative would be to simply concatenate the values or to remove the fallback array syntax altogether and let the behavior be defined by the user if/when we get some sort of plugin system in the future.

EDIT

After thinking about this for some time I think the best solution would be to just remove the fallback value so that these types of values can be used for any situation later on. It could be used for the solution above or media query values such as those used in styled-system or facepaint.

Additional context

As more users leverage the power of themes I think we should make it as easy as possible to work with them while using object styles. I’m excited to hear everyone’s thoughts on this and their alternative idea/solutions.

[zslabs]

Really like this idea! One other use-case that I find pretty monotonous right now is writing transforms. Using the array syntax, this could work like this:

transform: [['rotate', '40deg'], ['translateY', theme.space.large + theme.space.base]]

[tkh44]

After thinking about this for some time I think the best solution would be to just remove the fallback value so that these types of values can be used for any situation later on. It could be used for the solution above or media query values such as those used in styled-system or facepaint.