JSX

[00:00:00]
>> Brian Holt: JSX, and we're on to core React concepts now.
>> Brian Holt: So again, I remember I watched Pete Hunt's talk, I just don't even remember which conference was that, but this would have been 2014, no 2013. I would have watched this in 2013, I was working at Reddit, and he showed this off.

[00:00:23]
And I was like, this seems like pretty cool. And then he started writing his HTML and his JavaScript, I was like, I'm out, I don't like this, I don't want anything to do with it. Take your demon magic and go away, right, [COUGH] it didn't make any sense to me.

[00:00:36]
And I was reading the story of how they ended up creating JSX, is they had created React, and they think this is a good idea, but they had to convince a bunch of hack developers to use it. Hack is a flavor of PHP, or that might be not quite totally true, but it's very similar to PHP.

[00:00:52]
And so, they hacked together this last-minute JSX thing to try and convince them, and that's like, the PHP developers were like, this is cool. We can use this, right? And then it turned out to be really popular back with the JavaScript developers as well. And so that's how JSX ended up taking off.

[00:01:08]
It was never intended to be the core use case for React, and yet it still is. And now not only does react use it, but solid JS uses it, you can use it with like Vite or with View and some other things as well, so it really took off.

[00:01:24]
So let me tell you about why I came back around when someone reframed this for me. Again, I'm old enough to remember JavaScript in our HTML. Where you click like an on click handler, and all the JavaScript was just shoved into the HTML, and it was gross, it was hard to debug.

[00:01:41]
It was like trying to debug minified code. It was like landmines throughout all of your HTML. And it was just the worst. And I spent a good part of my first job ripping JavaScript out of HTML, and so the inverse sounded just as bad to me. Is like, I don't want HTML in my JavaScript, right?

[00:01:58]
The reframing that finally got me to accept JSX, or at least try it out for a longer time, is we just wrote this, right? React.createElement("h1", { id: "main-title" }, "My Website"). What is this supposed to end up translating to? It's supposed to be this, right? We're literally writing code that mimics HTML.

[00:02:27]
Shouldn't we just write the HTML, right? Instead of trying to mimic it. And when I kind of had that reframe, I was like, okay, that actually makes a lot of sense to me. And when I understood how JSX is just a very, very thin layer on top of JavaScript, it's not really adding barely any semantics to JavaScript.

[00:02:45]
I was like, okay, I think I can tolerate this, and I have to have a build step anyway, so who cares? So this is what our pizza ends up looking like. In fact, let's just go write that. So open your App.js. Let's actually just create a new file here and call it Pizza.js, and then we're gonna add just one more character here, x.

[00:03:14]
>> Brian Holt: And we're gonna make our pizza component, we're gonna move that out of App.js into Pizza.jsx. Now, if you've watched previous versions of this course, you'll notice that I have gone back and forth several 100 times from using JSX as the extension to just using JS. And let me explain to you why, initially, we had to call it JSX because the tools required it, or else it wouldn't transfile from JSX to JavaScript.

[00:03:40]
And then famously, Dan Abramov, who's a well-known JavaScript engineer that was at Reddit, or sorry, he was at Facebook, he created Redux, and now he's at Bluesky. He tweeted one time, why is everyone calling this JSX? It's just JavaScript. And that caused a massive swing in the JavaScript community to go back to the other way of just calling it .js.

[00:04:07]
And so again, I try and just follow the sea trends but this particular course of what you'll normally see in the wild, if you're a professional React developer. The reason why is we're back on JSX now for this course, is Vite requires it. Vite will not run the JSX transformation unless you call it .jsx.

[00:04:26]
I don't even know if you can configure that away, I didn't really try. So we're back on JSX now, but I hope my point to you is that it doesn't matter. Who cares, right? Like, it's like the dumbest thing to argue about. Just do whatever your tools require, and don't think much more about it than that.

[00:04:45]
Okay, so go ahead and copy and paste. I'm gonna just cut this out of here, and I'm gonna put this in my Pizza file. I'm gonna put an export default Pizza at the bottom.
>> Brian Holt: And we're gonna just comment this, and I'm just gonna re implement it with JSX.

[00:05:14]
>> Brian Holt: So, const Pizza = (props).
>> Brian Holt: And you're gonna return, I'm gonna suggest here that you put an opening parenthesis, I'll tell you why in a second. And you're just gonna start writing your HTML, div.
>> Brian Holt: We didn't give this a class before, but we're gonna give one now.

[00:05:46]
But notice we're gonna call it class name, I think they've gone back and forth if they're gonna get rid of this. Anyway, the reason why they have you call this class name and not class is technically, the word class in JavaScript is reserved, right, for JavaScript classes. And so they didn't want to collide with that, so they called it class name.

[00:06:07]
Which is actually, I mean, if you have a x = document.getElementById, blah, you don't have to copy. I'm just proving a point. The way that you would get the class name of x would be class names. They went with the actual name of the JavaScript API, that's just where that came from.

[00:06:31]
They didn't make it up, right? Anyway, you'll get used to it, but you do have to call it class name instead of class, and your tools will catch that for you, so don't worry too much about it.
>> Brian Holt: Okay, and then we're gonna have an h1. Now, I could put props.name here, but what would happen?

[00:06:53]
It would literally display the text, props.name. But if I surround it with curly braces, you can put in here any JavaScript expression. And so, your question might be, what is a JavaScript expression? It's anything that can go on the right side of an equal sign. So, I could put,
>> Brian Holt: Right, this right half of it would be an expression, right?

[00:07:21]
So I can put props.name.toLocaleUppercase, and that'll work, right?
>> Brian Holt: Okay, same thing with our paragraph here, props.description.
>> Brian Holt: And there you go. That is JSX.
>> Brian Holt: Pretty straightforward, I think, right? I think it's simpler, compare this with this. I'm gonna say, almost certainly, unless your brain is broken, [LAUGH] like mine, which is frequently broken, this is just way easier to read, right?

[00:08:12]
This is actually what you mean, right? This is the markup you intend to generate. This is mimicking markup that you intend to generate. Okay, any questions about this?
>> Speaker 2: Yeah, I'm a bit curious about the use of the default. It probably doesn't have a meaningful distinction with a simple app like this, but can you give an example of when you might not want it to be your default export?

[00:08:39]
I know it's related to the module that you're exposed, I kind of don't understand the concept there.
>> Brian Holt: Yep, so I have down here, export default Pizza. And if we go over here, we need to import this from the other file, right? So we're gonna say, import Pizza from .Pizza, right?

[00:08:59]
The fact that this has no curly braces around it means that it is the default export of this particular file, right? So because I said default, you import it over here with no curly braces. Now, if I wanted to do it differently, you could say export const Pizza = Pizza.

[00:09:24]
>> Brian Holt: I forgot exactly what the syntax is because I never do it this way, but you would do something like this.
>> Brian Holt: Okay, now this is a named export here. And so now over here you would import this like this.
>> Brian Holt: Now, why would you ever wanna do it one way versus the other?

[00:09:53]
When you have named exports, now I can do multiple exports here. I can do export const blah equals, right? And now I can import two things over here, blah. People have very strong opinions about how you're supposed to do this or not supposed to do this. Some people are like, named exports all the time, default is an anti-pattern, and to those people I say, I don't care.

[00:10:19]
[LAUGH] I just don't care, it's the dumbest thing to argue about. I'm generally of an opinion that one file, one component, so therefore, default exports make sense to me. It's kind of a reliable pattern for me. Sometimes I'll do something where you can have both, by the way.

[00:10:42]
Which would look like this. Some of them would be inside of the curly braces, some wouldn't be. And I will do this from time to time, it actually will look more like this. So I'll have the Pizza one from this, and then I'll have like, testPizza, where I'll have to have a little like additional logic to be able to test it correctly, right?

[00:11:04]
And I'll have it do something like that, right? But generally speaking, I'm a one file, one component kind of person, and this makes a lot of sense to me. One thing I'm gonna call out here is, notice that you used to have to do import React from react.

[00:11:23]
We don't have to do this anymore. So, remember how this gets transpiled to React.createElement, right? So anywhere that you were doing React, you had to import React even though you weren't directly using it. Luckily the tools got smart enough to say, okay, if we see JSX, we're gonna import React for you.

[00:11:46]
So, not required anymore, but it used to be required. But you might see that in older codebases that haven't updated their build configurations.