Component State: Overcoming Tunnel Vision

Redux can eliminate the need for component state by storing all data in one
immutable object. However Redux introduces new complexity to manage global
state and actions. For domain resources (usually fetched over HTTP) a global
store enables sophisticated caching strategies. But for application state,
it’s often more trouble than it’s worth.

React lets us organize applications by the features in our domain (e.g.
ProjectPage, Search, ValidatedField) rather than by technical patterns (e.g.
views, containers, actions, reducers). Effective product teams work in terms
of features, not abstract technical domains.

Deciding to work with component state puts pressure on our designs.
Developers must decide which components should own state and then connect
parent and child components to that state with data props and callbacks.
Because components can make API calls, manage internal state, and render HTML
they often grow with every new feature.

Let’s focus on one design pressure we often feel when using component state:
tunneling data though layers of components.

Tunneling Application State

Most front-end developers know that they could forego global state if they
were willing to pass every bit of state through every component. This
practice is sometimes called “tunneling”.

Tunneling properties through components starts small. But every time a
developer extracts an intermediate component, they must tunnel all the
properties through that new component. It’s like they’re being punished every
time they improve the design.

Let’s look at an example of a search component that follows a naive design
path.

Already there’s a little boilerplate in our render method. We’re mapping
names (e.g. onFilterClear to this.handleFilterClear) without providing
any new information. It’s redundant but it’s a reasonable way to expose a
public API to SearchLayout.

Now let’s check out the SearchLayout component:

SearchLayout has some presentation responsibilities (notice the heading and the
horizontal rule), but it also has to divvy up props from its owner to its
children. This time we’re mapping props that our component doesn’t care about
to other props that our component doesn’t care about. This is where we start
to feel the “tunneling” pain.

Search, meet SearchField

SearchLayout shouldn’t know how to connect the prop names between Search
and SearchField. It should only care about presentation things: headings,
horizontal rules, and other stylistic elements.

So let’s pull the configuration of SearchField and SearchResult up the stack,
right where that information lives: inside Search.

So what does SearchLayout look like now?

SearchLayout decides where to put the field prop and results prop, but
no longer needs to worry about the props exchanged between SearchField,
SearchResults, and Search.

Is this actually better?

Are we really improving our design or just moving stuff around?

I argue this design is better because we’ve eliminated the repetition of
tunneling our properties through the SearchLayout. We now map the Search
properties to owned components once rather than twice. We’ve also identified
an implicit responsibility (configuration) that was shared between two
components and is now confined to Search.

However, if we look at the Search component before and after this
refactoring we notice that it’s more complicated. Although SearchLayout is
now dead simple, Search knows about three components (SearchLayout,
SearchField, and SearchResults) rather than one (SearchLayout). Because
Search is the top-level component in our Search domain, it’s easy for
responsibilities to collect here.

Search handles both the concern of querying and the concern of
coordinating communication between our search components. Let’s extract a
new component to handle our lower-level, “querying” concern.

Introducing the SearchQuery Component

An alternative, and probably a more popular option, is to create a higher
order component that accepts Search as an argument and renders it with
a query prop. I prefer the render callback because it declaratively shows
how all of our search components work together inside of Search.

Notice that I cheated a little. Not only did I extract a component to handle
querying, I also bundling the props and callbacks into a domain object that
I’ll call query inside of Search.

Search is looking pretty good at this point.

We set out to remove some prop tunneling and at the same time dramatically
increased the flexibility of our design. It would be trivial to create
another Search component that uses a different SearchQuery component to
accommodate a different backend. We could inject a different presentation for
our search results into our SearchLayout component. The flexibility comes
with a cost: separating concerns creates more abstract pieces to learn about.
But in this case, the level of abstraction in each component is more
consistent, making our components easier to understand.

Goodbye Tunneling

If you squint a little you can see query as a little Redux bundle with one
immutable state object and 3 actions (setFilter, clearFilter, setTerm).

By creating a domain object and a component dedicated to composition, we
removed the state tunneling pain. As a happy side-effect we created a design
that is more flexible, has constant levels of abstraction, and is easier to
test.