Comparing React with ES5 versus React with ES6

Learning React in 2016 seemed like it was stuck halfway transitioning from examples and tutorials using ES5 JavaScript, to the similar but different ES6 JavaScript syntax. If you haven’t done any JavaScript for a while (or at all), it was easy to get confused between the different styles. Even worse, you could easily spend some time reading an article before realizing that it was using ES5 or ES6 syntax and recognizing the differences (or not). As I was learning React, I’m sure I wasn’t the first to paste some ES5 style React syntax into a app using ES6 and get into a complete mess. Once you’ve got to the point of recognizing the differences then it becomes more obvious which is which, and becomes easier to spot an older (and possibly out of date) article with a newer, up to date article.

I like to build example apps to help me understand what’s going on with any new tech or framework, so thought it would be useful to build the same app twice, once using React with ES5 and then rebuild it with React and ES6 as a comparison.

Here’s a rundown of the differences and similarities (I’m sure there’s others too, but these are the ones I’m familiar with).

First up, the entry index.html for each app is mostly the same. The only difference with the ES5 version on the left is that I manually included the webpacked bundle.js, whereas this was done for me from the create-react-app scripts:

Next up, the first index.js to set up the root container component is almost identical. The only difference the JavaScript ES5 using the RequireJS module syntax, versus the ES6 style imports:

Now looking at the AppContainer component. React with ES5 on the left, and ES6 on the right:

Using React with ES5:

  • uses the React.createClass() api
  • defines component state using getInitialState()
  • exports the component as a module using ‘module.exports’

React with ES6:

  • uses the ES6 class
  • defines component state using this.state in the constructor()
  • exports the component as a module using ‘export default’

The render() function is similar in both.

CalculatorComponent – here you’ll notice some more significant differences:

React with ES5:

  • props are implicit
  • implicit binding of ‘this’ to functions

React with ES6:

  • props are passed into the component via the constructor()
  • explicit binding of ‘this’ to functions in the constructor, using this.functionname.bind(this)

And that’s it! Hope this is a useful reference if you’re looking for a side by side comparison. You can clone my example apps from github here: https://github.com/kevinhooke/ReactJavaScriptComparisons

As I’m still learning as I go, if I’ve misunderstood anything or got anything wrong, please leave a comment and let me know!

React: _registerComponent(…): Target container is not a DOM element

Using Webpack with React, it’s critical you import your bundle.js after any DOM elements in your page that you intend to reference. See this issue discussed in this SO question here.

For example:

<body>
<h2>React with ES5</h2>
 <script src="dist/bundle.js"></script>
 <div id="app"></div>
</body>

Importing bundle.js before a DIV element that you reference in your app will result in this error:

Uncaught Error: _registerComponent(...): Target container is not a DOM element.
    at invariant (bundle.js:839)
    at Object._renderNewRootComponent (bundle.js:20668)
    at Object._renderSubtreeIntoContainer (bundle.js:20758)
    at Object.render (bundle.js:20779)

Instead, you need to ensure bundle.js is loaded after the elements you need to reference:

<body>
<h2>React with ES5</h2>
 <div id="app"></div>
 <script src="dist/bundle.js"></script>
</body>

Learning React and Flux – how many articles and references do you need before you can build a working example?

As an experienced developer of some 21 years, I have no problem in stating that learning React and Flux has a steep learning curve. It’s complex (until you understand it). If anyone else tries to tell you anything different I’d question if they know what they are talking about. They probably don’t. In fact they’re flat out lying if they say it’s anything but complex. The official Facebook documentation for Flux is terrible. I challenge anyone to build a working React app using Flux using the solely the Facebook Flux docs and no other sources and no other prior knowledge of how to build a React app using Flux. You won’t be able to. There’s too much information that’s missing. You might be able to create Actions and send them to your Dispatcher, but you won’t get to the point of having a working Flux event flow through View Controller, creating an Action, sending it to the Dispatcher, the Store, emitting events, and triggering a Component to update based on Store changes.

In learning Flux, I’d say I went through a substantial number of articles piecing together snippets of different approaches before I got to the point where I got the concept, and then many more to get to the point of actually having a working simplest case app up and running. In addition, I’ve also worked through a React and Flux tutorial on PluralSight, and part of part of another similar course on Udemy, and also watched numerous presentations on YouTube.

The trickiest part I found was that the docs and many articles talk about each of the individual parts of Flux, creating Actions, creating the Dispatcher, creating a Store, but what seems to be missing is the key part of how do you hook them all up to together, so the one way event flow works as it should. Miss out any one part and nothing happens. Your app just doesn’t work. Or you get obscure errors and you’ll have no idea what they’re talking about.

Here’s a summary of the best articles I’ve found that were the most useful:

http://blog.andrewray.me/flux-for-stupid-people/

https://discuss.reactjs.org/t/whats-the-best-flux-tutorial/51

https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture

https://scotch.io/tutorials/creating-a-simple-shopping-cart-with-react-js-and-flux

https://brigade.engineering/what-is-the-flux-application-architecture-b57ebca85b9e#.8twu5mlke

https://medium.com/@nosherwan/flux-stores-with-es6-syntax-d2182552091e#.ozap6h8sb

  • parts of this article don’t work because you get at least the first error below, but it was useful in showing registering a Component to listen for events from a Store

 

Here’s a list of articles and posts for working round specific (weird) errors that I ran into:

Understanding binding ‘this’ to access setState() in ES6, to avoid this error:

Uncaught TypeError: this.setState is not a function

http://stackoverflow.com/questions/33381756/this-setstate-is-not-a-function
http://stackoverflow.com/questions/20279484/how-to-access-the-correct-this-inside-a-callback
Why this.setState is undefined in React ES6 class? https://github.com/goatslacker/alt/issues/283

  • the magic answer from user troutowicz: “React components using ES6 classes no longer autobind this to non React methods. In your constructor, add:this.onChange = this.onChange.bind(this)"

What JavaScript voodoo is this!

Understanding this error when attempting to output state in the render() for a component: “Uncaught Error: Objects are not valid as a React child”

  • this error is particularly obscure. It turns out the ‘object’ in question was a property object where I was referencing part of the object parent properties to display in a render() using { } but the property I needed was nested further down. So
    { this.state.labelValue }

gave the error above, this referencing the property data correctly (in my case) like this worked:

  { this.state.labelValue.labelValue.value }

This was hinted by this post:
http://stackoverflow.com/questions/33117449/invariant-violation-objects-are-not-valid-as-a-react-child

I finally got to a working example, simplest case example, which you can see on my Github here. I feel like I’ve just earned my Flux badge 🙂

What will we say about Facebook React and Flux in 10 years?

I’ve been learning some React and Flux. You don’t have to develop React apps with ES6, you can still use ES5, but I think having a library that can be used (or has been over the past couple of years) with two different languages with differing syntax and quirks, and is supported via bewildering layers of complexity like transpilers and webpackers and the like, it does nothing to help developers who are just getting started.

The problem is, you start reading articles and tutorials and initially you’ve no idea that ES5 syntax is not the same as ES6, so you start inter-twining concepts from both and finding out that even copying snippets of using React apis using ES5 into ES6 classes does not work (for example). At least in the Angular world they made a clean break when introducing Angular 2 which can be developed using TypeScript and other languages. The two frameworks are obviously and deliberately different.

I don’t think this is entirely React’s fault. It’s more to do with browsers not natively supporting ES6 (yet),  and hence the need for transpilation from ES6 source to ES5 for runtime. Just to get Babel and Webpack setup and configured is a significant task. True, you can use a starter project template that’s preconfigured and ready to go, but I like to know how to do things myself so I have the understanding of what I’ve got, rather than working with a black box of magic that I have no idea how to fix if it goes wrong.

There is no denying that the JavaScript world right now is complex and diverse. It’s very complex. It’s also growing and changing quick (just look at the new module trends for JavaScript modules shared via the npm repository – it’s outgrowing every other language by far, in rate of growth and sheer numbers of modules – e.g. take a look at ModuleCounts). There’s so much going on and changing that the phrase ‘JavaScript Fatigue‘ has been coined to describe what it’s like to try and keep up (click that link or Google that for yourself – there’s over 1,000,000 hits right now, which tells you this is not an isolated feeling among just a few developers). The article ‘How it feels to learn JavaScript in 2016‘ attracted a huge amount of attention this year, and many followon discussions, but there’s no smoke without fire.

Which brings me to my question. Ten years from now will we look back and say:

  • ‘Wow, Facebook React and Flux was so ahead of it’s time. It was a remarkable approach to web development’

or will it be more like:

  • ‘Wow. Facebook React and Flux. Why on earth did we think that was a good idea?’