Support css pseudo-classes

[craigspaeth]

We can support this with Radium. I want to add a .use API for decorators/mixins etc. something like:

const view = veact()

view.use(Radium)

// ...

Maybe we can even support "global" decorators with something like veact.use(Radium) which would apply it to all views (... although hesitant b/c globally applied things like that tend to hurt extractability/encapsulation).

It'd be cool if .use could inspect the argument and determine if it's a mixin, decorator, or some other pattern transparently—but if not maybe it can default to decorators (which seem to be the most popular/trending way to do these) and support a .use(String, Mixin) API otherwise e.g. view.use('mixin', React.Stateless). Or just a set of APIs for each e.g. view.mixin(React.Statless) view.decorate(Radium).

Thoughts?

[acjay]

Not sure if I understood from the readme, but are styles inline in the style attribute of individual tags, or in a single style tag? If it's the former, I've got some concern that this might not be a good default for something intended to scale to an entire site. There are a number of downsides:

• Page weight suffers, especially if there are many repeated instances of a a component
• Have to resort to hacks for many CSS features. Radium could go a long way to helping here, but that feels like possibly just digging a deeper hole, rather than leveraging the way the CSS was designed.
• You lose the ability to use dev tools to experiment with styles page-wide in the browser.

I'm not saying style attributes are universally evil, but just that they might be a poor choice of default. I think finding effective ways of leveraging https://github.com/cssinjs/jss might be a better alternative.

Or I guess maybe offering different decorators, which would handle the way the styles are mounted. In a perfect world, the declaration of the styles is independent of their mode of delivery (style attribute vs. style tag vs. link tag). Then the latter just becomes an easily configurable option, which can be tweaked based on needs.

[craigspaeth]

Thanks for the comments @acjay! They are going the former, inlined style attribute, route currently. I hear those downsides—frankly, I just picked the most straightforward way I knew of to write CSS in JS. JSS probably is a better alternative, especially if it can be swapped in somewhat transparently without extra configuration burden.

For my own curiosity, do you know of any reading/benchmarks that compare the difference in page weight when using inline vs not? Also curious what gets lost with dev tools that wouldn't be lost with JSS (I might be missing out on some workflow tricks!)?

[craigspaeth]

Here's some interesting articles about inline tradeoffs:

• https://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupid-benchmark/
• https://byjoeybaker.com/react-inline-styles
• https://medium.com/@jedwatson/how-do-we-make-styles-in-components-play-nicely-with-server-side-rendering-25de9ecb1b49#.du355logc
• https://github.com/callemall/material-ui/issues/1132

[acjay]

For the performance thing, I don't have any benchmarks. It's tricky because it would be highly dependent on what's being served and what the objectives were. At HuffPost it was something we thought about a lot, inspired by http://alistapart.com/blog/post/breaking-the-1000ms-time-to-glass-mobile-barrier and other stuff out of the web performance space that I mostly heard second-hand from the real specialists.

Oh yeah, the dev tools thing is basically just the ability to interactively experiment with styles page-wide by modifying class rules.

Thanks for the links, that's gonna be great plane reading for the 4-hour flight I'm about to catch :D