2022-01-14
3160
#react
David Herbert
86288
Jan 14, 2022 â‹… 11 min read

A better way of solving prop drilling in React apps

David Herbert David is a frontend developer by day and a technical writer by night who enjoys breaking down complex topics into comprehensible bits, digestible even by five-year-olds.

Recent posts:

i tried kiro and here is what i learned

I tried out Kiro: Here’s what I learned

Check out Kiro, AWS’s AI-powered IDE, see what makes it different from other AI coding tools, and explore whether it lives up to the hype.

Elijah Asaolu
Aug 28, 2025 â‹… 5 min read
Go Design Pattern Article Image With Logo

Why Go design patterns still matter

Here’s how three design patterns solved our Go microservices scaling problems without sacrificing simplicity.

Peter Aideloje
Aug 28, 2025 â‹… 2 min read
how to protect your ai agent from prompt injection attacks

How to protect your AI agent from prompt injection attacks

Explore six principled design patterns (with real-world examples) to help you protect your LLM agents from prompt injection attacks.

Rosario De Chiara
Aug 27, 2025 â‹… 5 min read
Don’t Let AI Erase The Next Generation Of Dev Leaders

Don’t let AI erase the next generation of dev leaders

As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.

Jack Herrington
Aug 26, 2025 â‹… 6 min read
View all posts

13 Replies to "A better way of solving prop drilling in React apps"

  1. Great post David, very clear and to the point. I like how you have shown how using patterns to solve problems can be a better alternative to reaching for frameworks and libraries. I had written a similar post on medium about using composition and the pins pattern you have shown above by passing a component as the prop of another. I too also often find that devs don’t really use composition to it’s fullest (they think they do but not really) and instead reach for things like redux and context api when things start to get out of hand instead or reconsidering the archiecture first.

  2. This seems like a terrible solution. Scaling this is going to be a nightmare. All your HTML markup need to be explicitly defined in App now.

    First issue, move each component to its own file, in your first example each file would only need to have its child component included, but in your solution you would need every component included.

    Second issue, App needs to know how every component works. It needs to know their props, their nesting rules, etc. That should not be on App to know.

    Third issue, add a second message. Where do you do it? In App or in Content? By your code style choice it should really go in App, but what if App doesn’t know the value of the message. Ok, put it in Content, but now a message is coming from somewhere hidden. Now half the info is one place (App) half is another (Content), but they are equal in the end, that’s hard to understand and see at the same time.

    Fourth issue, how do you make message dynamic? Not the text, but rather the ability to hide or show it. This is sort of the same issue as two. Do you put that logic in the App or in Content? Either way is hard to understand.

    I like this idea, but it simply will not scale for larger applications.

    1. I don’t think he meant that everything needs to be in the app. This is how I tend to build components, and I like to push as much of the composition as possible to whatever screen it is on. The app would obviously get really bloated on a real world application if all the state lived there.

    2. Hey Rod,

      As regards your first issue, there seem to be some confusion here. I did not advice that you put all your component’s in one file. I only took that approach so the entire code is in one place and easy to follow along.

      Regarding your second issue, If I’m understanding you correctly this is in relation to the first issue. You can define your individual components and it’s dependencies in their respective files and simply import the components themselves into the root App component. The idea is to simple compose all the components in the root App so it’s easier to directly pass states into any component.

      I’m rather confused at your third issue as my reason for reusing the message component in two different places was to highlight the problem with reusability when it came to using the Context API. Your explanation is somewhat confusing here so I’m not exactly clear on what your issue is.

      Your fourth issue is also not clear. I did highlight that with the Context API there was always the issue of reusability when it came to reusing any Context dependent component outside the Context Provider. But Component composition is free of the above issue and as such is a solution in itself.

      It is scalable but does depend on your understanding and choice of implementation when it comes to composing your application.

  3. Good content, well explained with simple and effective examples. I am new React Dev and Irecently learned about the use of context API to solve the prop drilling problems and this article has provided me with a new way solution to this problem. Thank you.

  4. seems to be just a move from “prop drilling” to “component drilling”: if you have 10 nested components in between App and wherever component you use the state in, you’d have to pass component created in the App there.

    also, wouldn’t the state change change the reference to the component and trigger a rerender in all the ones it is passed to as a prop?

  5. Great post!
    Very clearly explained the possible solutions and the caveats of these. I didn’t know the problems about relaying to much on Context. I like more the second way of compositing, it looks more like the react syntax I’m used to it.
    Again, thanks a lot. Very well explained

Leave a Reply