This course has been updated! We now recommend you take the Complete Intro to React, v7 course.
Transcript from the "JSX vs. createElement" Lesson
>> Speaker 3: Question, is there a difference between React.createElement and React.DOM.div, since React.DOM sits in a separate package now?
>> Speaker 4: I'm not sure I understand the question, if you could take a look at it in the chat room.
>> Brian Holt: I lost my computer, so, but I think I understand the question.
>> Speaker 4: Okay.
>> Brian Holt: So, which is a salient point to bring up. If we come back here to my tile.js, what is- remember this is being run through babble now, so this is actually being transpiled to something different. Something that we don't actually see unless you actually flip the compiled code.
[00:00:38] What this actually gets compiled into is React.createElement('div')
>> Brian Holt: Null, blah, right, whatever the children of that particular element is. And all that React.DOM.div stuff is just, it's the factory, right? It's just a thin wrapper that makes it a little bit easier to write. So, this is what it's actually being transpiled into.
>> Brian Holt: And that's it, it's readable. You can actually go and read it. In fact, if you want to, let's just go read it. See, bundle.
>> Brian Holt: And it's gonna be this.props.
>> Brian Holt: Title.
>> Brian Holt: So, I must've built this for production, which is fun, which is why this is not super readable.
[00:01:38] That's been went through uglifies. Anyway, a is going to be react I promise.
>> Brian Holt: That's what module is, but anyway. So, as doing createElement h1.
>> Brian Holt: Styles object.
>> Brian Holt: this.props.title. This is the source map. That's what I'm looking at. Right, cuz it's gonna be anyway.
>> Brian Holt: We're looking at source maps.
[00:02:11] Anyway, so that's what's happening, yeah, go ahead.
>> Speaker 3: Another question. They wanna know if they can remove the bar div in each one no?
>> Brian Holt: Yeah, please do.
>> Brian Holt: Yep, that's, you'll no longer do that.
>> Brian Holt: Any other questions?
>> Brian Holt: All right, I got like two more points to make, and then we'll break for lunch.
>> Brian Holt: Yep, so let's go rewrite client.app real quick. So, you can drop that div stuff right there. You can drop the MyTitleFactory as well. I showed you how to use create factory, and you'll almost never use it, so [LAUGH].
>> Brian Holt: In fact I will venture to say, that certainly more than half of React developers don't even know that there is a react.create.factory method, because it's no longer useful with jsx.
>> Brian Holt: Okay, so I'm just gonna delete all that. I'm gonna put div.
>> Brian Holt: And then, what's cool is I made this my title component, right? I can actually just write it as if it was a real HTML element. And then I just give a properties, again like, I would a normal HTML element.
[00:03:39] Props are cool, color = 'rebeccapurple' and since there's no children inside of it, we're just going to make it a self-closing tag. This is something that bears mentioning, I know a lot of us like to leave off the slash on inputs, and stuff like that. In JSX it is no longer optional, you must put the closing tag if it's a self-closing tag.
[00:04:05] Just get used to doing it.
>> Speaker 4: Can I ask you a question about that?
>> Brian Holt: Yeah.
>> Speaker 4: Does it need the actual back slash?
>> Speaker 5: Yeah.
>> Brian Holt: Yeah, must be there.
>> Speaker 4: Wow, okay.
>> Brian Holt: Yeah, that's a JSXism.
>> Speaker 4: Okay.
>> Brian Holt: Furthermore, you can self close things that are not self closing.
>> Speaker 5: Yeah.
>> Brian Holt: That is valid.
>> Speaker 4: Okay.
>> Brian Holt: Whereas obviously that's not valid. HTML.
>> Speaker 4: Thank you.
>> Brian Holt: Yep.
>> Speaker 6: So, the name of the element can be anything? It doesn't have to match what that variable name was earlier?
>> Brian Holt: My title?
>> Speaker 6: Yeah.
>> Brian Holt: I mean, it needs to match this, right?
>> Speaker 6: Okay.
>> Brian Holt: Cuz this is going to be the method that calls, right?, because this is just a function, and it's gonna use that to create a new component, right, so, yeah, it does have to match that.
>> Brian Holt: Good question. Another thing that bears mentioning, it must be uppercased.
[00:05:11] It's not even a convention, they actually made it a requirement now in React. If it's uppercase it's a component that you created, if it's lowercase, that's literally what it's going to output to the dom. Right? So, it's literally going to put a div on the dom. Why did they do that?
[00:05:27] Because web components, right? The web components are coming, so we need to be able to do things like, x my component, right? Because we literally want x my component up into the dom, right, because that's going to be a web component. If you don't know what components are home of the discussion go check it out.
[00:05:45] Super cool. But suffice to say, if it's your component, must be upper case. If it's some, if it's literally what you want to be put out to the dom like that's the tag name you want then do lower case.
>> Speaker 3: Oscar's asking why we're using create class instead of the ES6?
[00:06:04] Extends reactor component.
>> Brian Holt: I'm teaching this way, because it's easier to teach. [LAUGH] There's three different ways to create react components. I will eventually show you all three of them, but we're starting with React createClass, because that is the easiest to understand. And I try to work up from easiest to understand to knowing all the [CROSSTALK].
>> Speaker 3: Do you use the es six version in your React code, or do you use createClass?
>> Brian Holt: I use createClass, cuz there's less to do. There's less boiler plate. I think, ES six classes are the way that React is moving. Create class works for now. There's also going to be stateless functional components, which we'll use as well.
[00:06:48] Which are actually probably the best if it works for you. Good question.
>> Brian Holt: This, every, yeah, I need a peru.
>> Brian Holt: Okay, so let's go save that and make sure that still works. Looks like everything's still running, so refresh and we're still building. So, everything's still okay.
>> Brian Holt: Questions about this, what's going on here?
[00:07:21] This all make sense?
>> Brian Holt: So, now, that you're kinda starting to see how these components start building, and becoming bigger and bigger things. Like my title could be five more components, which could be five more components. You've got these fractal trees of crazy stuff. But the nice thing is, they are still broken into bite sized pieces that you can understand.
[00:07:39] And by separating these concerns into. Or separating these components into packages, they are easier to maintain. One of the things to remember here, is, like, what's actually happening underneath the hood? This is just being compiled to function calls, right? There is no black magic here. Now, that you've actually written it by hand, you can see like,
>> Brian Holt: You know exactly what's going on. So, something that people initially get frustrated with is like, well, I would like to put another div here, and more mark up in here. But why doesn't this work? Why can't we have two siblings be the top level component? Well, if you think about this in terms of just being like function calls, right?
[00:08:42] And that must be one top level component. So, what you'll see a lot of people do is they just wrap everything in a div. And that's fine. If that's what you need to do, then just do that. Yeah.
>> Speaker 4: Question from Dinarte wanting to know if there's any recommendation on how to break your app into components.
[00:09:02] And if you're gonna cover this later.
>> Brian Holt: I'm sure I'll talk about it, it's a good question. I think, many of times should be intuitively obvious that have a separations of like this is a thing, right and I can separate this concerns other thing then I can make it reusable, or whatever, right?
[00:09:23] The only thing I would caution against is, that gets people breaking things into absolutely tiny, itty bitty things. And usually that's not a good idea either. There's balance to be made there of decent robust pieces of code, and being way too small. And the danger of going way too small is it gets harder to reason about, and maintain and think about.
[00:09:44] But you also get a performance hit if you start having way too many components, right? Cause if React has to keep track of 50,000 components instead of like 5,000, that makes a big difference. So, use your intuition, I guess. I think that's an age old question of when do I separate something into a module, right?