React components are wonderfully encapsulated. Each component is a blueprint for what a focused bit of markup should look like at any moment. They're reusable and can change their behavior depending on the context provided. Does that remind you of another programming paradigm?

Let's talk about JavaScript. JavaScript has a prototypical inheritance model. That means different objects can have a common structure. The structure of one object can be derived from the structure of another.

It also means that changes to the original object are inherited in all derivative objects. Let me illustrate this with some code:

var Page = function(content) {
    this.content = content;
};

Page.prototype.render = function() {
    return "<div>" + this.content + "</div>";
}

var Post = function(tags, content) {
    this.tags = tags;

    Page.call(this, content);
};

Post.prototype = new Page();

Post.prototype.render = function() {
    var page = Page.prototype.render.call(this);

    return "<ul>" + this.renderTags() + "</ul>" + page;
};

Post.prototype.renderTags = function() {
    return "<li>" + this.tags.join("</li></li>") + "</li>";
};

var page = new Page("Welcome to my site!");
var post = new Post(["news"], "A new product!");

Page.prototype.render = function() {
    return "<section>" + this.content + "</section>";
};

I begin by creating a function called Page, which requires a content parameter. A simple render method returns that content, wrapped in a div tag. This seems like a good starting point for a website.

Next, I decide to make a second type called Post. Objects of this type have tags, so I create a new initialization function to store them. I want Post to behave almost like a Page type, so I call the Page initialization function.

To inherit the Page methods in Post, I need to link their prototypes. I can then choose to override the render method and add new methods to the derived type. I can also change the Page type and these changes will be inherited by objects of the Post type. The connection happens because a prototype is a reference and not a copy.

Depending on the programming languages you grew up with, prototypical inheritance might be tricky at first. Many new developers learn (incorrectly) that object-oriented code means class-oriented code. Dynamic concepts such as prototypes are foreign to them. In the past, this led to a few libraries implementing "pretend" classes. They created patterns that would make code appear as if it was class-oriented.

Then, ES6 added the class keyword. It's a formalization of the pattern I just showed you. It's a syntactic shortcut to prototypical inheritance.

We could reduce the previous code to:

class Page {
    constructor(content) {
        this.content = content;
    }

    render() {
        return "<div>" + this.content + "</div>";
    }
}

class Post extends Page {
    constructor(tags, content) {
        super(content);
        this.tags = tags;
    }

    render() {
        var page = super.render();
        
        return "<ul>" + this.renderTags() + "</ul>" + page;
    }

    renderTags() {
        return "<li>" + this.tags.join("</li></li>") + "</li>";
    }
}

var page = new Page("Welcome to my site!");
var post = new Post(["news"], "A new product!");

Notice how much clearer things are? If you want to use classes, then this syntactic shortcut is brilliant!

Let's look at a typical ES5-compatible React component:

var Page = React.createClass({
    render: function() {
        return <div>{this.props.content}</div>;
    }
});

var Post = React.createClass({
    render: function() {
        var page = <Page content={this.props.content} />
        var tags = this.renderTags();

        return <div><ul>{tags}</ul>{page}</div>;
    },
    renderTags: function() {
        return this.props.tags.map(function(tag, i) {
            return <li key={i}>{tag}</li>;
        });
    }
});

ReactDOM.render(
    <Post tags={["news"]} content="A new product!" />,
    document.querySelector(".react")
);

You've probably seen this kind of code before. It's called JSX and it's a JavaScript superset language. The idea is that the markup and the supporting logic are created and stored together.

We'll get into some of the specifics in later chapters, but this is doing pretty much the same thing as before. We create a base component called Page. It renders a property instead of a constructor parameter.

The Post component composes the Page component. This style of React code doesn't support component inheritance. For that, we need ES6 code:

class Page extends React.Component {
    render() {
        return <div>{this.props.content}</div>;
    }
}

class Post extends Page {
    render() {
        var page = super.render();
        var tags = this.renderTags();

        return <div><ul>{tags}</ul>{page}</div>;
    }

    renderTags() {
        return this.props.tags.map(function(tag, i) {
            return <li key={i}>{tag}</li>;
        });
    }
}

We could still compose Page within Post, but that's not the only option with ES6. This code resembles the non-React version we saw earlier.

In upcoming chapters, we'll learn many useful features of ES6 that'll allow us to create modern, expressive React components.

Babel is the cross-compilation tool we'll use to turn ES6 code into ES5 code:

It's time for us to look at how to compile ES6 and JSX code into formats that most browsers can read. Create a folder for your React components and run the following commands inside it:

$ npm init
$ npm install --save browserify babelify
$ npm install --save react react-dom

The first command will kick off a series of questions, most of which should have reasonable defaults. The second command will download a builder and a cross-compiler for your ES6 code. Place the following component in a file called page.js:

import React from "react";

export default class Page extends React.Component {
    render() {
        return <div>{this.props.content}</div>;
    }
}

There are a couple of important differences between this and the previous Page component. We import the main React object from within the node_modules folder. We also export the class definition so that importing this file immediately references this class. It's a good idea to limit each file to a single class. It's also a good idea to make each file define types or use them. We use this class in main.js:

import React from "react";
import ReactDOM from "react-dom";
import Page from "./page";

ReactDOM.render(
    <Page content="Welcome to my site!" />,
    document.querySelector(".react")
);

This code imports React and ReactDOM from within the node_modules folder, so we can render the Page class. Here we're referencing an element in the DOM again. We can use this JavaScript within an HTML page:

<!doctype html>
<html lang="en">
    <body>
        <div class="react"></div>
    </body>
    <script src="main.dist.js"></script>
</html>

The final step is to compile the ES6/JSX code in main.js to ES5-compatible code in main.dist.js:

$ alias browserify=node_modules/.bin/browserify
$ browserify -t babelify main.js -o main.dist.js

The first command creates a shortcut to the browserify command in the node_modules/.bin folder. This is useful for repeated calls to browserify.

The second command starts a build. Browserify will combine all imported files into a single file, so they can be used in a browser.

We use the babelify transformer, so the ES6 code becomes ES5-compatible code. Babel supports JSX, so we don't need additional steps for that. We specify main.js as the file to transform and main.dist.js as the output file.

browserify main.js -t babelify -x react -x react-dom --outfile main.dist.js

We can also use our code directly in the browser. There may be times when we want to see the effects of a change, without a build step. In such cases, we can try something like this:

$ npm install --save babel-core
$ npm install --save systemjs

These will give us access to a browser-based dependency manager and cross-compiler; that is, we can use unbundled source code in an example HTML file:

<!DOCTYPE html>
<html>
    <head>
        <script src="/node_modules/babel-core/browser.js"></script>
        <script src="/node_modules/systemjs/dist/system.js"></script>
    </head>
    <body>
        <div class="react"></div>
        <script>
            System.config({
                "transpiler": "babel",
                "map": {
                    "react": "/examples/react/react",
                    "react-dom": "/examples/react/react-dom",
                    "page": "/src/page"
                },
                "defaultJSExtensions": true
            });

            System.import("main");
        </script>
    </body>
</html>

This uses the same unprocessed main.js file as before, but we no longer need to rebuild it after each change to the source code. The System is a reference to the SystemJS library we just installed through NPM. It takes care of the import statements, loading those dependencies with Ajax requests.

You may notice the references to react and react-dom. We import these in main.js, but where do they come from? Browserify fetches them out of the node_modules folder. When we skip the Browserify step, we need to let SystemJS know where to find them.

The easiest place to find these files is at https://facebook.github.io/react. Click on the download button, extract the archive, and copy the JS files in the build folder to where they are referenced in the HTML page.

The ReactJS website is a great place to download ReactJS, and find documentation about how you can use it:

As our collection of React components grows, we'll need ways of bundling them all together. It would also be a good idea for us to minify the resulting JavaScript to reduce the time it takes to load them in a browser.

We can perform these kinds of tasks using scripts in package.json:

"scripts": {
    "bundle": "browserify -t babelify main.js -o main.dist.js",
    "minify": "..."
}

NPM scripts are fine for small, simple tasks. When the tasks get more complex, we'll start to see the drawbacks of using NPM scripts for this. There's no easy way to use variables in these scripts, so parameters are often repeated. The scripts are also a bit inflexible and frankly ugly.

There are a few tools that address these problems. We're going to use one of them, called Grunt, to create flexible, repeatable tasks.

The Grunt website has instructions for using Grunt and a list of popular plugins you can use to customize your workflow:

Grunt is a JavaScript task runner. There are three steps for using it:

We can install the CLI tool using the following command:

$ npm install -g grunt-cli

We will need the following task libraries:

$ npm install --save-dev grunt
$ npm install --save-dev grunt-browserify
$ npm install --save-dev grunt-contrib-uglify
$ npm install --save-dev grunt-contrib-watch

The global CLI tool needs a local copy of grunt. In addition, we also want the glue libraries to run Browserify, Uglify, and a file watcher in Grunt. We configure them with something like this:

module.exports = function(grunt) {
    grunt.initConfig({
        "browserify": {
            "main.js": ["main.es5.js"],
            "options": {
                "transform": [
                    "babelify"
                ],
                "external": [
                    "react", "react-dom"
                ]
            }
        },
        "uglify": {
            "main.es5.js": ["main.dist.js"]
        },
        "watch": {
            "files": ["main.js"],
            "tasks": ["browserify", "uglify"]
        }
    });

    grunt.loadNpmTasks("grunt-browserify");
    grunt.loadNpmTasks("grunt-contrib-uglify");
    grunt.loadNpmTasks("grunt-contrib-watch");

    grunt.registerTask("default", ["browserify", "uglify"]);
};

We can configure each task in gruntfile.js. Here, we create a browserify task, defining the source and destination files. We include the babelify transformation to convert our ES6 classes into ES5-compatible code.

After the ES6 code is transformed, we can run Uglify to remove unnecessary whitespace. This reduces the size of the file, so browsers can download it quicker. We can target the file Browserify created and create a new minified file from it.

Finally, we create a watch task. This watches for changes to main.js and triggers the Browserify and Uglify tasks. We need to register a default set of tasks, which we set to browserify and uglify. This configuration enables the following commands:

$ grunt
$ grunt browserify
$ grunt uglify
$ grunt watch

There are other great tools like Grunt:

They work with similar configuration files, but the configuration is done through functional composition. The important thing to take from this is that there are tools we can use to automate tasks we would have run by hand. They make these repetitive tasks easy!

If you're anything like me, you'll often just want a quick place to test some small component or ES6 code. Setting up these build chains or live browser environments takes time. There is a quicker way. It's called JSBin and you can find it at https://jsbin.com:

To get the most out of JSBin, be sure to set the JavaScript dropdown to ES6/Babel and include the ReactJS scripts from CDNJS. These are pre-built versions of ReactJS, so you can create React components (using ES6 features) straight from the browser.

In this chapter, we saw why component-based design is good. We saw what simple React components look like. We saw a few interesting differences between ES5 and ES6, and we also saw how those differences influence React components.

We also saw a few ways to make ES6 code work in an ES5-compatible way. We can write cutting-edge code that works on common browsers. We can even bundle that code into single, efficient files, or debug it live in a browser.

In the next chapter, we're going to look at some intricacies of state and properties. We'll begin by creating reusable React components to use in our example application.