The underlying AWS mobile CLI used in this course has changed it's API. If you're starting to learn AWS, you may want to try the latest course. We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Transcript from the "React Application Review" Lesson
[00:00:00]
>> Steve Kinney: So we're gonna look at this React application. I'm gonna take you on a tour of it. This React application right now, it's like a brand new Create React application. It's managing all of its state in memory. And it doesn't have any back end. It doesn't have any sense of authentication, or authorization, or anything along those lines.
[00:00:18] It just is, again, a very simple, just a few components on the page. And this is an application for keeping track of all the people who have wronged you, cuz that's difficult at times. As I get older, there's more and more people that need a place on that list.
[00:00:33] And so sometimes, being an engineer, you're trying to scratch your own itch, and you're trying to build the application that you need. And maybe other people find it useful. And so I hope, as we build this application, and give it a back end, and give it authentication, eventually give it real-time push and stuff that I don't know if any grudge list really needs, we'll kind of build in all of those features.
[00:00:51] We'll also build a second application in a little bit, as well. But this is kind of our main application as we go through. So let's actually switch gears and take a little bit of a look at a tour of this application.
>> Steve Kinney: I'm gonna check out a new branch.
[00:01:11] What should I call this new branch?
>> Steve Kinney: really-live, okay, gonna have our branch. We'll kinda push up to it as a we go along. This branch is a little bit changed from a normal AWS Mobile Hub application, insofar that I added some of the Mobile Hub specific stuff to gitignore.
[00:01:32] So you should be able to pull in some of the changes. Normally, you can figure all this back end in your repo, you probably wanna commit it to source control. So this is like a few extra additions to gitignore. But your application, you can actually configure your back end in this same repo and have all that infrastructure set in code.
[00:01:49] A lot of times, well especially with DevOps stuff, it's one wizard. It's like configuring all these servers and then went on vacation and nobody knows how anything works. In this case, a lot of your back end infrastructure is committed as code. And you can check in the version control, you can see how it changes.
[00:02:06] And you can modify the infrastructure and push it back up. We just have those things in gitignore, because sharing is caring. Right, so that branch, the really light branch just pushed up. Right now, it's just master. We haven't made any changes to it yet. We're gonna take a tour of the application.
[00:02:22] Then what we're gonna do is we're going to see how easy it is to kind of deploy a full stack React and Node application. Right, all of the code will be in this application, our back end, as well as our front end. But it won't just be like a little toy app on a single server somewhere.
[00:02:38] It's going to be a full AWS powered, scalable infrastructure from day one. First, let's just take a tour of the actual React code, though. This application started it's life as a Create React App application. So React applications start with a single component mounted to a single element in the DOM.
[00:03:03] So in this case, there is, if we looked at the index.html, we would see that it's got a head and it's got a body. And it only has one empty div in it, which has the ID of root, which is all we need. Cuz we're gonna pull in React, ReactDOM, our basic CSS file, this application component, and mount it onto the page.
[00:03:20] So this is the kind of source of truth of our application. Inside of Application.js,
>> Steve Kinney: We're gonna pull in, we have a few helper components which is a list of all of our grudges and a little form for creating a new grudge. We're not really gonna need to work with these.
[00:03:38] I've had them made them components so just basically get them out of these files, so they didn't have to touch them too much. But Application, this component, holds on to some amount of state. In this case, it's an empty array of grudges that we're keeping in memory. We have a method for adding a grudge, and all that does is a text a single grudge and pass it on to the array of all the existing grudges.
[00:04:02] So if we fill the form, that grudge is added on, and we can see it on the page. All of this is happening in memory. So the moment you refresh this page, everything's gone, right, which makes it kind of not great for it's purpose. But you know, what do I know.
[00:04:16] Removing a grudge, we just filter out the grudge that has that ID. There are obviously more robust and sophisticated ways of managing state in a React application. But the goal is to kinda keep it simple and into one component. A very handsome gentleman did an entire two-day course on Advanced State Management in React, you should totally watch it.
[00:04:38]
>> Steve Kinney: Toggling, we're basically gonna find all the other grudges, change our one grudge, and then put that changed grudge on the list of all the other grudges. All right, it's just a way of, arrays are hard, [LAUGH] right? You have to get all the stuff that's not in there, right?
[00:04:52] I feel really strongly about objects, but that's a whole bunch of extra boilerplate. So we'll stick with arrays, even if we're kinda staring at the code makes you wanna cry a little bit. Finally, all right, so that's all the state management of this application component. What does it mean when we actually wanna show it on the page?
[00:05:09] So we'll pull out all those grudges out of the state. We have our unavengedgrudges and our avengedgrudges. And we have this too. We have new grudge form, which is just basically a name, and the thing that they did that wronged you and a button to add them to the list.
[00:05:26] We have the list of unavengedgrudges and avengedgrudges, and the ability to basically toggle and manage that state. Then finally, we export that application. I'm not gonna go through the rest of the components cuz we won't be touching them. But it's basically the rest of the infrastructure to get out of our way.
[00:05:45] For the most part, when we modify this application, we're not gonna be changing too much of its functionality. We're just gonna be changing the way that it manages the state. Cuz right now, it manages all that state in memory. Again, the second you refresh the page, you're dumping out all of that memory.
[00:05:59] What we would like to do is we would like to go ahead and actually persist that to a database. Now it's a little bit easier said than done, right? You don't wanna have a global database that everyone's, like maybe you wanna have a global grudge that's that's anonymous.
[00:06:16] Anonymous people on the internet are the best, probably not exactly what you want. So we need to implement some amount of authentication so a user can log in. And then we need to figure out what data belongs to each user. Like when a user logs in, they should only see their data.
[00:06:31] Then we wanna persist that data on the server. All right, now, currently there is no server. And that's again, a part of what this workshop is about is how do we spin up, again, a very scalable, very robust back end very quickly, and kind of focusing on the parts that make our apps special.
[00:06:48] Cuz I'm gonna be really honest, this is a very special application. It has a lot of value that it can bring to the world. And it's best that I get this in the hands of customers and not me spending my entire weekend doing stuff like authentication. I'm not interested in that.
[00:07:02] I don't want to do that. I'm not going to do that. So we have this application. And our goal is going to be to kind of get that back end into place, get the API in place, get the authentication in place. Very cool.