This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Understanding React" Lesson
[00:00:00]
>> Brian Holt: So let's actually start talking about React. And we're gonna do something kind of a-typical here with React in the sense of. Well just, for those of you that are snooping right now, I'm ignoring those global installs, I'm gonna come back to them later, okay? Because I know someone's thinking about like, he skipped that, I'm doing it on purpose.
[00:00:18] Okay, so, React. Now I would say many React developers even today people like me that have been writing React a long time don't know that you don't need any tooling to write React. You can write React, just plain old React today with no tooling whatsoever. That's exactly what we're gonna start doing right now.
[00:00:39] Just to show you that there is no, there is nothing behind the curtain, there is nothing mysterious going on here. This is really just a library that has function calls that produces markup, the end, right? That's it, so yeah, no ES6, no JSX, just barebone React. And we're gonna write that.
[00:01:00]
>> Brian Holt: So let's actually start addressing why React is useful. Why are we pulling this library? What problem it's solving.
>> Brian Holt: I mentioned many of you are coming from jQuery backgrounds, from Angular, Backbone, Ember, Knockout. I don't know, other libraries that I can't think of right now, Cycle. If you're coming from Cycle and not writing React already, then good for you.
[00:01:30] [LAUGH] So, yeah, we're gonna start talking about what React is. React is just kind of a view library. Now, that's a gross simplification. It does a little bit more than just a view library, but a good starting point for forming your mental model of what React is, it's just thinking of it as the view in the model view controller.
[00:01:53] Again gross simplification, but that's a good place to start. And I guess it's kind of worth addressing what happened to MBC in the front end. So, many of you come from back-end type positions. Right, you've written Django or Rails or a play like some of these different libraries.
[00:02:18] That aim to separate your concerns into models, views and controllers, right. You have the model that talks to the database, you have the view that actually talks to the client, and then you have the controller that kind of wires up the talking between the models and the views.
[00:02:34] That works phenomenally for the back-end, right? Like that abstraction makes a lot of sense because you have, this code definitely goes in the model, this code definitely goes in the view. And we have this just like little wiring layer between the two, right? Works amazing. Maintaining projects that are written well in MBC in the back end is a joy.
[00:02:55] So people decided, okay, can we take these kinda cool ideas and this good idea of separating concerns from the backend into the front end, right? And we ended up with Backbone. And Backbone's a good library, right? If you have written any amount of Backbone, it's usually not too bad until things go wildly wrong, and then it's horrible and people die and stuff like that.
[00:03:16] Just kidding. So we tried to take this abstraction built for the server and we tried to kind of shoehorn it into the front end. And we found out that this quickly kind of falls apart because there's no true models, there's no true views, and the controllers, these concerns kind of get blurry really, really quickly of what should go where.
[00:03:38] And so you end up with these mixed weird looking code basis and you know you have a problem, and you don't know if it's in the view, you don't know if it's in the model, you don't know if it's in the controller. And you end up with this really, really hard to debug, really hard to read a project.
[00:03:51] So people kind of starting exploring beyond backbone. Backbone was not necessarily the best abstraction for the front end and so we started coming up with these things like Angular and Ember. That's kind of start of shifting more towards a UI type of concerns, right? And those were really great, too.
[00:04:13] But we still kind of end up these problem with, I have this piece of code that needs to do something and I don't know where it goes. So we discover that we have problems with Ember and Backbone, I'm talking about older Ember, older, sorry, older Angular, older Ember of I have this concern and I don't know where it goes, right.
[00:04:32] I would say Ember is a little bit on the better side of this, Angular is a little bit on the worse side. But when you have a concern and you don't know where it goes, that's a real problem. One, for when you first write it but two, it's a bigger problem when you have a problem with it, right.
[00:04:44] So I write this particular piece of code, I put it on to the web I have a bug that if I don't instantly know where that bug is going to be, that's a real problem. So let me give you an example. Let's say I had some sort of JavaScript code that as soon as I clicked that React title, that it pops something up, right?
[00:05:05] I don't know, something stupid like that. If this was written in older angular, you can ask yourself, okay, so I have a problem with this particular,
>> Brian Holt: Piece of JavaScript, where does that JavaScript code live? Does it live in the directive? Does it live in the controller? Does it live in the other directive?
[00:05:23] Does it live in the scope? Does it live in the template? These are all perfectly viable places where that particular piece of code could live. And that sucks, right. Because now you have to go check seven places to try and find your boat. So, the smart people at Facebook/Instagram at the time said this is a problem.
[00:05:43] We want our code to be have a well defined place where logic goes and we want to have very easy to follow code flows. They kind of took that whole NBC idea as this is not good. We're not gonna follow this, we're gonna go with something else. So they threw that all out and they ended up with this kind of React idea that the best idea that people have come up with so far for UIs is just the basic request response cycle, right?
[00:06:12] You make a request to Web Server, you get back a response, right? As a user, I make a request by clicking on a button and I get a response by something happening back at me. This request response cycle made a lot of sense to people.
>> Brian Holt: So they kinda built on top of that and they kinda arrived at the idea of one rather than trying to separate concerns out for these different pieces of UI code.
[00:06:36] What we should do is we should take all of the concerns. And shove them together for very small pieces. So taking this example again of this React headline right there.
>> Brian Holt: I'm going to take all of the concerns for this behavior, for the mark up, for the, all that JavaScript, CSS, HTML, and we're just going to shove it all together.
[00:06:59] And it's all going to be right there for this very small component, right? So if I have a problem when I click on it, the problem is right there, right? Because all of the code is right there. And so by knowing what the problem is. I also know where the code starts right.
[00:07:16] Now that code could bring in other modules. But it gives you the start of the trail right. The post on the trail says, the debugging path lies this way. And it's dark and dreary and scary. So, yeah that's kinda the idea behind React, is we're gonna take all of our concerns, and shove them together for very small pieces.
[00:07:37] And then we're going to take these different pieces, and we're going to build bigger, and bigger applications as we go along. Question?
>> Speaker 2: Yeah it was just React versus Vue or Vu or whatever.
>> Speaker 3: Vue.
>> Brian Holt: I would say the React versus Vue questions pretty similar to the React versus Angular question, in my opinion.
[00:07:59] So it's just,
>> Brian Holt: I'd say Vue's a little bit lighter weight. It's really good for It's been a long time since I worked in Vue. So I think my best question is don't ask me. [LAUGH] That's not my best answer to that. My second answer is that I like I had a very pleasant time writing it, and it seems like they're going in a good direction.
[00:08:21] So check it out, I think that's probably the best answer for that. Any other questions?
>> Speaker 4: Another question in the channel. Sanjay asks what, I don't know. Basically, mixing a react with jQuery. How to do it if we want to do it, and those kinds of things.
>> Brian Holt: One can, and one should not.
[00:08:42] [LAUGH] So, what one can do and what one should do are totally different things. It can be done. And there's good examples of it. Like, for example Stripe has a really cool Jquery library for formulating currencies and stuff like that. I think it's called jquery.payments, if I remember correctly.
[00:09:00] This was a while ago when I wrote this, and I had to write a glue layer between react and this j query plugin. And it can be done, it works okay, it's just gross and messy, and It's a messy abstraction. So it can be done, but as soon as you start writing React you should really try and pull all the other libraries out of your particular application.
[00:09:23] So try and get rid of jQuery, try and get rid of Backbone, all of those different things. I'd also not suggest trying to marry React and Backbone. I've seen a lot of people trying to do that with not great success. I will say a valid migration strategy if you're on Backbone is to rip out the view layer of Backbone, put in React and then slowly move everything else into React.
[00:09:49] But you need to have the goal of migrating completely off Backbone. Don't try and leave this gross hybrid out in production. That's a bad idea.