Transcript from the "Prop Drilling & Context API" Lesson
>> So, before we started with Celeste refactoring, we're looking at gradually in the beginning, I said there was like, two kind of issues like one that we could theoretically implement a reducer to kind of solve some performance issues. Also just it's a nice simple way to see a reducer kind of in isolation.
[00:00:17] We'll see some more complicated examples in a little bit. The other part was that we had a past that toggle forgiveness all the way through the grudges plural component, right and even though it wasn't using it, now in this example it's not that bad, right? And arguably, I would say, if the example was the size and one thing I want to point out is like, while this application seems small, right in the way that like React works like there's a version of this inside even a bigger application, right like there are usually like small versions of these like vignettes in a larger application.
[00:00:49] But as an application grows and the dependencies kind of are meaningful across the application, it becomes a little bit trickier. So this is kind of the problem that we're trying to solve. And so prop drilling is this idea that we have to go from parent to a child, to its child to its child to the component that actually needs a function or a piece of data.
[00:01:13] And when you have deep component trees, this becomes an issue, right? This is the component tree of our previous application. It's not that bad. The idea that we have to go through grudges plural is not terrible. But if we had a application that maybe was like a common board where, all right, we've got boards and those boards have lists, and those lists have cards, and so on and so forth.
[00:01:37] And there's users, and so a drop down for assigning one needs to know about the user sidebar. Right, it can get, even in this example, already increasingly complicated. And now if we want to move something from the sidebar to the main page, we've got to rethread those props all the way through.
[00:01:51] It becomes somewhat problematic just for maintainability. Right, as the application goes. Yeah, this, no need to commit this to memory if it stresses you out, its sole purpose is to stress you out.
>> It's mostly to look like a lot of things on this screen, right?
[00:02:06] And what we wanna do is to be able to skip a lot of that, and like say hey, I want to have the availability of any of the state or data anywhere in this tree and they can hook into it. Now, prior to the Context API getting released about a year and a half ago or so.
[00:02:29] There was a legacy Context API and if you went to the documentation, it was like, hey, don't use this, right? And the reason it was don't use this cuz the API was not stable. Right there. We don't know how this is gonna change, and if you rely on it then bad things could happen if we break it.
[00:02:47] And there were libraries that used it, like React Redux used it, right. And the argument there, which is well if you relied on that library and React made the change, the library could make a change and you would be okay. But if you did it bespoke in your own application it was a little trickier.
[00:03:02] Right? You were kind of on your own if the API changed. So if you wanted to skip this prop drilling problem, what you had to do is effectively look at a library like MobX+React or React Redux. And basically opt into this whole other paradigm of matching state, right?
[00:03:17] And there was all sorts of really tricky things you could do with hierarchy components and render props, to try to make it work and like in a previous version of the course, that's what we did cuz none of this existed yet. But recently there is now a kind of public context API that you can just use that allows you in the same way Hoax gave us reducer patterns out of the box, right?
[00:03:39] We get a lot of this kind of for free built into the library. And so the context API allows you to solve the prop drilling without having to immediately reach for a tool like Redux or Mob x or something along those lines. There's still a bunch of really valid reasons why you might want to, but the fact that you do not need to and it's a choice that you don't immediately have to make that jump, I think is really important.
>> So my question had to do with what you just said. When would be a point, like in your experience, if you'd like about large scale enterprise applications that you would actually feel the pain think now I have to move to a mob back solution or Redux.
>> Yeah. So like, I think I said this a little bit before with the reducers. It's like to say that's like 80% or whatever, some percentage of what you get from Redux is probably true, right. And so, for instance, like Redux out of the box supports middleware, right.
[00:04:37] You just plug in multiple middleware, no big deal. Use reducer does not right. Like Redux also gives you combine reducers and a whole bunch of other helper functions. Use reducer does not right now if you don't need those it's a wash, right, like, why would you pull in a library?
[00:04:51] At Twilio we have a product called flex, which is this idea that we give you the framework to build your own call center application, right? Now, if you have your own version of Redux, now we've got to manage two versions of Redux state we might consider, we use Redux now, but we might consider switching to the Context API, because it's just one less dependency that we have to manage for something we distribute, right?
[00:05:13] But there's a lot of things that come for free in Redux that you would have to implement yourself like we will implement a very naive version of middleware in a little bit, but like you just get apply middleware from Redux. React Redux does a lot of performance optimizations that you could do.
[00:05:32] Right, using the Context API. But are kind of the ones that come in React Redux are obviously battle tested and stuff along those lines. So there is usually a super set of features beyond what you get out of React. But if you don't need them, right before the bar before you need it, like basically if you needed any of it, you needed all of it.
[00:05:52] Now there's a lot more you can do in React before you need any of it right. And some cases like you might have, we'll see cases where we use a reducer pattern for very simple things that might will definitely not have justified Redux overall. And you might still use those kind of in that unique component state where you might use Redux for an overall application.
[00:06:10] So it's more of a yes end thing. For most of the simple cases, you now have it built into the framework. You don't need to necessarily deal with that extra dependency. But if you need all of the extra functionality and features of these more robust solutions, they are still available for you.
[00:06:25] So I don't think that either one obviates the need for the other.
>> Can you have both though? Can you use both?
>> We use both, we use both. We'll use both Redux and the Context API in different places, right? There are things like ephemeral state that I need to share across multiple components.
[00:06:43] I don't wanna put it in the Redux store. Because we use that for our model data, but a bunch of components need the same ephemeral state, we might spin up a context for that small part of the tree that needs it. While the overall data's being managed by Redux like smaller kind of pieces might use a reducer, or might use a context API.
[00:07:00] So we absolutely use both.