Instructor: So it took a lot of code,
one tremendous hunk of code, a huge pile of code,
to put together client-side authentication.
But, man, we sure did it.
The biggest kind of heavy lifting
that we did inside the entire application
was definitely inside
of our action creators file, I would say.
The action creators signinUser and signupUser
were both real big hefty action creators here.
Not only did they have
kind of branching logic inside of them,
but they also took several distinct actions
after a user was signed in or authenticated in some fashion.
One thing that I wanna point out in particular,
is that because we were storing our token on localStorage,
our user is always going to be considered to be logged in
until they forcibly sign out.
And once they sign out,
that's when we actually take care of that token right here.
Besides the use of these
really kind of heavy action creators,
the other big hefty things that we did
inside this application
was validation inside of the signup component.
So remember, inside the signup component,
we used Redux form to put together some validation
of the different fields inside of our form.
This very particular validate function right here,
we wrote in a pretty imperative approach right here,
really went kind of long form
on all the different validation options.
As we said earlier,
I could definitely imagine
refactoring this validate code in here
just to make it a little bit more condensed and clear
to other people who are coming along in the future.
Just to make, you know, a little bit more reusable.
I suspect we could probably reduce this validate function
to far fewer lines of code
while still validating basically the same stuff.
The other really fun thing here
was the higher-order component that we put together,
RequireAuth.
So this was a higher-order component
that we put together in a previous section,
and the only update that we had to do it
was to update the piece of state that it was looking at.
After we did that, we were able to make use of it
directly inside of our router.
Inside of the router,
we said, for a very particular component,
in this case, Feature, before showing Feature,
make sure that the user is actually authenticated.
And so this was a use of higher-order components
at kind of used time or required time,
as opposed to always exporting
a RequireAuth version of Feature.
What I mean by that is,
we could have just as easily imported
our higher-order component into this file instead,
and then added our higher-order component
right here on top of Feature.
Instead, we ended up
with this very clean version of Feature
that really anyone could access,
and only once we started to use it at the router,
did we define that, "Hey, this thing needs to be secured
by authentication."
We took this approach because it makes it very easy
for other developers in the future
to come view your routes file, or your kind of router here,
and see with very plain, very visible,
"Oh, okay, the Feature is intended to be
kind of hidden behind this wall of authentication."
So it's just something that helps communicate the intent
or architecture of your code a little bit more.
So in closing, this is client-side authentication.
I hope you enjoyed this section.
It definitely was a hefty amount of work to put together.
I know that we did a tremendous amount of coding in here.
Definitely went a little light
on some explanations at some places,
but that was definitely with the purpose
of getting through the content
in some reasonable amount of time.
I hope you've learned a lot.
It was certainly a lot of fun to put together,
and I hope to see you again soon.