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:

CSS logo in front of pile of green matcha tea, which represents the matcha.css library discussed in this article.

How to style HTML with matcha.css

Matcha, a famous green tea, is known for its stress-reducing benefits. I wouldn’t claim that this tea necessarily inspired the […]

Emmanuel Odioko
Oct 7, 2024 â‹… 10 min read
CSS typography in white on a vibrant red geometric background. Article will focus on the CSS backdrop-filter property and its various functions, including blur, grayscale, brightness, and drop-shadow.

How to use the CSS backdrop-filter property

Backdrop and background have similar meanings, as they both refer to the area behind something. The main difference is that […]

Oscar Jite-Orimiono
Oct 4, 2024 â‹… 10 min read
6 AI Tools For API Testing And Development

6 AI tools for API testing and development

AI tools like IBM API Connect and Postbot can streamline writing and executing API tests and guard against AI hallucinations or other complications.

Frank Joseph
Oct 3, 2024 â‹… 12 min read
Patterns For Efficient DOM Manipulation With Vanilla JavaScript

Patterns for efficient DOM manipulation with vanilla JavaScript

Explore DOM manipulation patterns in JavaScript, such as choosing the right querySelector, caching elements, improving event handling, and more.

Joe Attardi
Oct 2, 2024 â‹… 8 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