
ReactCSS – Bringing Classes to Inline Styles - casesandberg
http://reactcss.com/
======
AriaMinaei
Webpack's css-loader is made pretty much for the same goals, but it has some
differences. [https://github.com/webpack/css-
loader](https://github.com/webpack/css-loader)

One difference between the two is that css-loader allows you to use normal css
files with classes and selectors, while ReactCSS inlines all properties.

For example, with css-loader, you can use much of your old toolchain for css.
You can use sass, less, or newer tools like postcss, but you still get the
benefit of local styles.

Here is a nice articles that touches on css-loader and postcss:
[https://medium.com/@olegafx/frontend-welcome-to-the-
future-9...](https://medium.com/@olegafx/frontend-welcome-to-the-
future-91ff064884b6)

~~~
Lazare
First, this isn't really anything to do with webpack or css-loader; it's an
idea which just happens to be supported by, among other things, css-loader.
(Also has a browserify plugin.)

Second, I find this idea to be conceptually very interesting, especially
compared to the inline styles people are playing with. It works with the
existing CSS tooling, knowledge, frameworks, browser optimisations, etc we
already have. There's no real workarounds, edge cases, weird hacks, whatever.
It's normal CSS, but scoped to your component, which makes reusing components
across a project or between projects MUCH easier.

It's not a magic bullet; you have to be smart still about organising your CSS.
But it's really quite clever. I'm using it on a decently large project right
now; too soon to tell how it'll work out but it's been good so far.

------
dwwoelfel
For anyone experimenting with inline styles, there are a couple of things
you'll still need a stylesheet for.

Inline styles can't modify psuedo-elements or psuedo-styles. You'll need to
define styles for :before, :focus, :active, etc. in a stylesheet. These
selectors are really important if you want to make appealing forms, e.g.
[http://blog.circleci.com/adaptive-
placeholders/](http://blog.circleci.com/adaptive-placeholders/)

Vendor prefixes are difficult to do with inline styles. If you're using a map
to represent your styles, you can't define multiple values for the same key.
For example, if you wanted to use flexbox, you'd need "display: flex" and
"display: -webkit-flex". Solving that with inline styles is going to get
messy. It's much easier to use less's auto-prefixer plugin to do that for you.

You need a stylesheet to define keyframe animations.

There's probably more I've missed, but those were the problems I ran into when
I experimented with inline styles. In the end, the vender prefixes problem
made me move all of my styles to a stylesheet. The good news is that the
problem could probably be solved by applying a runtime equivalent of less's
auto-prefixer.

~~~
snookca
While you can't modify pseudo elements or pseudo classes, you can replicate
them using actual elements and conditional logic. I've seen React examples
that do just that.

------
Raphmedia
Impressive, but to me, as a front-end developper that has been breathing CSS
for the best part of my adult life, this solve an issue that shouldn't be an
issue.

Yes, you can end up with unmanageable CSS. Yes, it is very easy to end up with
a website that is hell to maintain if you have no idea what you are doing.

The real solution is to hire someone who is an expert at managing CSS in
enormous websites.

You don't see people saying "Oh? OOP programming? That's too hard! Write all
your code with this _insert unconventional project_ instead!".

That being said, this project is impressive, and I love that people are
working toward making CSS better.

~~~
clessg
Of course, anybody is able to _manage_ a problem, but our jobs as engineers
should be to _fix_ the problem. And indeed, there is a _lot_ that is
problematic about CSS, just as there is a lot that is problematic about
writing concurrent code in old versions of Java.

You can deal with it if you're careful and don't let anybody touch the code,
but you've solved nothing and as an engineer, that should make you feel bad.

~~~
tracker1
I'm not sure that this really solves the problem better than keeping your less
files next to your jsx files for component specific styles and relying on css
classes, hierarchy or properties as it stands.

I've gone down the path of doing similar things to this, and in the end I find
it's more complex than simply using less (or scss)... While I appreciate the
effort actually inheriting styles in/out of react components, based on
parent/child relationships is a lot harder to manage when dealing with your
react components directly imho.

~~~
clessg
Are you able to elaborate on what practical issues you ran into?

~~~
tracker1
Mainly centers around inheritance, or applying the same styles to multiple
controls... it's much easier in CSS using classes, or hierarchies than it is
directly in the controls... you'll usually wind up with some common js style
files, and have to import/use them for reuse... and it just gets a bit weird,
even compared to say bootstraps variables file.

------
hhsnopek
Can someone explain or lead me to a reason that this is a good idea? I
understand that React is solving a problem, but I don't see how inlining your
css like so contributes or improves the solution that React brings.

~~~
andreasklinger
css tends to be used with global name spacing

this becomes very quickly hard to manage

the core idea is to do what react did in js (global namespace => components)
but for css

that being said i believe stuff like [https://github.com/css-modules/css-
modules](https://github.com/css-modules/css-modules) will be a more correct
solution (you can also use scss to precompile eg)

~~~
guiporto
I understand the idea but I still think the BEM methodology is better than
this approach.

~~~
RussianCow
I disagree. Using something like ReactCSS, _all_ the code related to a
component is in the same file. I don't have to switch between HTML, JS, and
CSS files just to edit some small part of my app.

~~~
snookca
I'm not sure that trying to keep everything in one file is necessarily a great
argument. Optimizing for not having to open files doesn't seem like the best
thing to optimize for. Even many of the react+inline styles examples include
putting variables and other patterns into external files. Language (i18n)
strings could be another external dependency. Data model, controllers, and
routing are other good examples. (Rarely (if ever) have I seen an MVC
framework that doesn't separate things into separate files.)

~~~
RussianCow
It's more conceptual than keeping everything in one file. I want to be able to
see everything related to a component without looking at anything else, and to
be able to easily change its styling in the same way I change its structure or
behavior (at least with React). You can technically do this by creating a
separate CSS file for every component, but the problem is your CSS has no
context about your component, and so you end up doing all kinds of shuffling
with classes to get things to display the way you want them to. This is a much
more elegant solution, in my opinion.

------
cardeo
what happened to a clear division between js and css? In my experience many
developers want nothing to do with css, they want a designer who can code to
handle that

~~~
iMark
In many cases that division doesn't exist. Part of the beauty of React, as far
as I'm concerned, is that it allows us to think about things on the page in
terms of components, rather than as separate blocks of html, and javascript.

It does make sense to bring css into the mix as well, as css can have
functional effects. If you have a React component, for example, which
explicitly toggles whether items are displayed or not, it makes sense to tie
the toggling of the css display property directly into the component, rather
than factoring it out into a separate stylesheet and creating an additional
dependency.

Note that I'm not suggesting that all styling should be done this way - I
think that would be disastrous - but that there is merit in composing the
html, css and javascript together.

~~~
betenoire
Exactly. It's still a separation of concerns, just a different set of
concerns. Organizing my code by feature/component is so much easier on my
brain than organizing it by file extension.

You can mess this up, of course. We are really good at making things more
complex than they ought to be, especially while the ideas are fresh in our
head. We just need to keep that in mind to :)

------
vlunkr
Maybe we should start calling this something besides inline styles, because of
the huge negative connotation it carries. It's more like component-ized styles
or something. This is a pretty interesting concept though. I've noticed that
in really large and interactive web apps sass becomes super unwieldy, and many
styles just aren't re-usable.

~~~
davidkpiano
Look at the source. It's quite literally _inline styles_.

~~~
vlunkr
Sure that's the final result, but like mmatants said, it's the opposite of how
inline styles were used back in the day. They were static then, and
repetitive, the idea here is to programmatically create inline styles for web
pages that have become increasingly dynamic and complex.

------
dinosaurs
How does this compare to something like Radium? I have been looking for a
clean way to work with styling in React and was planning to use Radium, then I
noticed this.

~~~
williamstein
I'm also very interested in the answer to this.
([http://projects.formidablelabs.com/radium/](http://projects.formidablelabs.com/radium/))

------
rcgs
Hey, you put CSS in my JavaScript!

Surely this could be done in a smarter way, using one of the many CSS
preprocessors to replace the variable mapping done by `classes()`?

After all, the `render()` template just needs to reference variables!

~~~
brunolazzaro
I think you might want to try [https://github.com/css-modules/css-
modules](https://github.com/css-modules/css-modules)

------
nathan_f77
I'm not a big fan, to be honest. I've read a few posts about the idea, but I'm
just not convinced. I'm very happy with SASS, especially with frameworks like
Foundation, Bootstrap, and Skeleton. If you follow the advice and best
practices outlined by those framework authors, then I don't think CSS needs
such a huge paradigm shift. And then there's PostCSS, which I haven't really
explored yet, but seems really promising.

------
Sakes
This is a very elegant and magical solution. My problem is with the react
community's position on maintaining css in JS rather than in css files.

I'd much prefer to see the problems that the JS managed css solves handled
during the build phase of the life cycle.

~~~
clessg
What is your practical issue with it? I know it feels wrong at first, and by
default performance may not be as good, but it makes sense to colocate the
trio: one component into one file.

If you already use a methodology like BEM or SUIT, this is just a natural
extension of that.

~~~
jeremiep
Thing is, your one component might share styles with half the other
components.

Then having a proper separation of code and style with class names to bind the
two becomes your only sane option at scale.

~~~
DougBTX
Components sharing styles is the same as functions sharing constants, so there
isn't a fundamental difference here. One benefit of sharing constants is that
you can use, eg, TypeScript to compile-time check that all of the constants
are defined, making it much easier to remove unused styles.

------
likeclockwork
I've been indirectly using React via Reagent in Clojurescript and I've been
enjoying expressing logic in Clojure syntax, with dom structure in Hiccup's
syntax.

I've been wishing for a nice way to incorporate CSS into that as well. I'm
starting to feel like using 3 different languages.. HTML/JS/CSS to achieve a
single effect is a bit unwieldy, though I've done it for years.

I haven't yet seen story in JS or Clojure for bringing CSS into the actual
programming yet that I'm ready to adopt.. but this is interesting.

------
danr4
<Icon is="Icon" />

<span is="span" />

<CodeSmell is="Stinky" />

Besides, you kinda lose all the advantages of using javascript to style, which
is complex computations and co.

~~~
clessg

        <div is="dialog">
          <h1 is="title">
            { this.props.title }
          </h1>
          <div is="actions">
            <Button is="Cancel" label="Cancel" />
            <Button is="Accept" label="Accept" />
          </div>
        </div>
    

Seems more expressive to me than <div className="dialog">. I understand the
point though; the example provided on the homepage is very contrived. Few
people are going to do something like <span is="span">. (Well, I could be
wrong.)

------
luisrudge
here's a great video about inlining css with react.

Colin Megill - Inline Styles are About to Kill CSS
[https://www.youtube.com/watch?v=NoaxsCi13yQ](https://www.youtube.com/watch?v=NoaxsCi13yQ)

------
autobot
Thoughts on [https://github.com/pluralsight/react-
styleable](https://github.com/pluralsight/react-styleable) ?

A higher-order React Component that:

\- Makes defining and using css styles in React Components consistent.

\- Makes your styles portable with your reusable components.

\- Makes overriding styles easy and predictable.

Uses CSS modules.

------
dauoalagio
Regardless as to what this project is trying to achieve, I appreciate that the
site is using all inline styles and is surely using this project to have made
it easier!

~~~
kolodny
I've never seen any builder that outputs js to that[1]. Does anyone know what
he's using?

[1][
[https://raw.githubusercontent.com/casesandberg/reactcss/gh-p...](https://raw.githubusercontent.com/casesandberg/reactcss/gh-
pages/common.js) ]

~~~
sabarasaba
that's webpack [http://webpack.github.io/](http://webpack.github.io/)

------
grandalf
Though the styling of the website looks similar, this is not a facebook
project.

I think the main reasons to want a component to do some styling are:

\- so the consumer doesn't have to include separate CSS elsewhere to get
default appearance

\- and so that stuff that is an implementation detail can be relatively hidden
(as with the shadow dom) and can expose what it makes sense to expose.

So the ideal styling approach lets a component properly render itself, yet
also lets it be customizable with regular CSS.

------
travjones
This is pretty cool. For now, I'm going to stick to regular CSS files, but
when that becomes unmanageable it will be nice to have styles combined with
react components. Some would argue that this is edging near "inline styles"
and "one should never inline CSS." But this package definitely has practical
value. Talk about "rethinking best practices?!" Nice work!

------
jaequery
I believe in the future, js may replace css, perhaps even html. Javascript is
the future.

~~~
ihsw
_barfs violently_

In all seriousness, I could see a future where the browser is just another
user environment. Desktop OS (Linuxes, Mac OSX, Windows), mobile OS (Android,
iOS, Windows), and the browser (Firefox, Google Chrome, Safari, IE/Edge).

We compile things against it (there's a standard library/API/ABI), it has a
screen that users interact with.

At the risk of sounding more irrationally exuberant than the parent, the
browser is an OS in itself. Yes I realize that "OS" and "browser" are actual
terms that have narrowly defined definitions, however the sentiment is the
same.

It's just another client for our code/binaries to run on and in actuality
what's running our code is irrelevant.

I'm intentionally avoiding calling it a _platform_ , though.

------
etjossem
I really can't imagine a circumstance in which this would be a good idea (as
opposed to refactoring your CSS such that it's well namespaced).

------
ylg
The way CSS in React should be is not to be.

~~~
clessg
Elaborate?

~~~
Semiapies
CSS in JS is not an inherently bad idea, but I haven't seen a good
implementation, much less one as good as a CSS preprocessor. CSS done in React
abandons all that's powerful about CSS in order to do glorified inline styles.

Look at the example. Imagine that being one of dozens or hundreds of
components in an app. Then imagine trying to re-style the app from a flat-
looking interface to whatever's trendy next. I'd much rather do that with a
LESS file than muck through however many JS files that would take with this.

~~~
clessg
I suppose I look at things differently, because I use the BEM/SUIT
methodology. There is already a logical one-to-one mapping between most BEM
components and React components, so the effort required to change everything
would be roughly the same.

The point of using inline styles isn't to be hip: it fixes most problems
caused by specificity wars, global selectors, monkey patching, code bloat,
dead code, and indeterminism. I agree that there is yet to be an
implementation that is perfect, but there are some very smart minds working on
this problem at the moment.

~~~
NathanCH
My issue is that the problems you listed are solvable if you write good CSS.

I mean, specificity wars... isn't that one of the first things we learn to
avoid when writing stylesheets?

~~~
clessg
Right. So long as you follow sound architectural practices and be careful to
not override global selectors, you will achieve most of the benefits of inline
styles. [https://github.com/postcss/postcss-bem-
linter](https://github.com/postcss/postcss-bem-linter) is a godsend.

However:

* Your components will still be spread out among separate files. Button.js, Button.scss. Icon.js, Icon.scss. Just like it doesn't make sense to separate inherently coupled HTML and JS, it doesn't make sense to separate inherently coupled HTML/JS and CSS.

* You have to use two separate programming languages unless your app is simple.

* SASS and LESS can be really problematic. They have ambiguous syntax and are non-standard. There's 9,001 ways to import in LESS. They look like programming languages, but they differ in confusing, bug-prone ways. SASS and LESS's variable resolution are different and confusing. And math is whitespace-sensitive. Yes, whitespace-sensitive math.

* Another build step.

* No easy way to get values statically from CSS files. Instead you have to use comments like "IMPORTANT: keep this value in sync with Button.js!". And if you forget, you will have a difficult-to-debug problem.

------
yummybear
Maybe this would make more sense for Native?

------
supercoder
Do inline CSS styles impact performance ?

