React v0.14 Beta 1 released

References to custom component classes work exactly as before.

https://github.com/circleci/frontend

https://www.youtube.com/watch?v=LNtQPSUi1iQ

But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow.

Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change."

By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble.

Isn't this what we have all been waiting for?

It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app.

In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components.

I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here.

If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries.

Another use case that I came across was where we wanted a search dropdown to open in the header when a user clicked somewhere in the middle of the page content. One option would be to make a PageStateStore and add an isSearchDropdownVisible to it, but I don't like doing flux that way because I don't want UI details to be part of my model later.

I think having isVisible in the SearchDropdown state is much more elegant, but that poses the slight problem of how to change that state from the other side of the page. We did that by having the item in the page have an onWantToSearch event, which the page had a handler for that invoked this.refs.header.showSearch(), which in turn invoked this.refs.searchDropdown.setVisible(true), which did a simple this.setState({isVisible: true}).

So, in general, the event first bubbles all up the tree (through custom react onSomething, onSomethingElse props), and then bubbles down the tree (through method calls on refs). This exposes a really elegant design, because it made the Header component be "a thing that allows searching" (because it has a showSearch() method), and the page item an "a thing that allows a user to initiate a search action" (because it has a onWantToSearch event). The available methods and onSomething props of all components perfectly matched the possible behaviors of the components, and no behaviour is "hidden" inside a singleton mesh of flux stores.