This course has been updated! We now recommend you take the Complete Intro to React, v8 course.

Check out a free preview of the full Complete Introduction to React (feat. Redux and React Router) course:
The "Conditional JSX" Lesson is part of the full, Complete Introduction to React (feat. Redux and React Router) course featured in this preview video. Here's what you'd learn in this lesson:

Since the Header component will be reused on both the search page and the details page, it will need to hide/show the search field and the back button depending on where it’s located. Brian demonstrates how to conditionally include JSX in the component based on the value of one of it’s properties.

Get Unlimited Access Now

Transcript from the "Conditional JSX" Lesson

>> [MUSIC]

>> Brian Holt: We just integrated header into details. Now we're going to put it into a search, so they're going to share some of the same code. Let's go ahead and make that happen.
>> Brian Holt: Go ahead and, let's actually go back to header, that's actually what I want to do right now.

[00:00:25] Well just to demonstrate, notice this header is slightly different. There is an input here that's not gonna be present in the details one. Now we need to make our header a little bit more flexible that will conditionally show that either the back button or the search button and we're just going to do that with some properties.

[00:00:41] Because search knows that if you need to show the input as this detail knows it needs to show the back button. We'll just pass as in this properties to header.
>> Brian Holt: Inside of headeder.jsx. Let's go ahead and abstract that out. First you we're gonna do is we're going to do this let utilSpace.

[00:01:06] And this is going to be where we're going to stick the component that we want to use inside of the header, and then want to say, if this.props.showSearch.
>> Brian Holt: Then we are going to say utilSpace = input, type=text classname = search-input and placeholder = search. This should look pretty familiar.

[00:01:46] This is exactly what we saw before. I'm going to say value = this.props.searchTerm and onChange=this.props.handleSearchTerm.
>> Speaker 2: It's so much nicer than doing it just like ES5 string concatenation.
>> Brian Holt: Absolutely. I find JSXP very, very compelling.
>> Speaker 2: I mean ES6 and string literals aren't terrible but-
>> Brian Holt: I think it's-

>> Speaker 2: It's still nicer.
>> Brian Holt: Yeah, definitely.
>> Brian Holt: Notice we're referring to props that we don't necessarily have yet. This is some personal advice to you is that, just write the code as if it was already there. Just expect it to be there, and then go figure out later how to get it there.

[00:02:55] And that that just lets you write the code right now and then fix it later from some engineers this is counterintuitive most of us want like make something work and then use it. I think we talked a little bit about this yesterday but with reactor two usually a good idea to just assume something was going to happen and then later go make it happen.

[00:03:19] Big reminds me I was reading yesterday on Reddit that Stephen Hawking threw a party for time travelers and then he announced it the next day and no one showed up, unfortunately. But I thought that was pretty funny. [LAUGH].
>> Brian Holt: Else you want to make utilSpace equal to our back button.

>> Brian Holt: And you can actually just go ahead and rip it out from down here.
>> Brian Holt: Now we have utilSpace and it's gonna depending on this boolean they're going to pass and later we're just going to say utilSpace so whatever it is in utilSpace put it down here. Any questions about that?

[00:04:15] This is kind of how you do conditionals in JSX, this is the way that typically it's on. You can get fancy with ternaries, but I don't recommend it. Ternaries tend to be more confusing than helpful, for very basic things ternaries work okay but for entire reactor components it gets pretty messy.

[00:04:33] There's also a conditional components that you can use, you say, something in the effect I've never used them before but it looks something like, if condition=this.props.searchTerm and then you put blah in here. Don't copy this. I'm just giving a demonstration. Else, this. You can do something to that effect.

[00:05:06] I think it's messy and muddles up everything, so I elect not to. But that's another open source library you have to pull in to be able to do that. That's not part of react. I find this to be much more preferable. Another thing people ask me is why don't I say util = input, and then I'll do an if statement to change it?

[00:05:27] Well you have to think that you're creating react components in here and that's not free. It's pretty cheap but it's not free. If you do it this way, nothing's wasted. That's another reason that you might not want to do it that way.
>> Brian Holt: Any question about this? Kind of make some sense of why we're doing it this way.

[00:05:54] Something I wanted to, okay go ahead.
>> Speaker 3: Somebody is asking that they thought that JSS tags had to be capitalized.
>> Brian Holt: Down here. Notice we're not doing utilSpace. This wouldn't work, but this isn't really, this is a variable holding a react component and not a react class. You need to separate those two in your mind.

[00:06:21] Because we're just doing it like this, this is fine because this is just a variable, this is not a react component, it's just a variable that happens to be holding already rendered react components. I could see how that's confusing. If I should say it this is the way this works, if you feel better about calling this capital U, UtilSpace.

[00:06:43] It's not exactly accurate, because then you would miss some sort of constructor. But you can do it if you want. Nothing's stopping you.
>> Brian Holt: Any other questions?
>> Brian Holt: Cool. Kind of a another tangent I wanted to run on down real quick is that, something I like about react, and something that you need to get used to as you're writing react components.

[00:07:12] We tend to think of UIs over time, that you have a user interface, you do something that changes the state, and then it changes over time. You have to think about these user interfaces, ask people are gonna interact with them, as the server comes back and it's these Interfaces over time estate changes.

[00:07:31] That's not the way you wanna think about writing react you want to think about react given properties this is what it's going to look. It's more of a snapshot mentality rather than over time. If show search do this, otherwise do that right. It's very synchronous, it's a very now type experience.

[00:07:52] And I think this is cognitively less of a load to think through. You don't have to think about what is this going to look at over time. I just have to think about given such state it looks like this, does that kind of makes sense?
>> Brian Holt: It's like I said it's way easier to think about things otherwise you're thinking about over time I'm drifting towards these different particular things whereas I can just say, nope it's input output.

[00:08:20] Input of parameters, output of this component, that's all it is.
>> Brian Holt: And that's actually a very functional mentality, that's how you tend to think about functional programming as well. It's just a series of transformations given some sort of input.
>> Brian Holt: We are going to have to do some prop types as well.

[00:08:50] Let's go ahead and do that. This is a create class, so we're gonna stick our prop types up here.
>> Brian Holt: Let's go ahead and bring those out too. We're gonna need function, func, bool and string is another thing that, I have a lot of things complained about with prop types.

[00:09:14] One of things I like to complain about is some of them are shortened and some of them are not, and it just drives me absolutely crazy, it's func and bool but it's not num, no it's number. I just hate having to either to shorten everything or shorten nothing.

[00:09:34] Anyway, sorry, rent over.
>> Speaker 2: [LAUGH].
>> Brian Holt: It's getting later in the day. I'm getting cranky. [LAUGH] HandleSearchTerm is going to function that showsSearch is going to be a boolean or a bool and searchTerm is going to be a string. Any questions about that?
>> Speaker 4: If you have showSearch is an optional prop type, but if you have showSearch, then wouldn't you want searchTerm and handleSearchTerm to be required?

[00:10:17] How would you define that?
>> Brian Holt: I don't know if you can do this, cascading is required. I'm not aware of aware of a way to do that. Yeah as far as I know is just is required or not. I can see where they would be useful but I don't know.

>> Speaker 2: Suppose you could bundle it as like an object and then the properties, I mean is not pretty.
>> Brian Holt: Yeah.
>> Speaker 2: [CROSSTALK].
>> Brian Holt: This is a really complicated and scary mess to get into. And this is just a bugging help. It's just kind of type hinting so doing much more work than this is tough for me to justify.

[00:10:54] At that point I'd rather just use typescript and the typescript take care of it. And that interested in it. The nice thing about making these definitely don't make these is required. Because now if I just don't give cert showSearch, it does just assumes that showSearch is gonna be false and so now if you go back and look at details .JSX, actually don't have to changes this at all because I'm not passing that showSearch as required.

[00:11:20] It's just going to default back to the back. And that's really nice.