Open broskoski opened 7 years ago
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:
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.
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!)?
Here's some interesting articles about inline tradeoffs:
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
We can support this with Radium. I want to add a
.use
API for decorators/mixins etc. something like: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?