
Rebass: Configurable React Stateless Functional UI Components - mrmrs
http://jxnblk.com/rebass
======
edvinbesic
Can someone explain to me the usefulness of "stateless" components? Doesn't
thing just mean that you have moved the state outside of the components
themselves, they are not really stateless.

For example, their dropdown menu takes in an open={false}. This just mean that
you now have to keep track of if this menu is open or closed outside of the
menu component itself. Or, you have to write a wrapper menu component that
emits something more useful and maintains that state.

Doesn't some state belong in the component itself? Certainly there are cases
where this makes sense, right?

~~~
andrewstuart
My (beginner level) understanding is that if you move the state up to a higher
level then you can generalise the component.

For example a button's state can be controlled by a higher level container
component and that state might include variables such as "buttonTitle" = "Hit
delete to continue", and onDelete = deleteCustomerRecord. So the core button
code can be used in a variety of contexts.

If I'm wrong maybe someone else will correct me.

~~~
edvinbesic
I guess I understand that for simple component. The checkbox here is a good
example where the value is the state, so there is no use in keeping an extra
copy of it. Same would be with a slider component or whatever. But when it
comes to more complex components I always feel like encapsulating
functionality makes the component more reusable and less boilerplate-y which
in turn encourages use. It's sort of like convention over configuration.

But then again, maybe it just hasn't 'clicked' with me yet.

Edit: I should say though that having all state external would help in testing
the component since you can now simulate every possible state without going
into the internals of the component itself.

~~~
andrewstuart
I'm not religious about keeping components stateless. I have some components
where I just found it was getting too complex to keep bouncing the state up
and down the hierarchy so I just merged it all into one big stateful
component.

If I was a better programmer I probably would have known how to structure it
properly to avoid this but I'm not.

Also recently I have gone to the trouble of learning Redux which effectively
provides a mechanism for global state and probably that would remove much of
the problem with moving state around. But this is the thing about programming
- you build your code doing it one way, and 80% into your project find a
better way, which you start using. Hmmmm.... now should I get the damn thing
built and have the app use two (or more) ways of getting the same thing done,
or go back and make the whole app consistently use the better way, or not use
the better way and instead continue to use the old way but keep things
consistent?

------
vdnkh
I've used a similar, albeit more opinionated library for boilerplate UI stuff
(modals, dropdowns, etc.) and the issue I have with it is styling. It works
fine for the well-defined use cases but when you need to style something not
part of the proptypes or as a child/parent of the given prop, the treatment
becomes worse than the cure. You have to resort to rooting around the DOM with
dev tools, determining the proper divs (which are usually horribly long and
messy), make the style, and hope the library isn't overwriting it at runtime.

~~~
lgas
What prevents you from assigning your own class names and styling based on
those?

~~~
vdnkh
You can't directly access the classNames of child components i.e. if the
component is composed of an <h1> inside of a <div> (with <div> being the top-
level component), you cannot directly set the className of the h1 if a prop
doesn't exist to do so

~~~
lgas
But you can set the classname of the component and then refer to it as
".componentclass h1" or similar, right? Or is that what you are saying gets
too unwieldy?

~~~
Mekkanox
Using ".component-name <insert child tag>" goes against semantic UI
conventions and couples your custom styles to the tags instead of the classes
in the component. It quickly becomes brittle when trying to update those
styles if the tags change in an updated version, or if the rendered output
changes structure, etc.

~~~
chatmasta
Maybe it's time to rethink your conventions...? The solution to your problem
is in front of you, but you're avoiding implementing it because of strict
adherence to arbitrary conventions.

------
api
The next level future of UI would be something as developer-productive as
Visual Basic .NET from 2007: lay out my app visually in minutes, double click
to add code, build, run, ship.

It's 2016 and I'm still using a soup of hacks to build web UIs. GWT was
promising but far too clunky. React+Bootstrap is almost there but I still have
to write code to make wheels roll (in a parser hack called JSX!) and I still
have to think about the web layer instead of having it abstracted away. As
soon as I start using anything else I have to drag in a soup of hacks, so in
the end I always end up with a web app with a hundred dependencies. Sorry,
must have (insert hipster framework here) installed _too_ if I want to embed
BeanieCap.JS.

I would pay thousands of dollars for something as productive as VS.NET from
2007 but for generating modern responsive UIs for the web. It's okay to
simplify the problem by being opinionated, but only if your opinions don't
suck and only if whatever abstractions you create are elegant and degrade
gracefully when they (inevitably) leak a little. Now that MS is open sourcing
.NET, adding web UIs to Xamarin and making them work like mobile and desktop
would be one route to this. Another would be to reboot GWT using Go->ASM.JS as
the code path and do the UI in Go, then build a visual UI designer for it. Use
the dom as a renderer and shit-can CSS and all the rest of that stuff in favor
of an opinionated uniform minimally-themable design (as long as it doesn't
look like crap).

Every now and then I go searching for this. Nope, still doesn't exist. I have
a wad of cash in hand but nobody will take it so back to hacking web UIs in a
text editor manually. Sigh.

~~~
mrmrs
I would argue that .NET did allow for developers to be very productive at
shipping the worst UI code I have ever seen. Productivity != shipping horrible
code faster than ever. In my opinion.

~~~
api
You can write bad code in any language. .NET was more productive for good code
too.

------
tlrobinson
Can we get the title changed to "Rebass: 56 Configurable React Stateless
Functional UI Components"?

I don't understand what's so "next-level future" about this, they seem like
pretty straightforward React UI components.

~~~
dang
Yes. But without the magic 56.

(Submitted title was "The next-level future of UI dev".)

------
enobrev
This reminds me a lot of semantic-ui[1] and the react-specific wrapper, react-
semantify[2]. Semantic-UI is entirely CSS Class-based, and has lots of similar
components. You can definitely use it without the react wrapper, though the
wrapper makes it "feel" a bit more react-like. Some of the interactive
functionality is based upon jquery, which is decidedly un-react, but while
using it in my most recent project, the jquery bits haven't gotten in my way
very much.

I'd love to see react-semantify expanded to replace the jquery-specific bits
more thoroughly beyond simply replacing the initialization methods, but
haven't had enough time to work on those changes myself.

\- I've nothing to do with these projects except that I've used them recently
and enjoyed them for the most part.

1: [http://semantic-ui.com/](http://semantic-ui.com/) 2:
[https://github.com/jessy1092/react-
semantify](https://github.com/jessy1092/react-semantify)

------
mrmrs
I think this demo is pretty rad:

[http://jxnblk.com/rebass/demo/](http://jxnblk.com/rebass/demo/)

------
SweetBro
"ebass is a React UI component library that uses inline styles to avoid "

Which also means you can't override the CSS if you're trying to go for
something like oh I don't know, basic cohesion; without using !important.
Seems useless for anything short of prototyping.

~~~
meemoo
No, all styling is exposed and easy to override per-instance or globally. You
just have to get in the mindset to do styling in JS:
[https://news.ycombinator.com/item?id=11245298](https://news.ycombinator.com/item?id=11245298)

------
fibo
I think it is very interesting and also a good excercise to read its source
and learn How the author implemented componente. Also seems interesting react-
static by the same author.

------
kevsim
Nice but the sliders are really hard to use on mobile. Also when the "drawer"
slides out in the demo, panning on mobile still pans the main page

------
qwertyuiop924
Rebass: lots and lots of buzzwords. It looks decent though.

