The Evolution of React Component Patterns: A Full-Stack Developer‘s Perspective

As a full-stack developer who has worked extensively with React, I‘ve seen firsthand how React component patterns have evolved over the years. What started as a simple createClass API has grown into a rich ecosystem of patterns and techniques for creating reusable, composable UI components.

In this article, I‘ll share my perspective on how React component patterns have changed, including detailed code examples and usage data to illustrate the key trends. Whether you‘re a seasoned React pro or just getting started, understanding these patterns will help you build better React applications.

In the Beginning, There Was createClass

When React was first introduced, there was only one way to create components – the createClass API:

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

createClass provided a simple, all-in-one way to define a component‘s props, state, and methods. But as React apps grew in size and complexity, the limitations of createClass became apparent.

Mixins were introduced as a way to share code between components, but they had issues with name clashes and made reasoning about a component‘s behavior more difficult. According to a 2016 blog post by the React team, mixins caused "more trouble than they are worth" and were officially discouraged.

The Era of Classes and Functional Components

With the release of ES6 in 2015, React moved to a class-based component model:

class MyComponent extends React.Component {
  render() {
    return <div>Hello {this.props.name}</div>;
  }
}

Classes provided a more standard JavaScript syntax and opened up possibilities like inheritance (although the React team would later recommend composition over inheritance).

Around this same time, functional components were introduced as a simplified way to define components that only needed to receive props and render UI:

function MyComponent(props) {
  return <div>Hello {props.name}</div>;
}

Functional components quickly became the preferred way to define simple, presentational components. According to React Community Metrics, by 2019 function components were used in over 60% of all React projects.

However, functional components had limitations. They couldn‘t have state or lifecycle methods, so class components were still needed for more complex use cases. New patterns emerged to address this.

The Higher-Order Component Pattern

One of the first patterns to gain widespread adoption was Higher-Order Components (HOCs). HOCs are functions that take a component and return a new component with some additional behavior:

function withData(WrappedComponent) {
  return class extends React.Component {
    state = { data: null };

    componentDidMount() {
      fetchData().then(data => this.setState({ data }));
    }

    render() {
      return <WrappedComponent data={this.state.data} {...this.props} />;
    }
  };
}

HOCs allowed for the reuse of common functionality like data fetching, authentication, and state management. Libraries like Redux and Relay used HOCs extensively.

But HOCs had downsides too. They made component trees harder to debug by wrapping everything in extra layers. They also had tricky issues with passing down props and refs.

According to a 2018 Twitter poll by React team member Andrew Clark, 61% of respondents found render props easier to understand than HOCs, foreshadowing the next major trend.

Sharing Code with Render Props

The render props pattern emerged as an alternative to HOCs. Instead of wrapping a component in extra layers, render props allow a component to receive a function prop that it can use to dynamically render UI:

<DataProvider render={data => (

)}/>

Inside the DataProvider, the render prop function is called with any necessary data or methods:

class DataProvider extends React.Component {
  state = { data: null };

  componentDidMount() {
    fetchData().then(data => this.setState({ data }));
  }

  render() {
    return this.props.render(this.state.data);
  }
}

Render props provided a more flexible and composable way to reuse code compared to HOCs. They quickly gained popularity, with libraries like Downshift and Formik adopting the pattern.

However, render props could lead to deeply nested "render prop hell" if overused. They also didn‘t completely replace the need for sharing stateful logic, which is where hooks came in.

The Flexibility of Hooks

Hooks, introduced in React 16.8, were a game-changer. They allowed functional components to "hook into" state and lifecycle features without needing to convert to a class component.

Suddenly, reusable behavior could be extracted into custom hooks, which are just plain JavaScript functions:

function useData(url) {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchData(url).then(data => setData(data));
  }, [url]);

  return data;
}

A component could then easily use this hook:

function MyComponent() {
  const data = useData(‘/api/endpoint‘);
  return <div>{data}</div>;
}

Hooks proved immensely popular. According to the 2021 State of JS survey, 93% of React developers used hooks. They drastically simplified the process of sharing stateful logic compared to patterns like render props and HOCs.

At Facebook, adopting hooks allowed them to delete thousands of lines of legacy class component code. In this comment, a React team member shared:

"When Sophie Alpert and I started writing the initial version of hooks back in late 2017, we manually converted several components to hooks to see how they‘d work in practice…100% of the bugs were gone after we finished the translation."

Hooks quickly became the default way to write React components for many teams. But even with hooks, there was still room for new component patterns to evolve.

Advanced Patterns and the Future

Hooks are incredibly powerful, but they are not a silver bullet. Complex components can still end up with a tangle of useState and useEffect calls, making it harder to trace the flow of data.

One emerging pattern to address this is called "state reducers". Similar to how Redux uses reducer functions to update state, the state reducer pattern uses a reducer to consolidate a component‘s state update logic:

function reducer(state, action) {
  switch (action.type) {
    case ‘SET_DATA‘:
      return { ...state, data: action.data };
    // Other action types...
    default:
      return state;
  }
}

function MyComponent() {
  const [state, dispatch] = useReducer(reducer, { data: null });

  return (
    <>
      {state.data}
      <button onClick={() => dispatch({ type: ‘SET_DATA‘, data: ‘New data‘ })}>
        Update Data  
      </button>
    </>
  );
}

State reducers can make complex state changes more predictable and easier to test. Libraries like downshift have started leveraging state reducers in their hooks.

Another trend is toward more granular, "headless" components that separate behavior from presentation. Rather than providing a complete UI, these components expose a set of primitive hooks and components that can be composed and styled as needed.

React Spectrum, a new component library from Adobe, epitomizes this approach. Its hooks like useButton and useTextField provide accessible behaviors while leaving the rendering up to the user.

Looking further ahead, React is focusing on improving performance through concurrent rendering and server components. These features could enable new patterns around code splitting, incremental data fetching, and seamless transitions between pages.

As a full-stack developer who has built React apps for startups and enterprises, I‘m excited to see how these patterns evolve. In my experience, the most successful React codebases strike a balance between following established best practices and judiciously adopting new patterns when they solve real problems.

Conclusion

React‘s journey from createClass to hooks and beyond has been driven by a desire to make building UIs more declarative, composable, and maintainable. Each new pattern – mixins, HOCs, render props, hooks – has built upon and learned from the previous ones.

As we‘ve seen, there is no one "right" way to structure React components. Different patterns have tradeoffs and are better suited for different use cases. Experienced React developers learn to evaluate these tradeoffs and choose the right tool for the job.

My advice to developers is to stay curious and open-minded. Explore new patterns with toy projects or small features before adopting them more widely. When you do use a new pattern, leave comments explaining your rationale and tradeoffs for your fellow developers.

Above all, remember that React is just a UI library. The best React code is the code that most clearly expresses your product‘s requirements and is easiest for your team to understand and iterate on.

So go forth and continue to push the boundaries of what‘s possible with React components! I can‘t wait to see the patterns and techniques you all come up with next.