Now that we can register users and log them in and out, it would behoove us to wire that functionality up on our front-end, so we can stop using Postman to do it. This is an activity both straightforward and startlingly complex. We’re going to introduce some new technologies here, and they’re going to be confusing. My intention is to go pretty granular here, in the hopes of really explaining what’s going on.
Here are the steps needed to get this working:
- User fills in form and clicks log in button (or hits enter)
- Tell app state an event is occurring
- Form validation, front-end
- Form validation, back-end
- Log the user in
- Update the app state with the user info
- Tell app state an event has finished occurring
Numbers 2 and 7 are important because we’re going to use them to control an Ajax spinner, so that people know something is happening and don’t assume your application is doing nothing. Now, the truth is this login should happen so fast, most of the time, that the spinner may not even flicker onto the screen … but you never know when someone might hit an internet hiccup that slows things down for a second or two. All of the actions your application takes should fire off a spinner (with a few exceptions), and then disable it when the action has completed.
We’re going to use a very, very popular solution to handling state in React applications called Redux. Created by a guy named Dan Abramov, Redux is often mentioned in the same breath as React, as if you can’t use one without using the other. This is false. There are any number of ways to manage state in React, including rolling your own. There are, in fact, some very good arguments against using Redux, especially if you’re a beginner.
Redux, however, enjoys widespread support in the community, which means there are lots of modules that work well with it. It’s also very straightforward … once you wrap your head around it. At first, it feels very alien, or at least it did to me when I started working with it.
Hold up, kids, I’m about to hit you with a diagram. Here’s a really basic, incomplete diagram of how Redux works.
You start with your application. When an event happens, let’s say a click, your Action Handler for that event (which would be a function you write yourself and embed using an onClick in your JSX code) dispatches what Redux calls an “action” … the thing with actions is that they’re not functional. They are an object that contains information. Redux reads this information and, if your action matches its list of actions it’s watching for (more on this later), updates the Store accordingly. The Store is, as we’ve discussed, React’s name for the state of your application.
That’s all Redux does. Once it changes the Store, Redux is done and React takes over. React, which is tied into the Store, automatically re-renders parts of your app to account for the change in state. At this point, the user sees the change, and the cycle is done.
That’s already sort of complicated, and as we’ll come to find out, it gets even moreso, but hey … that’s what these tutorials are for. So let’s start by installing Redux, which is straightforward. Head for a command prompt or terminal, and type the following:
yarn add email@example.com firstname.lastname@example.org email@example.com
Let that run, and you’re good to go. Redux is, well, Redux. React-Redux contains some bindings we’ll need to make things work. And we’re adding in some Redux-Devtools there because they’ll come in handy later, when we start to break things!
We could get into “thunks” here and how a module called Redux-Thunk helps with asynchronous functions, but we don’t need it right now, and may not need it at all for an application with this level of complexity, so we’re going to skip it. You may also have heard of “Sagas” … they’re a pretty awesome solution to lining up and firing off whole bunches of Redux actions. We don’t need ‘em, and aren’t going to cover ‘em. Both are examples of ways to DRY large-scale React apps, and if you’re writing the next great Mint replacement (and please do, because Mint sucks), you should look into them. This app’s just not that complicated.
We’re going to leave off here. I know we didn’t do much in this tutorial, and it’s not very long, but sometimes it’s important to just talk things through before really jumping in. In the next tutorial, we’re going to wire up our app store and, if we have time, create our first action. Stay tuned!