React 15 and learning to think in components

Looking back at React 15, the part that interests me is not how much JavaScript can be placed beside some HTML. It is the discipline of describing an interface as components with clearer responsibilities.

React has moved on since that release. I still think its earlier component model is a useful way to examine the habit underneath the tooling: decide which piece of the interface owns a value, describe how it should appear and make the route for changing it understandable.

A component needs a job

Splitting a page into many files is not the same as designing a component system. I want a component to have a job I can explain: show a project summary, let someone choose a filter or display the result of a save operation.

The useful boundary often follows behaviour and data, rather than the exact boxes drawn in a design. If a heading, status and action all describe one record, keeping that relationship together may be more valuable than creating a separate abstraction for every line of markup.

That feels close to application design. Before choosing a visual treatment, I need to understand which information belongs together and which actions a person expects to take.

Props describe an input

Here is a small class-component example in the style available in React 15:

class ProjectSummary extends React.Component {
  render() {
    return (
      <section>
        <h2>{this.props.title}</h2>
        <p>{this.props.status}</p>
      </section>
    );
  }
}

The component receives its title and status. It does not need to know how the project was fetched, which database stores it or how the whole application is arranged.

That separation is useful when reading code later. The question becomes whether the inputs are correct and whether the component presents them clearly. I do not have to trace an unrelated request through a display component before understanding its output.

State needs an owner

Interactive behaviour makes the boundary more interesting. A disclosure might own whether it is open. A selected project filter might belong higher up because both the controls and the result list need it.

If the same selection is independently copied into several components, I have created a coordination problem. One control can update while another still displays the old value. Keeping one clear owner and passing the value down gives me less state to reconcile.

For a React 15 class component, updates use setState; I would not mutate the state object directly. When a new value depends on the previous value, the updater form makes that relationship explicit rather than assuming an immediately updated object.

The interface still has to work

A component abstraction does not automatically produce a useful button, a sensible heading order or a form with understandable errors. Those decisions still belong in the markup and behaviour.

I want a reusable control to preserve ordinary keyboard interaction and give its state an accessible name. If something opens, the person using it also needs a predictable way to close it. Reusing a component is only helpful if it repeats a sound decision.

The same applies to lists of records. Stable keys should follow the identity of the data. Using a changing position as identity can become confusing when the list is filtered, reordered or edited.

What I take from the older model

I would not choose an old React release for a new application simply because it is familiar. The reason to revisit it is to separate the durable ideas from whichever API is currently fashionable.

Clear inputs, deliberate state ownership and understandable interaction are useful beyond one library. They help me examine an interface before it becomes a collection of components that are difficult to explain or change.

Further reading

The React 15 announcement gives the release context. React's state and lifecycle guide explains the class-component model discussed here.