Check out a free preview of the full Firebase with React, v2 course:
The "Higher Order Components" Lesson is part of the full, Firebase with React, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve creates a higher order component, which takes a component, wraps it in another component, and returns it.

Get Unlimited Access Now

Transcript from the "Higher Order Components" Lesson

>> Steve Kinney: So, we've got some sub-collections. What I'd really like to do is look at using Firebase, the context API, to create one of those high order components like that withRouter, cuz that's another pattern to hook into Firebase that we might really like in our React application. And this one's not gonna be too bad, cuz we're gonna cheat, and we're going to leverage the work that we already did with the user context provider before.

[00:00:26] So, a higher order component is effectively a component that returns another component, right? Based on stuff like higher order functions, because we asked all about the functional programming, right? So, basically it's a component. You give it one, it wraps it in a new component that passes more prompts in.

[00:00:44] And that's the magic of JavaScript in closures, everything just kinda works. All right, so let's go ahead. We're gonna make a new component called withUser.
>> Steve Kinney: Right, and withUser. We're going to put in react. And we're gonna bring in that user context. We could write all of the code that we wrote before in that user context, where we were subscribing to everything, so on and so forth.

[00:01:20] But we already wrote it. [LAUGH] I don't wanna write that code again, I didn't like it last time I wrote it. I have it written once and I'm not doing it again. So, make a new component called withUser and it will take a component as an argument. Which feels weird, but look at that withRouter, withRouter took our Post Page component and returned a new component.

[00:01:45] That passed in all the React writer stuff. So, we're going to basically implement that pattern, so it's no longer black magic to us. And we could figure how to hook in the Firebase with it. So, we're gonna make a new one called wrapped component.
>> Steve Kinney: And that wrapped component is gonna take some props, and it's going to return.

>> Steve Kinney: Whatever component we've passed in, pass in the user, and then like whatever other components, or like whatever other props it takes, right?. Whatever other props you passed in, those props but also the user.
>> Steve Kinney: Mm, curly prices are fun. I gotta hope the code doesn't bite me twice here.

[00:02:48] Famous last words.
>> Steve Kinney: Cool. And then we just return that wrapped component. Again if this looks gnarly, just remember it takes a component and returns a component that take some props. Whatever those props that got passed in it adds user on to those and gives you back that component.

>> Steve Kinney: We do one other thing just for debugging happiness because I feel the need to be responsible. Which is, bubble will go ahead and use the name of a constant or the name of a class to give your components a display name. So, when you look at them in the React tools, you see like, the name of the component, otherwise if you ever saw like just _class, that's what they're called otherwise.

[00:03:44] And so most of the components you write normally get names at compile time, or the build process puts in the part that gives them names. In this case we're dynamically generating a component, so we're really quick gonna just give ourselves this function get, guess I do const getDisplayName, that's gonna take in WrappedComponent.

>> Steve Kinney: And what it's gonna do, it's gonna look at the name, this is gonna get the name of a component, and so we can basically take the name of that component and name this component that, and we'll call it withUser. So, there's unfortunately, over time, there's a bunch of different ways it could have a component name.

[00:04:35] So, it's either got a displayName,
>> Steve Kinney: Or a name. Or if all us fails, just call it component.
>> Steve Kinney: And then what we will do is, we'll say that this.
>> Steve Kinney: New Wrappedcomponent.
>> Steve Kinney: DisplayName.
>> Steve Kinney: With user and then whatever it was named previously. This is totally optional but let me just tell you right now, if you don't do this eventually when you go to debug your code like two months from now, nothing will make any sense and everything will just have no name and you'll be really sad.

[00:05:22] This is what Redux does. When you do connect this happens to you out of the box, really we're just dispelling myths right now. All right. So, go with user now with postpaid we can bring in with user.
>> Steve Kinney: There it is. And we'll just wrap that as well.

[00:05:46] So, I'll say with. And there are helper methods like compose that make this a little bit better. So there, you can just say, compose, give it a series of functions and then the component, and that just runs it through all of them. It's the same as this, but it looks prettier.

[00:06:02] So, we'll say with user, and now we should have, we'll console.log the props first.
>> Steve Kinney: When this component mounts.
>> Steve Kinney: Look at that, along with match and all the other stuff, look who we got. We got the user, right pass into that component as well. So, these are the ways that you don't have to pass everything down through your application.

[00:06:35] You basically hook up in the Firebase with the common things that you need. You can pas in the comments as you need them, so now what we can do is we can basically say const user equals this.props
>> Steve Kinney: I'll put the user in there. All right,let's try it out.

>> Steve Kinney: And say we've got the username passed in, right? So just again, some interesting state management tools that you're not like at the whim of just like kind of at every component mount, hooking into everything, right? And especially with the provider, there is a thing that we kind of didn't talk about that the provider is really good at which is, we're making that first query once.

[00:07:22] So, if many components are using that provider, that's the same query being fed to all of them. It's not like you have ten components that need the user that are all asking hey, user slash whatever the new idea is, right? Because those are each kinds of query. This is one query done by the provider, passed to any component that needs it, right?

[00:07:42] And since we're subscribing, that means every time the user changes, which is probably not that often, it's still one query, rather that every component asking for it. So, being clever with state management can also save you money.