8 ms·

Rebass: Configurable React Stateless Functional UI Components

78 points by mrmrs 11y ago

tlrobinson 11y ago
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 11y ago
  Yes. But without the magic 56. (Submitted title was "The next-level future of UI dev".)
api 11y ago
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.
- protomyth 11y ago
  > The next level future of UI would be something as developer-productive as Visual Basic .NET from 2007 I was always partial to NeXSTEP 3.3 in 1995. I'm pretty sure that something post-webassembly might actually get us close.
- patates 11y ago
  > in a parser hack called JSX! React doesn't need JSX, and I'd like to think about it as if it is a macro, not a parser hack.
- jarcane 11y ago
  The problem is that we're trying to think in terms of "apps" on a platform that was invented and built in terms of "documents." The web wasn't designed to be an "interface", the browser was, and it's purpose was to display interlinked documents. On top of this, the pace of the web's development has outstripped the capability of anyone to actually plan the extensions to this base model, so everything since is just hacks on top of hacks. But it works enough for people to keep going through investor storytime year on year, so ... we continue to move fast, and break everything.
- mrmrs 11y ago
  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 11y ago
    You can write bad code in any language. .NET was more productive for good code too.
- jasim 11y ago
  We're building something like it - https://medium.com/@jasim_ab/code-generator-to-create-react-projects-straight-from-design-with-clean-html-and-css-c399a8189f0d https://medium.com/@jasim_ab/code-generator-to-create-react-.... Also - https://protoship.io/story https://protoship.io/story
vdnkh 11y ago
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 11y ago
  What prevents you from assigning your own class names and styling based on those?
  - vdnkh 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
qwertyuiop924 11y ago
Rebass: lots and lots of buzzwords. It looks decent though.
enobrev 11y ago
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
edvinbesic 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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?
fibo 11y ago
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.
SweetBro 11y ago
"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.
- MikaR 11y ago
  Same opinion... What if the UI need is slightly different from what ebass offers? !important everywhere? This solution to the "leaky global styles" seem worse than the problem it solves.
- meemoo 11y ago
  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
mrmrs 11y ago
I think this demo is pretty rad: http://jxnblk.com/rebass/demo/ http://jxnblk.com/rebass/demo/
kevsim 11y ago
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

78 points by mrmrs 11y ago

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 11y ago
Yes. But without the magic 56. (Submitted title was "The next-level future of UI dev".)

api 11y ago

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.

protomyth 11y ago
> The next level future of UI would be something as developer-productive as Visual Basic .NET from 2007 I was always partial to NeXSTEP 3.3 in 1995. I'm pretty sure that something post-webassembly might actually get us close.
patates 11y ago
> in a parser hack called JSX! React doesn't need JSX, and I'd like to think about it as if it is a macro, not a parser hack.
jarcane 11y ago
The problem is that we're trying to think in terms of "apps" on a platform that was invented and built in terms of "documents." The web wasn't designed to be an "interface", the browser was, and it's purpose was to display interlinked documents. On top of this, the pace of the web's development has outstripped the capability of anyone to actually plan the extensions to this base model, so everything since is just hacks on top of hacks. But it works enough for people to keep going through investor storytime year on year, so ... we continue to move fast, and break everything.
mrmrs 11y ago
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 11y ago
  You can write bad code in any language. .NET was more productive for good code too.
jasim 11y ago
We're building something like it - https://medium.com/@jasim_ab/code-generator-to-create-react-projects-straight-from-design-with-clean-html-and-css-c399a8189f0d https://medium.com/@jasim_ab/code-generator-to-create-react-.... Also - https://protoship.io/story https://protoship.io/story

vdnkh 11y ago

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 11y ago
What prevents you from assigning your own class names and styling based on those?
- vdnkh 11y ago
  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 11y ago
    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 11y ago
      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 11y ago

qwertyuiop924 11y ago

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

enobrev 11y ago

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

edvinbesic 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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?

fibo 11y ago

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.

SweetBro 11y ago

"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.

MikaR 11y ago
Same opinion... What if the UI need is slightly different from what ebass offers? !important everywhere? This solution to the "leaky global styles" seem worse than the problem it solves.
meemoo 11y ago
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

mrmrs 11y ago

I think this demo is pretty rad: http://jxnblk.com/rebass/demo/ http://jxnblk.com/rebass/demo/

kevsim 11y ago

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