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 Intro to React, v3 (feat. Redux, Router & Flow) course:
The "React Paradigm" Lesson is part of the full, Complete Intro to React, v3 (feat. Redux, Router & Flow) course featured in this preview video. Here's what you'd learn in this lesson:

Comparing to other frameworks, Brian reviews the philosophy regarding the React's approach to building applications. Brian takes questions from students.

Get Unlimited Access Now

Transcript from the "React Paradigm" Lesson

[00:00:00]
>> Brian Holt: Hopefully now you're seeing more things kind of come together, right? The fact that you can make components up of other components means we have some pretty powerful patterns at our disposal. We can create reusable components like a datepicker, right? And then we can reuse that datepicker throughout our entire website.

[00:00:20] I'm sure you could see many instances where this can be useful.
>> Brian Holt: So yeah, we can use these components to encapsulate logic, markup, and style. Kind of compress those all together and then ship them out in individual pieces. And we're kinda getting at what the core of what React is all about.

[00:00:42] So at least for me, I used to write Backbone, and I used to write a decent amount of Angular pre-1, 0.8, I think is what it was when I was writing Angular, maybe Angular 1. And they were kind of all-inclusive frameworks, right? They kind of emulated MVC on the server.

[00:01:02] It felt a lot like writing something like Django or Rails or something like that, where you'd have the model, you'd have the view and you'd have the controller, right? And you'd have the model set in one end, you'd have the view set in the other, and then the controller is kind of routing to each other.

[00:01:14] This is an amazing paradigm on the server, really there's not many better ways to write servers. And we kind of thought, well, this is a really great way to write servers. Why shouldn't we try this with the client, right, and it worked okay, right? It was better than writing the jQuery spaghetti code that at least I used to write.

[00:01:32] But over time we kind of see kind of the cracks show when you have a large app, right? The real problem is that you'd have these models, one model'd be using a bunch of different views, right? And then you have this controllers doing all sorts of crazy routing from one model to many controllers and many controllers to one model, right?

[00:01:50] It was just many to many mess, right? That's kind of what ended up happening. So some really smart people at Facebook decided that this was not necessarily a very good way to write a code. And they kinda yearned for the days where we could just write some markup on a page, and it just worked, right?

[00:02:09] So they kind of went forward with that idea, that well, why don't we embrace the paradigm of what's on the web, which is components, right? We would have these bits of markup, which had CSS that would get applied to them. And then we could reuse these different pieces of markup all over the site.

[00:02:25] So they kind of embraced and leaned into this pattern and said, well, why can't we create these component that then we can render out to the DOM? And so that's kind of what they started leaning into, and we ended up with React components. And a React component is just an encapsulated piece of a component, right, behavior, style and markup, HTML, CSS and JavaScript.

[00:02:51]
>> Brian Holt: Now this ends up being really, really powerful because it's a natural way to think about the web, right? It's a natural way of creating interfaces. So rather than having models, views and controllers all separated, that separation of concern doesn't necessarily make a ton of sense for interfaces.

[00:03:09] So what they did was they took models used as controllers, they shoved them all together for very, very small components, right? So everything for a component lives inside of one file basically, right? Now this is really, really awesome, because if something breaks, it's all right there, right? You don't have to go through multiple files, right?

[00:03:29] How many of you have ever debugged an Angular 1 app, and you look at some component that broke on the page. And you have no idea how it broke, right? It could be in the directive, it could be in the controller. It could be in the template, it could be in the service, I can go on, and on, and on of where all the different places this could live.

[00:03:49] The cool thing about a React component is due to the encapsulation of how these components work, if you see something that breaks on the page, you have a pretty damned good idea of what happened, right? Because it all lives right there in that one file. Now I'm kind of exaggerating a little bit, right, because modules can break and etc.

[00:04:11] But you always have a good starting point. So this is all getting to why I love React. React is going to be more verbose for sure than Angular, right? You can write amazing interfaces with Angular with very, very little code. However, when you go back to maintain some of these very clever Angular apps, I'm speaking on my own behalf, right?

[00:04:29] I wrote crappy Angular, I own that. [LAUGH] But maintaining some of these clever Angular apps is atrocious, it's nightmarish, right? With React it forces you into such a paradigm that it's much easier to debug, it's much easier to maintain. It's much easier for someone to come back later, yourself or someone else and read through the code and kind of understand because it's a very, very explicit.

[00:04:55] But this comes at the cost is that you write more code. It's physically more keystrokes to get it out. So that's kind of the paradigm of why React is the way that it is. This affords some other really interesting patterns which we're gonna be getting to throughout the next couple days but that´s where we´re gonna start.

[00:05:12] Yeah?
>> Speaker 2: It´s just a couple of clarifications or questions on the chat about why we need null parameter.
>> Brian Holt: Yep.
>> Speaker 2: And people are just saying the second parameters is the set of properties, attributes, that can be passed in.
>> Brian Holt: Yeah.
>> Speaker 2: First is the tag, the second is properties-

[00:05:28]
>> Brian Holt: I'll talk about it here in just a sec.
>> Speaker 2: The third is the child element and then yeah, why do we need to do two React.createElement together, and you're just showing nesting.
>> Brian Holt: Yep, yep, so to talk about this null right here, you could also pass an empty object.

[00:05:51] That's fine too. So what this is, this is all the attributes or properties that's going to be passed to that particular element. So for example for a div, let's say you wanted to give it this particular div an ID of, let's do this one here. An ID of my first component, you'd say id: 'my-first-component'.

[00:06:18]
>> Brian Holt: So now if I refresh this and I look here inside of my element, notice I got the ID right there of my first component right? So this is how you pass attributes to these particular things. Now we're gonna get into, we can also pass attributes to my title as well, which we'll do momentarily.

[00:06:35]
>> Speaker 2: And then one more clarification is you're talking about Angular 1, right, with everything being split apart?
>> Brian Holt: Yes.
>> Speaker 2: Is Angular 2 and 4, whatever.
>> Brian Holt: I don't know anything about Angular 2 so.
>> Speaker 2: Okay, you're saying that-
>> Brian Holt: So all of my ragging on Angular from here forth will be on Angular 1.

[00:06:52] Thank you for that clarification. [LAUGH]
>> Speaker 2: Yeah, a lot of the frameworks are coming in to this new paradigm of putting your mark up, your CSS, your component and everything into one file now.
>> Brian Holt: Definitely, no, it would be fun and useful to compare this particular course with Lucas' course on Angular 2.

[00:07:14]
>> Brian Holt: Cool.
>> Brian Holt: So yeah, someone asked about why we're doing multiple createElements, right? This is how you create, for example, a div, right, and then inside of that div, right, so notice that we're still inside of this particular parenthesis from this one. We're doing nesting right, and here instead of putting text, we can actually put more createElements, right?

[00:07:37] It's like HTML, there's infinite nesting that you can do. So that's what's going on there.