Elemental UI for React.js | Hacker News Reader

Elemental UI for React.js

elemental-ui.com

148 pointsjamesknelson46 comments

Does everyone think that wrapping almost each and every html element into a react component is a good thing? Why do I need a <Button /> element if I already have a <button></button> element? You're not really saving bytes here as much as creating confusion and new stuff to learn.

Take, for example, the <FormField label="Input name" htmlFor="input-name" /> component. It takes two props which have totally different meaning. htmlFor is react's substitute for the native html "for" attribute, but the label is being created as an html element. So I have to learn this new mixed up syntax. Why? Existing html syntax is nice already and what everyone's used to.

On the other side, such elements as <Spinner /> are nice to have. We don't have any native html spinner elements, so it's a good unifying wrapper for arbitrary spinner html+css magic, which can be easily changed once someone on the project wishes to change how the spinners look.

You will most likely attach an event listener to the button. You could just use `element.addEventListener`, but that's not consistent if you use React for other form elements.

Next, you might want to dynamically change the button's text, color, visibility etc. At that point, if you are using pure DOM API, the code will start to look like spaghetti, unless what you're doing is a really simple one-off form page.

I'm not sure I understand your answer. The event listener is added via react's 'onClick' attribute which is consistent across all elements.

Things like button's text, color, visibility is nicely controlled via adding/removing classes. And this <Button /> element can create enough spaghetti of its own, too, with attributes like "size", "type", etc, if overused. And with some attributes it can be hard to distinguish native html attributes from component-specific attributes.

> Things like button's text, color, visibility is nicely controlled via adding/removing classes

Isn't the whole point of using React that I don't have to manually manage state like this? When text, color, visibility are all changed independently in different places for more than a handful of states, suddenly it isn't so nicely controlled.

So one example that we use is for many input fields to have formatting done based on the client and their 'settings'/locale. It's basically just a wrapper around the html 5 input with the different types. So decimal places, right aligned, currency symbol, certain client validation that may be different per customer, etc. At the same time we name those components different than something like < Button /> so that it is very clear it's not just a UI wrapper, it has functionality.

You can use polymer/webcomponents with react if you don't care about server side rendering.

> So I have to learn this new mixed up syntax. Why? Existing html syntax is nice already and what everyone's used to.

I assume you'd learn it because it fits with the majority of your use case; having labels immediately attached to fields. So not only are you enforcing a particular style but your saving keystrokes and mental energy on two tags when you only need one.

That's exactly the problem: "it fits with the majority of use cases". What happens when I want to create a form-group element where label comes after the input? Do I need another component like <FormGroupReversed /> or do I need to add an attribute "reversed" to the initial component? I guess I have to go look in the documentation. So here I am, searching documentation to find a way to simply change the order of html elements. And that's just an example. Not to mention that in a week I won't remember what exactly the "reversed" attribute means.

The thing with html, you're gonna start fighting it sooner or later. And when this moment comes, i would prefer to find solutions to the wide-known html problems, not to the problems specific to this library, which may kind of create them in the first place.

One of the advantages of React compared to Angular is that you don't have to learn specific angular syntax — you are encouraged to use native javascript as much as you can. Same goes for html — i'd like to use native html as much as I can. It has enough problems of its own, but at least I know those problems, and which I don't, i'm pretty much sure i can google solution for.

But these component-wrappers are not solving html problems, they are creating shortcuts which are definitely shorter, but rarely intuitive and introduce new syntax and may introduce new problems.

Not defending this particular library, but there are some good reasons to use React abstractions even for simple things like a button. Some examples:

* If the form deals with state and validation, then <Button> (as opposed to <button>) can automatically disable itself if the form's input isn't valid.

* It can incorporate useful features like preventing redundant clicks (to prevent duplicate submits) and showing submit progress (eg., replace button label with a spinner while it's pending).

* You can more easily add features that you would have to manually wire with an HTML <button>: For example, let it take a "tooltip" prop that will automatically show a tooltip on hover.

As an aside, I should add that I wouldn't code up a "form with submit and cancel" like this. I would have the form component itself render the submit and cancel buttons, and call it something like SubmittableForm. This way, it can be in control of the UI (eg., validation, button placement, etc.) and submit logic.

As for that htmlFor thing, I don't know why this library does it that way. There's no reason it couldn't correctly wire up a "for" attribute itself on the HTML label element.

Just a guess, but it might be that because "for" is a JS restricted word, they picked an attribute name that wouldn't maybe trip up a syntax highlighter or something of that nature.

That's not what I was referring to. There shouldn't be any reason for the FormField component to need to know the name of what the label is referring to, since it has access to its children through the "children" prop.

Not to criticize this project specifically but having done some Angular & React apps I wish these libraries would allow some kind of bridge for JS and jQuery plugins.

Do you need incomplete or lagging Bootstrap port for each new framework of the day ?

Especially when you're not doing a SPA and integrates in an existing website, it leads to duplication.

For example I've used Angular-UI and have encapsulate real Bootstrap components in directives and the advantage of the former was not that obvious because it leads to new and different bugs, incomplete features etc.

Have you used React with jQuery plugins? Because you don't really need a bridge

Out of curiosity, what is Bootstrap helping you with?

I'm trying to understand why you'd need bootstrap and jQuery when you're using Angular. I use Angular daily and have never felt the urge to use Bootstrap. In fact an older Angular project had been using bootstrap and I was able to completely eliminate it from the project.

Did angularjs provide a device targeting feature for you? That's all I've used bootstrap for.

Are you saying Angular and Bootstrap provide you the same things? I do not see in what world those two are synonymous, one is basically a glorified ui kit with some limited js backed widgets, the other is a framework for building applications.

No. Not at all.

Let me explain. I see two groups of bootstrap users:

1. Those that use the framework for JavaScript tooling. Things like dropdowns, hamburger menus, tooltips, etc. They typically don't use any of the prepackaged bootstrap styling. This was me for a long time.

2. Those that use the framework for both aesthetic specific CSS and JavaScript.

Angular helps Group 1 rid themselves of bootstrap. Group 2 is largely helpless.

So....asking for a friend. But why is using bootstrap for #2 a bad thing?

It's not necessarily a bad thing. What I meant was that it's much harder to convince someone already relying on prepackaged styling to abandon that for a custom UI.

The full-bootstrap-stack is perfectly fine for things like side projects.

It's not, bootstrap gives you a nice starting point to design your application.

You might have misread. He's wondering if you need Bootstrap when you're using Angular and suggesting that you don't. No where does he conflate the two.

Looks like a wonderful React-based alternative to the likes of Semantic UI, and a great start! A couple quick questions:

1. I see a lot of "inspired by bootstrap" comments in the grid/scaffold... just wondering, are you porting their grid system in a reproducible way -- or are you finding these components don't change frequently enough that it's easier to just pull in pieces of the base code manually, as needed? As per the commenter below, there doesn't seem to be any indication of a dependency in your `package.json`

2. Bootstrap 4 is finally moving to SCSS... any plans to follow suit?

Hmmmmmm. Semantic UI is honestly an amazing and under-looked alternative to Bootstrap/Foundation and the likes -- definitely more focussed on building web apps than just pretty web sites. It's good to see something similar coming together for React -- the controls are well worth it.

Are there examples for using Semantic UI for a basic CRUD workflow?

Thanks! We're porting their grid system manually at the moment, the foundations don't really change much and we're quite selective about what's being ported.

We're actually experimenting with deprecating access to classes (i.e exposing components rather than class names as the public API) - will be interesting to see how popular that approach is.

2. LESS has been our favourite pre-processor for a white but we're finding it doesn't play well with packaging modular components on npm. Some real limitations around the @import logic, and the core team refuse to make it to work with node-style require path resolution which is disappointing.

From here I think it's more likely we go with the "styles in components" approach (via Radium or similar) and make variables / themeing available via context. Much easier to package & use "out of the box". Might keep a "base" css include though, or possibly use the Bootstrap 4 "Reboot". The distinction between, and best way to package, component styles and page styles is something we're putting a lot of thought into!

There's something wrong with the routing on that page. Whenever I open a link in a new tab it redirects to the home page. The same behavior when I type http://elemental-ui.com/css in my address bar and hit enter, it opens the homepage. Only clicking a link on the homepage gets me to the css page.

Thanks for pointing that out - webre using react-router and it works locally, not sure why hosting on github pages breaks it. Will check it out.

If you're using the HistoryLocation in react-router then it expects a server with routes that renders the same index.html page, which github pages definitely doesn't do

There is a bug in the modal code. It scrolls to top of page when you click the launch modal button.

Annoying for the user to have to scroll down. Also visually annoying, personally I got very distracted when it scrolled to the top like that.

Not sure if Elemental UI is a competitor to bootstrap. But if you are happy with bootstrap, then the react bootstrap library is fine. And the modal is very concise and fluid. https://react-bootstrap.github.io/components.html

I am using react-bootstrap but I wish I hadn't - it's quite large (113kb minified, without including anything from bootstrap itself) and doesn't do very much above and beyond using standard bootstrap classes and standard HTML tags.

It also means you'll probably end up having to include jquery for things which adds another very large amount of code...

I'm pretty happy with bootstrap as a quick good looking (with a theme) win, but I think one day I'd like to get rid of it and write some simpler problem specific CSS and use React proper for any Javascript interactions.

I haven't had to pull in jQuery for other things with usage of react-bootstrap, as react-bootstrap handles all of the interactions that bootstrap provides. Also, if file size is getting you down, and you don't need all of react-bootstrap, you can simply require the individual components you need.

e.g: require('react-bootstrap/lib/Modal')

Elemental UI is a competitor, sort of, I guess. But it's not a zero-sum game, and we've learned (and borrowed) a lot from Bootstrap.

More specifically, we're not porting Bootstrap to React but building React-specific components from scratch to fill the same gaps.

Something in particular we're focusing on is building a modular IU toolkit - so you could use all of Elemental, or just our select component / buttons / date picker / etc; all of which would be available as standalone packages on npm, but can leverage a consistent thumbing system and play nicely together.

(And yes - we'll fix that modal issue soon with a pure css approach; a community member wanted to implement it with JavaScript but it hasn't worked out well)

Can I ask what you mean by this? I'm just getting into react and that sentence is a pretty big red flag..... you mean you cant just do return false and it breaks react?

I phrased it badly - I meant the modal scroll handling that was implemented hasn't worked out well, no red flags for React here. position: fixed is a more robust way of positioning modals, the current version watches the scroll event and updates the modal's position which is pretty janky; and it does some not-great things manipulating overflow on the body too, which causes the bug mentioned. We'll be fixing that in the next release.

gotcha, thanks!

So if Elemental is a competitor to Bootstrap, would you be able to point out some reasons to use this rather than React Bootstrap? It appears the elements are almost identical to Bootstrap, but with far less number of them so far.

Semantic UI is a competitor as well, but that library has a number of styling options and UI features that Bootstrap does not have. Semantic doesn't seem to have a complete port to React yet, particularly with some of the more advanced controls (sidebar, sticky elements, certain modals, etc.)

Not intended as a loaded question: How come you're building a full form system yourself rather than leaning on formsy or similar?

There's another UI kit for React called Belle, I posted here: https://news.ycombinator.com/item?id=10110956

Is this component based. Where I could pick the modal without all the forms. Or form elements without all the grid system. I'm dying for a pick what you need framework rather than all or nothing like everything else out there.

Hint: you are looking for something that isn't called a "framework".

Not sure if you saw my other comment below but this is a major goal for us with Elemental. We're not there today, because we're working through the best way to componentize the CSS for each module while retaining a common base for variables & customisation (i.e themes).

The most likely outcome will be to go with the "css in components" approach (w/ Radium, I expect) and maybe a base / "foundational" optional stylesheet for typography / etc. Still working it out though - all today's viable approaches have lots of pros and cons.

You might like to look at how reapp [1] has achieved this.

It has default styles baked into each component, allows granular overriding of styles at a component level, as well as global theme support.

[1] http://reapp.io / https://github.com/reapp/reapp-ui

Sounds good. I don't mind having to have some base or foundation file as long as the components can be picked.

I'm working on a project at the moment where I just want form elements :( but doing them myself because everything else is all of nothing.

Cool. It says it uses Bootstrap grid, Does that mean that bootstrap is integrated? Hard to tell from the package metadata.

Note that this is from the creators of KeystoneJS [1] and TouchstoneJS [2].

[1] https://github.com/keystonejs/keystone [2] https://github.com/touchstonejs/touchstonejs

It means we've borrowed the css directly from Bootstrap for the grid (as well as some variables and mixins) so, aside from giving credit, if you are familiar with the bootstrap grid it should be easy to get up and running with Elemental.

We're actually developing it first and foremost for use in Keystone's Admin UI - we needed a robust and flexible css + component library for that, which users could extend & build plugins on, so we started building one.

This looks cool. I'm kicking my heels while I wait for react-bootstrap to be compatible with react 0.14-beta3. But I see this isn't compatible with 0.14-beta3 either... :-(

What's the weight of elemental UI once it's minified?

Reply on news.ycombinator.com