Optimizing React Performance with Stateless Components — SitePoint

Optimizing React Performance with Stateless Components  #reactjs #javascript

  • First, the Super Basics
    import React, { Component } from ‘react’

    class User extends Component {
    render() {
    const { name, highlighted, userSelected } = this.props
    console.log(‘Hey User is being rendered for’, [name, highlighted])
    return div
    h3
    style={{fontStyle: highlighted ?

  • For example, something like this:
    import React, { Component } from ‘react’

    class Users extends Component {
    constructor(props) {
    super(props)
    this.state = {
    otherData: null,
    users: [{name: ‘John Doe’, highlighted: false}]
    }
    }

    async componentDidMount() {
    try {
    let response = await let data = await response.json()
    this.setState({otherData: data})
    } catch(err) {
    throw err
    }
    }

    toggleUserHighlight(user) {
    this.setState(prevState = {
    users: prevState.users.map(u = {
    if (u.name === user.name) {
    u.highlighted = !

  • import React, { PureComponent } from ‘react’

    class User extends PureComponent {

    render() {
    const { name, highlighted, userSelected } = this.props
    console.log(‘Hey User is being rendered for’, [name, highlighted])
    return div
    h3
    style={{fontStyle: highlighted ?

  • Our first attempt at re-writing it back to a functional component but with recompose.pure looks like this:
    import React from ‘react’
    import { pure } from ‘recompose’

    const User = pure(({ name, highlighted, userSelected }) = {
    console.log(‘Hey User is being rendered for’, [name, highlighted])
    return div
    h3
    style={{fontStyle: highlighted ?

  • ‘italic’ : ‘normal’}}
    onClick={event = {
    userSelected()
    }}{name}/h3
    /div
    })

    export default User

    As you might notice, if you run this, the User component still re-renders even though the props (the name and highlighted keys) don’t change.

Writing inefficient React components can cause them to rerender too often. Peter Bengtsson looks at ways of creating and optimizing stateless components.

@ferroariel: Optimizing React Performance with Stateless Components #reactjs #javascript

calls in them. They only deal with incoming “props” and sub-components.

Yay! It works. It’s really basic but sets up the example.

Things to note:

We realize now that the component above is not only stateless, it’s actually what Dan Abramov calls a presentational component. It’s just a name but basically, it’s lightweight, yields some HTML/DOM, and doesn’t mess around with any state-data.

So we can make it a function! Yay! That not only feels “hip”, but it also makes it less scary because it’s easier to reason about. It gets inputs and, independent of the environment, always returns the same output. Granted, it “calls back” since one of the props is a callable function.

So, let’s re-write it:

Doesn’t that feel great? It feels like pure JavaScript and something you can write without having to think about the framework you’re using.

is used in a component that has state which changes over time. But the state doesn’t affect our component. For example, something like this:

If you run this, you’ll notice that our little component gets re-rendered even though nothing has changed! It’s not a big deal right now, but in a real application components tend to grow and grow in complexity and each unnecessary re-render causes the site to be slower.

. Oh no! What to do?!

to override how React considers the props to be different when we’re certain they’re not. To add a React life cycle hook, the component needs to go be a class. Sigh. So we go back to the original class-based implementation and add the new lifecycle hook method:

function prop doesn’t change. It’s unlikely, but something to watch out for.

component re-renders. So, that’s good for performance. But can we do it better?

method which had to list specific props.

it returns true because the function is always different since it’s created each time.

Generally the solution to that is to bind the function in the containing component’s constructor. First of all, if we were to do that it means we’d have to type the method name 5 times (whereas before it was 1 times):

iterator.

and then when calling that method (from within the child component) pass the user (or its name) back. Here is one such solution.

First, to iterate, what we want:

(Actually, what we ideally want is that components are only rendered once. Why can’t React solve this for us? Then there’d be 90% fewer blog posts about “How To Make React Fast”.)

recompose is “a React utility belt for function components and higher-order components. Think of it like lodash for React.” according to the documentation. There’s a lot to explore in this library, but right now we want to render our functional components without them being re-rendered when props don’t change.

looks like this:

keys) don’t change.

, but you specify the prop keys to focus on explicitly:

component doesn’t.

Hurrah! We have found the gold!

has finished.

It’s not a bad solution to write code the most convenient way for you, then launch your thing and then, from there, iterate to make it more performant. In this case, to make things performant you need to rewrite the functional component definition from:

that is able to “automagically” decipher that what’s being passed in and compared is a function and just because it’s not equal doesn’t mean it’s actually different.

when the need calls.

This article was peer reviewed by Jack Franklin. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Optimizing React Performance with Stateless Components — SitePoint