In the last video we implemented these two callbacks of on sign in and on sign out we made sure that
we called both those anytime the user clicked on either the sign out button or the sign in button right
here.
Now at the end of the last video I was looking at both these callback methods we just put together and
I realized that the naming of them is really unclear.
They're named on sign in and on sign out.
I don't know about you but when I see the term on seinen it makes me think that the user just successfully
signed in.
But that is not the intent of this cold act function right here on CNN is supposed to be called when
the user is attempting to first sign it.
And so in order to make that a little bit more clear I think that we should probably change the name
of both these event handlers.
So I don't change on SIGN INTO on sign in click and on sign out to on sign out.
Click.
So the idea here is that this name is a little bit more descriptive.
This is a function that is going to be called when the sign in button is clicked.
There is no functional change here.
Again it's just to communicate the functionality to other engineers who might work on our project.
Now since we updated these event handler names we need to make sure that we update the references down
in both the buttons as well.
So I'm going to change this to on sign out click and on sign in.
Click Like so OK.
So now in this video we're going to continue by talking about how this component our Google component
is going to play around with redux because we have not yet integrated redux into our application so
I'm going to show you two different possible ways in which we might integrate this Google authentication
with redux.
All right.
So here's the first way.
The first way that I'm showing you right here is essentially going to leave our Google off component
for the most part untouched.
Now this way that I'm showing you right here is not closely following the conventions of redux.
So I would say that if we wanted to 100 percent follow redux conventions this might not be the best
approach.
The reason we're going to take this approach right here is that at the end of this project you're going
to end up with a single component.
This Google component that shows you the entire process with Google from start to finish and that's
what I really want you to have.
I want you to have a component that shows you from start to finish how to set up Google off.
So even though this is not super optimal it's still going to leave you with a single reference for hey
here's how.
Here is how it works.
OK.
So let's walk to this flow and I'll show you an alternate flow that more closely follows redux conventions.
All right.
So inside of our component we've got on signing click and on sign out click whenever we call those We're
going to essentially be accessing the off to instance and that's going to start either the sign in flow
or the sign outflow.
Either way this library is going to eventually call our on of change inside of our class or inside of
our Google Earth component in order to integrate redux into this flow.
We're going to make sure that any time that on off change is called we call some appropriate action
creator.
So either an action creator called something like sign in or something called Sign out.
Now these two action creators right here are going to be called any time that the user successfully
signs in or successfully signs out.
So remember just a moment ago I had said oh yeah the name on sign in or on sign out was kind of unclear
because it wasn't clear if that was the user completing the sign in process or starting the sign in
process.
So these action creators their intent is to be called once the user has successfully signed in or successfully
signed out.
So when we call this action creators they will return in action.
That's going to show up inside of a new reducer that's going to be called something like our reducer.
This author reducers probably going to be an object or something like that that is going to hold a simple
boolean value that reflects whether or not the user is currently signed in or signed out.
Now you might be kind of curious why are we going to reflect whether the user is signed in or signed
out inside of a redux store.
Because we are already recording that inside of our Google off component.
Well the reason for this is simple.
Right now only our Google component knows whether the user is signed in or signed out.
That is really inconvenient for a lot of things that we want to eventually do inside of application.
Eventually we are going to have entire screens and different components that are going to function very
differently depending upon whether the user is signed in or signed out.
And so we need to make sure that we have the facts of whether the user is signed in or signed out in
some very centrally accessible location inside of our app.
Having that inside this component is not centrally accessible.
It would be very challenging for other components to somehow reach into this component and figure out
if that user is signed in or signed out.
So rather than leaving the state of whether the user is signed in or signed out inside this component
alone we're going to instead move that to our retail store.
So the redux store is going to have a boolean flag inside of it either true or false or no.
If we don't know if the user is signed in at any given time that's going to reflect whether that user
is signed in or signed out.
This is going to lead to some kind of weird things.
However I want you to know that right now we don't want to reflect whether the user is signed in in
multiple locations.
We really want to reflect whether they are signed in or signed out and only one spot inside of our app.
And so we're going to make that the redux store but then the side effect of that is that our Google
off component needs to know whether to show the sign or the sign out button.
And it only knows which one to show depending upon whether or not the user is signed in or signed out.
So we're going to make sure that the redux store communicates whether the user is signed in or signed
out as a prop Drew that map stage props function down to google off.
So the reason that I say that that this is kind of awkward is that right now this component has component
level state that says whether or not the user is signed in.
And so I'm now telling you that essentially we're going to take this little piece right here or this
little piece of state that says whether or not the user is signed in and move it into the reducer and
then go through a ton of like you know all the map state to props all the connect function all that
nasty stuff just to get this simple boolean or no value back into the component.
And so that's what I find is kind of awkward.
We're going to remove some piece of data that is already into the component into some other location
that is way harder to get access to just to get it back inside the component anyways.
Now again the reason that we are doing this is to make sure that other components can very easily read
this data as well.
Nonetheless it will feel a little bit awkward when it comes back to refactoring the Google off component.
OK.
So that's kind of my spiel around how we're going to do some of the redux design around this component.
Now I want to show you an alternate way of designing our story here in designing the red oxide the application.
Now this other way I'm going to show you like I said is following redux conventions a little bit more
closely but it's also going to spread a lot of our authentication logic out all over our application.
And so if you want to reference this Google stuff in the future it would be a lot harder to figure out
the entire flow if you use this other approach like so
OK.
So in this approach the general idea is that we want to have our action creators always responsible
for changing the state of our application at present with this flow.
We are Google off composed right here is responsible for changing the state of our app.
Like truthfully it really is because this component is accessing the API to object right here.
And this object right here kind of is a part of state of our application.
So it's not really best practice to have a component manage state like that.
But again we're going to take that approach instead it would be a little bit better approach to have
our action creators manage access to that API object instead.
So in this approach we would still have a Google off component and it would still have some callback
functions like on sign and click or on sign click.
Anytime someone invokes one of those callback functions we would call inappropriate action creator something
named like try sign in or try sign out.
Now the reason I named these Try sign in and try sign out is to make sure that it's clear that these
are going to attempt to sign the user in or attempt to sign the user out.
Is the start or the beginning of the authentication process.
So these action creators would essentially called this API auth to object right here.
And then once the user is either signed in or signed out successfully the API object is still going
to call some callback function called something like change off.
And this would also be an action creator.
Change Auth. right here would be essentially equivalent to our current onchange auth function right
here.
So any time that the user successfully signs in or signs out change Auth. would be called that would
dispatch an action that would update our piece of state and then just before as in the last diagram
our redux store would communicate whether or not the user is signed in or signed out through Mount St.
to prop's down to our Google off component okay.
Like I said this is a alternate approach that would follow conventions of redux a little bit more closely
because it is blocking access to the API object right here behind our action creators at the end of
the day it's really not a big difference at all.
I just wanted you to be aware that we could have taken this alternate approach and probably done just
as well as what we're doing.
OK.
So now that we understand the general idea here let's take a quick pause.
When we come back the next video we're going to start wiring redux up to our project and implementing
these action creators and some 3DO as well.
So quick break and I'll see you in just a minute.