Making sense of React’s different component styles

React is an unopinionated framework. It gives you a lot of flexibility to do things your own way.

This flexibility can be empowering once you are familiar with the framework, but it can make it a little daunting to get started. Every piece of code you see seems to be doing things in a slightly different way.

One of the most obvious examples of this is when defining components. Components are at the heart of React. They are first major concept you’re exposed to when learning how to develop applications. Unfortunately, there are different approaches to achieving even this most fundamental of React tasks!

To be fair, the differences are down to advances in both JavaScript and in thinking about how to build better applications. React and its community are flexible enough to evolve and adopt better approaches as they appear. Scant comfort if you’re struggling to make sense of it all, of course.

There are three common styles used to build React components. Let’s look at examples of each and place them in context.

React.createClass components

Until recently JavaScript didn’t have a native class system—so the React framework introduced its own component “classes”—generated using React.createClass.

An example of a component generated using this function is

const ComponentA = React.createClass({
    getInitialState() {
        return {
            todos: [ "Buy milk", "Pay bills", "Feed goldfish" ]
        };
    },

    render() {
        return (
            <ul>
                {this.state.todos.map(function(todo, index) {
                    return (
                        <li key={index}>{todo}</li>
                    )
                })}
            </ul>
        )
    }
});

This was the original React component style, so you’ll see it in older materials. It’s still valid, so also pops up in newer examples.

ES6 class components

ES6/ES2015 introduced the class syntax to JavaScript. When using ES6 (e.g. via Babel) we can use the following component style

class ComponentB extends React.Component {
    constructor(props) {
        super(props);

        this.state = {
            todos: [ "Buy milk", "Pay bills", "Feed goldfish" ]
        };
    }

    render() {
        return (
            <ul>
                {this.state.todos.map((todo, index) =>
                    <li key={index}>{todo}</li>
                )}
            </ul>);
    }
}

While the introduction of the class syntax into JavaScript is controversial, it’s certainly more familiar territory for those coming from enterprise OO languages such as Java or C#. React makes it easy to adopt the latest JavaScript innovations and this native class syntax has become more popular than React.createClass.

Stateless functional components

React tends to encourage functional programming—especially when paired with the Redux. This has lead to the idea of stateless functional components and separating these “presentational” components from “container” components that manage state. The idea is that pure presentational components are easier to reuse and test. Also, separating presentation and state management supports the Single Responsibility Principle—i.e. each component should do only one thing.

Stateless functional components look like this

const ComponentC = ({ todos }) =>
    <ul>
        {todos.map((todo, index) =>
            <li key={index}>{todo}</li>
        )}
    </ul>;

The state (todos in this case) is passed in from an associated container.

class ComponentCContainer extends React.Component {
    constructor(props) {
        super(props);

        this.state = {
            todos: [ "Buy milk", "Pay bills", "Feed goldfish" ]
        };
    }

    render() {
        return (
            <ComponentC todos={this.state.todos} />
        )
    };
}

The container is responsible for rendering the stateless (presentation) component.

While this looks somewhat convoluted in a trivial example, the approach confers a number of benefits, including

  • Reusable components
  • Separation of concerns
  • Improved testability
  • Improved performance (with no state or lifecycle methods to consider, the React team is apparently planning to optimize for stateless components in the future)

Conclusion

React can be difficult to learn as it’s so flexible. This post has introduced three common styles for developing components and placed them in context. They all do the same thing, but come at the problem from different views on what is best practice. I tend to use stateless functional components, but, if you are just getting started, I recommend the ES6 style—because it’s the most common style used in newer tutorials and examples.

The best way to get your head around React’s complex ecosystem is probably to get some training. Learning Tree offers a four-day React course that will introduce you to the core concepts—helping you bring the various elements together to build applications.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.