
Rebass – Functional React UI component library built with styled-components - mxstbr
http://jxnblk.com/rebass/
======
ptgloden
I've really enjoyed using jxnblk's approach to styling. I started with basscss
[1], then moved on to rebass, and finally settled on axs [2]. They all take
more or less the same approach, but operate differently. Rebass generates
inline styles; basscss is simply a CSS file that defines a set of utility
classes (like `mb2`, `p3`, `flex-none`, etc.); and axs dynamically generates
CSS classnames and stylesheets.

...Or at least, that used to be the case. Looking at the most recent version
of rebass, it looks as if it uses the same dynamic classname/stylesheet
generation strategy. Now I'm not so sure what the difference between rebass
and axs are, except that the former seems to be a comprehensive set of UI
components, and the latter a tool for generating your own component library.

In any case, I'm glad jxnblk keeps experimenting with these libraries, even if
it's hard to keep up with the changes. Their surface area is so small that
it's easy to pick up the API and it doesn't feel like a risk or burden to stay
on older versions.

[1] [http://basscss.com/](http://basscss.com/)

[2] [http://jxnblk.com/axs/](http://jxnblk.com/axs/)

~~~
tracker1
Similarly, I've been enjoying JSS[1] a lot... it works similar to inlined, but
under the covers it creates classes per component and renders to styles... can
pre-render via server pass too.

[1] [https://github.com/cssinjs/react-jss](https://github.com/cssinjs/react-
jss)

------
krainboltgreene
The shortening of properties is very much a bad idea and should be avoided.
"What the hell is `mb`?" is going to come up a lot.

~~~
javajosh
In fairness the code is live-editable and so you can figure out what it means
by changing it and seeing how the output differs. (mb means margin bottom).

~~~
cowmoo728
Is there any reason to use shorthand like mb instead of using the React
standard marginBottom?

~~~
pygy_
FWIW, marginBottom is not a React "standard", it's a DOM getter on the style
object:

    
    
        document.body.style.marginTop = '200px'
    

The non-camel-case version works as well (in modern browsers, there was a time
when browsers supported either one or the other):

    
    
        document.body.style['margin-top'] = '400px'

------
subpixel
If the rebass approach to css is interesting to you, i recommend checking out
tachyons.io

It plays nicely with React as well. Sadly most of the discussion around
Tachyons is hidden away from the web in a burrow of Slack channels, but it's
an active community and there's a lot of help and show+tell to be found.

------
imjared
Didn't dive in too much yet but heads up that your hero animation is a bit
funky in Chrome (stable). Here's a screencap:
[https://cl.ly/0D031Z0p3v26](https://cl.ly/0D031Z0p3v26). The glitch happens
towards the end of the recording.

------
k__
I prefer glamorous, CSS properties as JSX props is so much nicer.

~~~
tracker1
give react-jss a look... :-)

------
charris0
I do really like a lot of things about the styled-components approach and
general CSS in JS approach.

I do though have a few concerns that stem from loosing the abstraction of
ascetics vs function of a component, mainly though - ease of designer
collaboration;

It seems harder to have a designer collaborate on your styles. (Maybe they are
more used to CSS more than JS, or an external contractor, or just more
specialised etc). You can't have somebody change your design without them
having full access and knowledge of your entire component source and
architecture.

I notice that styled-components can automatically generate a style sheet with
nice names, it would be good if this could be a step at build time. And maybe
a step that can also reverse the process? adding any changed styles back into
your JS files? (syncing it with an externally edited stylesheet) Does anyone
else see value to this?

------
alttab
Why the hell are we now putting CSS in Javascript? I'm losing my mind with web
developers trying to control everything in the world with client-side
javascript.

What a mess.

~~~
lewisl9029
Styling with JS is simply a much better experience than using stylesheets.

Like it or not, styling often changes in accordance to changes in the
application state. Instead of reacting to state changes by appending/removing
class names, you can remove much of the friction by making style a part of the
application state and changing style directly when the appropriate state
changes.

By using inline styles exclusively, styles are now completely local and
isolated by default, and can never have any unpredictable cascading effects
throughout the rest of your app. We simply cannot understate the importance of
this guarantee of isolation in a component-oriented architecture.

We also gain all the facilities we might possibly need to programmatically
manipulate our styles since they're now just JS objects, without having to
resort to the clunky DSLs offered by preprocessors like LESS and SASS.

Last but not least, we can enable far more granular style reuse using plain JS
objects by leveraging the excellent built-in ES6 module system, and
automatically benefit from module optimization techniques in advanced module
loaders like Webpack to remove unused styles in production.

~~~
Y7ZCQtNo39
Only real downside of inline styles is that they're a subset of real css, and
are not as expressive. Goodbye using pseudo classes like :focus, :active, etc
with just the React 'style' object. And for things like designing input
components, they're really important. You could hack around this by
maintaining component state (e.g., flipping a boolean for mouseEnter and
mouseLeave to emulate :hover), and use the boolean within your styling logic,
but that is pretty hacky.

~~~
johncomposed
That said, with react tools like
[https://github.com/threepointone/glamor](https://github.com/threepointone/glamor)
or [https://github.com/milesj/aesthetic](https://github.com/milesj/aesthetic)
* you can get the best of both worlds. Isolated css plus :hover and other
psuedo attributes.

* or [https://github.com/dowjones/react-inline-style](https://github.com/dowjones/react-inline-style) or [https://github.com/martinandert/react-inline](https://github.com/martinandert/react-inline) ... there's a lot of options

------
morenoh149
This might be good for react native apps as well.

------
rmetzler
The "hello" in the bottom right corner seems like it was put there by
accident. It causes a small problem on mobile.

~~~
arh68
That's the Fixed element. You can live-edit the code:

    
    
        <Fixed m={2} right bottom>
          Hello, this is a Fixed Element...
        </Fixed>

------
riston
Seems like you are reinventing HTML and CSS, what's the benefit of using such
component library?

~~~
Kequc
That's the goal. It used to be that JavaScript and web development was very
difficult because the languages were lacking. Today the languages aren't
lacking but there's still a psychosis that won't go away. React was built for
extremely complex websites like Facebook, specifically for Facebook. And now
people use it just to make buttons or range sliders. Or to develop a blog, or
an about page.

Despite the fact that you can make a button or a range slider natively in HTML
and CSS which would be much more performant with a smaller footprint on both
bandwidth and cpu. What can you say; ever since jQuery everyone has been dying
to reinvent HTML and CSS, it's exactly what you just pointed out.

