React Components

Chapter 1. Thinking in Components

React was the first interface library that got me thinking about component-based design. React promotes many good patterns and habits, but this one stands out for me. To understand why, we need to think about how React works under the hood. React is primarily a rendering engine. It was created (and is used) for generating user interfaces.

How interfaces used to work (and indeed still work apart from React) was that someone would come up with a design. That image file would then be split up into assets for each interactive part of the interface. A library such as jQuery would manage user interactions and connect different interface components, often with an assortment of plugins.

Individual interface components can be quite clean and complete individually. However, when they are combined, interactions between components and shared, mutable component state often make a messy codebase. One of the main reasons why React was created was to simplify the interactions between components, so they can remain clean and easy to understand.

Using modern JavaScript

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!");

Note

If you're trying to run this using Node (preferably a version greater than 4.1), you may need to add use strict at the top of the file.

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.

Note

React components must return a single React node, which is why we wrap the tags and page elements in a div element. If you are using React in the browser, you also need to render your components to an existing DOM node (like I've just rendered the post to .react).

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.

Note

If you want to look ahead a little, check out http://babeljs.io/docs/learn-es2015. It's a great place to learn the main features of ES6!

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

Compiling modern JavaScript

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.

Note

If you want to keep that alias around, be sure to add it to your ~/.bashrc, ~/.zshrc or ~/.profile file.

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.

Note

If you want to compile React and ReactDOM into their own file, you can exclude them with the -x switch. Your command should be something like this:

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

Managing common tasks

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:

First, we need to install the CLI tool. We'll use this to run different tasks.
Then, we need to install the libraries our tasks will use, via NPM.
Finally, we need to create a gruntfile.js file where we'll put our tasks.

We can install the CLI tool using the following command:

$ npm install -g grunt-cli

Note

The preceding command installs the Grunt CLI tool globally. If you don't want that, omit the -g flag. You'll need to alias/run it directly with node_modules/.bin/grunt from here on though.

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.

Note

I've added the external option so you can see how. If you don't need it, just delete it and your bundle file should then include the full React source 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!