Parents & Owners in React: Data Flow

Consider this small app.

Each component is in control of what content it returns. This works fine.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Header() {
  return (
    <header style={{ backgroundColor: "lightgray" }}>
      <h2>Header</h2>
    </header>
  );
}
function Footer() {
  return (
    <footer style={{ backgroundColor: "lightgray" }}>
      <h2>Footer</h2>
    </footer>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardNav() {
  return (
    <nav>
      <h3>Dashboard Nav</h3>
    </nav>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

First, we’ll ignore a few less relevant components.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

The currentUser state has to go from <App> at the top to <WelcomeMessage> at the bottom.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

Therefore each intermediate component (<Dashboard> & <DashboardContent>) has to pass user forward, while having no use for it itself. That makes user a false dependency for these components.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

This is known as prop drilling.

Prop drilling can make your app hard to maintain. Over time, as product requirements change, so will your app. It should be prepared for that.

For example, the designer wants to turn <WelcomeMessage> in to a floating element in <App/>. Now you have to remove the user prop from all of its parent components.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <WelcomeMessage user={currentUser} />
      <Footer />
    </div>
  );
}
function Dashboard() {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent />
    </main>
  );
}
function DashboardContent() {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <div>Some content</div>
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

Whenever <WelcomeMessage> needs more props from the top, you have to add them at all the intermediate levels too.

These sorts of things make change tedious and can become time-consuming in large applications.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  const [personalMessage, setPersonalMessage] = useState();
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} personalMessage={personalMessage} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user, personalMessage }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} personalMessage={personalMessage} />
    </main>
  );
}
function DashboardContent({ user, personalMessage }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} personalMessage={personalMessage} />
    </div>
  );
}
function WelcomeMessage({ user, personalMessage }) {
  return (
    <div>
      <p>Welcome {user.name} {personalMessage}</p>
    </div>
  );
}

Consider this small app.

Each component is in control of what content it returns. This works fine.

First, we’ll ignore a few less relevant components.

The currentUser state has to go from <App> at the top to <WelcomeMessage> at the bottom.

Therefore each intermediate component (<Dashboard> & <DashboardContent>) has to pass user forward, while having no use for it itself. That makes user a false dependency for these components.

This is known as prop drilling.

Prop drilling can make your app hard to maintain. Over time, as product requirements change, so will your app. It should be prepared for that.

For example, the designer wants to turn <WelcomeMessage> in to a floating element in <App/>. Now you have to remove the user prop from all of its parent components.

Whenever <WelcomeMessage> needs more props from the top, you have to add them at all the intermediate levels too.

These sorts of things make change tedious and can become time-consuming in large applications.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Header() {
  return (
    <header style={{ backgroundColor: "lightgray" }}>
      <h2>Header</h2>
    </header>
  );
}
function Footer() {
  return (
    <footer style={{ backgroundColor: "lightgray" }}>
      <h2>Footer</h2>
    </footer>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardNav() {
  return (
    <nav>
      <h3>Dashboard Nav</h3>
    </nav>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

Let us deviate for a second to go over how content of components can be defined. Components can be fully in control of their own content, like in the example above — or components can leave it up to a parent to place content inside of them.

A component can wrap content by nesting it between its tags, just like HTML. The wrapped content is passed down as the special children prop ¹.

You can think of a component with a children prop as having a ‘slot’ that can be filled in by its parent components ². I like to think of children as the default slot provided by React. If you need multiple slots, you can pass JSX as props too ³.

Strangely enough, there is no widely-recognized name for such components. I’ve heard ‘layout’, ‘wrapper’, ‘container’, and ‘slotted’ components. I’ll go with slotted components in this post.

Let’s turn <Dashboard> into a slotted component:

function App() {
  return (
    <Dashboard>
      <DashboardContent currentUser={currentUser} />
    </Dashboard>
  );
}
function Dashboard({ children }) {
  return (
    <div>
      <h2>Dashboard</h2>
      {children} {/* DashboardContent will be rendered here */}
    </div>
  );
}

Recognize that there are two different relations between components:

Parent: the component or in which the other component is nested.
Owner: the component which renders the other component ⁴.

I think this distinction is overlooked. It’s important because props come from owners. Sometimes an component’s parent is also its owner, but usually they're different. A parent can only pass props when it is an owner as well.

In this example:

<App> is the parent and owner of <Dashboard/>
<Dashboard> is the parent of <DashboardNav> and <DashboardContent> but not the owner. <App> places <DashboardContent> inside <Dashboard> so it is the owner.

Source-to-surface measure for props

A useful measure for prop drilling is the source-to-surface: the number of components some piece of data needs to pass through to surface in the UI.

To find it, answer the following: Where is a piece of data defined and where does it surface in the UI?

Where is it defined?
- Which component holds the state
- Where is the 'static prop' passed (e.g. to configure a component)
Where is it used?
- Where is it visible? Where is it used in render?
- It can be ‘invisible’: In what event handler/effect is it used?

Then count the number of component it has to pass through. A lower source-to-surface (meaning a shorter path through component tree) is generally better.

How are slotted components useful? Let’s look at our app again.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

If we turn <Dashboard> and <DashboardContent> into slotted components…

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard>
            <DashboardNav />
            <DashboardContent>
              <WelcomeMessage user={currentUser} />
            </DashboardContent>
          </Dashboard>
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ children }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      {children}
    </main>
  );
}
function DashboardContent({ children }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      {children}
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

<App> is still the parent and owner of <Dashboard>
Now <Dashboard> is the parent of <DashboardContent> but not the owner
Likewise, <DashboardContent> is the parent of <WelcomeMessage> but not the owner
<App> now owns <DashboardContent> and <WelcomeMessage>

Because <WelcomeMessage> is lifted to <App>, currentUser can be passed to it directly. The source-to-surface has gone from 3 to 1.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard>
            <DashboardNav />
            <DashboardContent>
              <WelcomeMessage user={currentUser} />
            </DashboardContent>
          </Dashboard>
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ children }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      {children}
    </main>
  );
}
function DashboardContent({ children }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      {children}
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

Additionally, <Dashboard> and <DashboardContent> are no longer passed irrelevant data. They’re disentangled from their content and therefore better encapsulated. This makes our — admittedly very small — data flow is easier to follow! And we didn’t even have to reach for React Context.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard>
            <DashboardNav />
            <DashboardContent>
              <WelcomeMessage user={currentUser} />
            </DashboardContent>
          </Dashboard>
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
  
}
function Dashboard({ children }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      {children}
    </main>
  );
}
function DashboardContent({ children }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      {children}
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

How are slotted components useful? Let’s look at our app again.

If we turn <Dashboard> and <DashboardContent> into slotted components…

<App> is still the parent and owner of <Dashboard>
Now <Dashboard> is the parent of <DashboardContent> but not the owner
Likewise, <DashboardContent> is the parent of <WelcomeMessage> but not the owner
<App> now owns <DashboardContent> and <WelcomeMessage>

Because <WelcomeMessage> is lifted to <App>, currentUser can be passed to it directly. The source-to-surface has gone from 3 to 1.

Additionally, <Dashboard> and <DashboardContent> are no longer passed irrelevant data. They’re disentangled from their content and therefore better encapsulated. This makes our — admittedly very small — data flow is easier to follow! And we didn’t even have to reach for React Context.

function App() {
  const [currentUser, setCurrentUser] = useState({ name: "Jules" });
  return (
    <div>
      <Header />
      <div>
        {currentUser ? (
          <Dashboard user={currentUser} />
        ) : (
          <LoginScreen onLogin={() => setCurrentUser({ name: "Michael" })} />
        )}
      </div>
      <Footer />
    </div>
  );
}
function Dashboard({ user }) {
  return (
    <main>
      <h2>The Dashboard</h2>
      <DashboardNav />
      <DashboardContent user={user} />
    </main>
  );
}
function DashboardContent({ user }) {
  return (
    <div>
      <h3>Dashboard Content</h3>
      <WelcomeMessage user={user} />
    </div>
  );
}
function WelcomeMessage({ user }) {
  return (
    <div>
      <p>Welcome {user.name}</p>
    </div>
  );
}

We must recognize two — related but different — component hierarchies.

The parent tree: which components are nested inside of another. This is what you see in the React DevTools “⚛️ Components” tab.
The owner tree: which component renders another components. This is the hierarchy we see in code.

The parent tree is what is created by rendering. The owner tree is how it is created. Having a clear idea of this distinction is key to composing well.

Everything is clearer as a diagram, so here’s one for the parent tree. The dashed arcs between components indicate ownership. The moving dot represents the user prop trickling down.

Take a moment to relate the diagram to the code then hit the toggle above and compare.

Notice that the parent tree is exactly* the same as before! And by extension, the resulting DOM tree and UI too.

* What's the [] in the diagram of the updated version?

Structurally, the tree is the same. When you wrap multiple children in a slotted component using children, React passes the children in array to the parent.

If you would pass this JSX as a named prop, you would have to wrap it in a <Fragment>. With children, React (kind of) does this for you. The [] is like an implicit <Fragment>. Consider it an implementation artifact.

Here’s the owner tree:

Notice how it has changed. It has become flatter by using slotted components to lift up <DashboardContent> and <WelcomeMessage>.

Different owner trees can generate identical parent trees. Data flow — props — follows the owner tree! Flattening the owner hierarchy by lifting components can make the data flow shorter, resulting in better encapsulated components.

Lifting components can help rendering performance too. Props follows the owner tree, so updates do so too. We can use this to seperate components such that updates are avoided in parts that don’t need to be updated.

This is really a subject of its own so I won’t go into it here. I will (probably) do a follow-up post on this, including diagrams of course.

I’ve been scribbling these trees using pen and paper whenever my components were becoming a tangle. While writing this post, I learned that you can view the owner hierarchy in the React DevTools by double clicking on a component in the component tree (see tutorial). Who knew!

Screenshot of React Devtools showing the owner tree for the ill-composed example app — The React DevTools showing the owner tree for both versions of the app.

Screenshot of React Devtools showing the owner tree for the well-composed example app — The React DevTools showing the owner tree for both versions of the app.

React is fundamentally about composition. Composition has always been relevant for maintainable, performant components. It will become even more relevant with React Server Components, where children can be received from the server. I must confess I haven’t looked at RSC that much so I’ll leave it for another time.

Understanding the owner vs parent component distinction is important for composing well.
- I feel this distinction is under-discussed.
- They create similar but different hierarchies. They’re related, which makes it easy to mix them up.
- The owner tree is the shape of the data flow.
  - If the data flow is a mess, look at the owner trees. This can reveal when it’s a good idea to lift a component up.
Slotted component can skip a level in the owner tree while creating the same parent tree.
- Which is useful when ‘prop drilling’.

To close on a nuanced note: passing props down a few levels is not necessarily bad. And giving more control to parents by lifting components isn’t always the right solution.

This inversion of control [lifting components] can make your code cleaner in many cases by reducing the amount of props you need to pass through your application and giving more control to the root components.

Such inversion, however, isn’t the right choice in every case; moving more complexity higher in the tree makes those higher-level components more complicated and forces the lower-level components to be more flexible than you may want.

There’s a right time and place for every pattern, recognizing when and where is what it’s all about. I hope this post and these diagrams helped with that.

The example comes from Micheal Jackson's video Using Composition in React to Avoid "Prop Drilling". Credits to him for coming up with it and explaining it well.

Credits to Marcos for proofreading and providing valuable feedback.