Check out a free preview of the full Advanced State Management in React (feat. Redux and MobX) course:
The "Providing a Display Name to HOCs" Lesson is part of the full, Advanced State Management in React (feat. Redux and MobX) course featured in this preview video. Here's what you'd learn in this lesson:

Steve finds a problem in the component name using the React Dev Tools and shows how to fix it.

Get Unlimited Access Now

Transcript from the "Providing a Display Name to HOCs" Lesson

[00:00:04]
>> Steve Kinney: Now, everything looks great. But there's a very sneaky little problem.
>> Steve Kinney: Let's open up the developer tools. If I go to the React tools,
>> Steve Kinney: I can see the component hierarchy and normally when you look in this view,
>> Steve Kinney: It's hard to make that font a little bigger, but you can see that it knows the name of the pizza calculator class.

[00:00:39] It know the name of the application, but remember how I created that anonymous class? It says, class and that's not great. Worse, there are situations where you can just get unknown there which is not helpful in debugging. And so while we're big fans of this pattern, it does have a problem, a problem with a very easy solution.

[00:01:01] The way that components get names is a lot of that happens during the babble translation process, right? It goes and finds your classes, well that class has a name. It names the component. If you use the stateless functional components, it uses function.name to figure out the name of those.

[00:01:17] So all we need to do is figure out what to name this. Now, because it's a factory, we don't want to just call it with pizza calculation. We want to know what the child component is. If you've ever used, and we'll see this later in React redux which is, you'll see connect and then the name of the presentational component, right?

[00:01:40] It's basically using the name of the component that was passed in and then wrapping it in more text so you can get a little more clarity on what it is. So we can do that, we just have to be mindful and implement it ourselves. So let's do that together.

[00:01:53] So you have two choices, I can either store this in a variable and then just say whatever that name the variable, I'm not gonna do it but I can.
>> Steve Kinney: We then have to return the container.
>> Steve Kinney: I could say, Container.displayName and I do have to be a little careful here because I could have stateless functional components which have a dot name property or the ones I used for making a class which have a dot display name property, so what I'm going to do is this.

[00:02:40] I'll use a template string, and I'll say with pizza calculations. And again, this is kind of silly and arbitrary, like this would likely be with current user, with tweets, with marketing campaigns if this some great app I was working on. With whatever it is, whatever the state that you're passing it in the ability to manage it, would be what this is with.

[00:03:02] And that way if you do decide to compose more than one of these, you'd see current user component with current user with campaigns. You could actually see the entire chain. So it becomes very clear when you're debugging. And so we'll use a little bit of string interpolation here.

[00:03:20] And we'll say wrapped component.displayName and if that is false we'll go with WrappedComponent.name. So whichever one it has will return that.
>> Steve Kinney: So now if I go into the Tools, you can see that I have with Pizza calculations, Pizza Calculator. I know exactly what I composed in the de-bugging tools.

[00:03:49] My code worked without this, but I care about my co-workers. And the most important co-worker ever, future me. And future me will be very clear, cuz I can't tell you when I'm going to try to find a given component to debug a large application. And it's just called unknown or underscore class two, how not helpful that is for me finding it in the code base.

[00:04:07] This is a very small app. But our codebase is very, very big so this is incredibly helpful. I will show you some shorthand which is, you saw that I stored in the variable, put this on the class itself, and then returned that class. Remember when I was doing all that kind of trickery with just having state and the arrow function so I didn't have to bind this anymore?

[00:04:28] There is also more trickery I can do to avoid this intermediary step. So we'll implement that as well. So we'll go back, we'll get rid of this. And we'll just immediately return this again. So this trickery I used, these are methods on the instance of the class on each individual component that I create, right?

[00:04:55] But when I say container.displayName that was on the class itself. It turns out that the friendly folks on TC39 have given us syntax for this.
>> Steve Kinney: This will be on the class itself.
>> Steve Kinney: Then we can go ahead.
>> Steve Kinney: Cool and that should give me the same effect.

[00:05:40]
>> Steve Kinney: Exactly the same effect. So it's a nice short hand that gives you a convenience method for debugging later on. And again, makes it very clear all the wrappers around this component so that you can see. I think a big problem with the container pattern, and we're gonna see this with the next pattern, is that it's kind of a black box.

[00:05:57] It's called, whatever container. And yeah, you can dig into the code and you can try to suss out what it is. But remember when we were looking at that thinking and react piece, and there's, hey being really explicit makes it very clear, everything going on your code, even if it's tedious to write.

[00:06:12] Here we get to strike a balance between now being able to compose components with different kinds of state without passing it around all the time but also being very explicit about where that state is coming from. So we can have our cake and eat it too. We just have to you know embrace these patterns and get really comfortable with them.