Feedback

[mxstbr]

• I totally agree with point one, makes a lot of sense.
• You're kinda loosing me with rules, not 100% how rules.background('black') is any better than background: 'black'. You can still abstract common rules and you can avoid the one-to-one mapping with the spread operator so I kinda don't really get the usecase. (I guess not using the spread operator is nice, but imo that's a pretty small benefit…)
• You're completely loosing me with trait. The same thing could be accomplished with the API we have and a function, why do we need a separate, implicit API for it?
• Totally back on track with point 4 and 5, agree with those
• Why do we not make the initial step (elem) much better by making it generic instead of bound to react? Not sure what that API could look like, but having elem be completely generic and able to return whatever (Angular components, web components, HTML tags, you name it) would help immensly with adoption

[geelen]

You're kinda loosing me with rules, not 100% how rules.background('black') is any better than background: 'black'.

For that example, it's not. It was something I was playing around with, really, where I wanted to do some cool tree-shaking shit with multiple exports i.e.

import { background } from 'styled-elem/rules'

const Header = elem('header',
  background('red')
)

But it turns out that writing a different import for each new rule you want to use is shit. Hence:

import { rules } from 'styled-elem'

const Header = elem('header',
  rules.background('red')
)

_But_, working with it, I found a couple of small advantages. By abstracting the underlying {property: value} object that represents 1-1 mapping to CSS rules in the base case (i.e. even when you do have a 1-1 mapping) I think it encourages higher-level thinking. Because then there's less friction going from "this is an object" to "this is a function that returns an object".

AND THEN, you could start working with more advanced constructors for some rules. For example, transitions/linear gradients/animations etc. Yeah, you can do these same constructors and compile down to a simple {property: value} object but I think the real power is when everything compiles up to a higher-level representation.

BUT THEN, what about adding flow/typescript annotations to all these rule constructors? Type-checked style declarations, instantaneous in-editor feedback, that sort of stuff would be _italian chef kissing fingers_.

You're completely loosing me with trait. The same thing could be accomplished with the API we have and a function, why do we need a separate, implicit API for it?

Again, this is just me dipping a toe into higher-order styling constructors. My goal for the whole thing is not to port CSS to JS (although I ended up thinking that was pretty important i.e. points 4 & 5) but to make it easier to do styling. So, the trait is just a higher-order styling function constructor. You can implement my example:

const typography = trait('typography', {
  weight: {
     light: fontWeight(300),
     bold: fontWeight(500),
     default: null
  },
  size: {
    '24pt': fontSize('1.5rem'),
    '18pt': fontSize('1.125rem'),
    '16pt': fontSize('1rem'),
    default: null
  }
})

as the following simple function:

const typography = tokens => {
  let weight, size
  tokens.split(/\s+/).forEach(token => {
    switch (token) {
      case 'light': fontWeight(300); break
      case 'bold': fontWeight(500); break
      case '24pt': fontSize('1.5rem'); break
      case '18pt': fontSize('1.125rem'); break
      case '16pt': fontSize('1rem'); break
    }
  })
  return concat(weight, size)
}

...except the trait constructor does a bunch of error-checking, like making sure you don't provide two different fontSize tokens. Obviously, having the underlying representation means that people can define their own, but I always use traits when I style, so I decided to implement them first.

Why do we not make the initial step (elem) much better by making it generic instead of bound to react?

I think it's useful to bind to React for now (solve one problem well before generalising, etc), but maybe elem lives in css-components-react instead of this repo (whatever the name ends up being). To be honest, though, elem is really just the React-specific parts already, creating and injecting the styles is deferred to Root. So we can definitely generalise things later.

My big question is how to get the React stuff perfect. I.e. perf-wise, DX-wise, server-rendering-wise. Atm I'm being super simplistic but this needs someone with much deeper knowledge of React than me. Know anyone like that, @mxstbr? ;)