All language subtitles for 008 Google Sign In Authentication 2_en

Now that we have our sign in with Google Button, we actually have no way of knowing inside of our application

whether or not our sign was successful with Google, but we can tell that our user was added to our

firebase and authenticated when we go back to our firebase console in our authentication, if we click,

this user's tab will see this list of users.

And right there, that user is the one that we just logged in with, with our sign and with Google.

So we know that it's working and we're getting authenticated.

Now, how do we actually add this into our application so that our application is aware that those changes

are happening while Firebase gives us a really easy way to do that?

So let's go back to our application and let's go to our app, Abcess.

Inside of our abcess, what we want to do.

Is we want to first import in off from our firebase utils.

So let's import off.

Firebase Dasch, Firebase Utils, and what we want to write is we want to actually store the state of

our user in our app, right.

So when a user logs in using whatever service we use, whether it's Google Sinon or email and password,

we want to store that on the App State so that we can pass it into components that need it because we

want to access our current user object throughout our application.

So what we'll do is we'll convert our app over to a class component so we can have access to state.

And we'll put this return inside of our render.

And now everything will work the same.

We'll just add our constructor, call our super and call this Staats state equals an object where current

user is null.

To properly understand what Firebase Auth gives us, we have to understand the concept of a subscription.

So normally how we fetch data before is we inside of our component did mount.

Method component did mount.

We're used to firing a fair shot to the back end to fetch data, but this is only a one off thing.

Once the code calls fetch, it won't come back again until a component did Mount Life-cycle method gets

called again.

But we don't want to remount our app.

We just want to always know when Firebase has realized that the authentication state has changed.

So whenever somebody signs in, whenever somebody signs out, we want to be aware of that change without

having to manually fetch.

Firebase actually gives us that really easily.

So when we call off on off state changed.

This is a method on the off library that we get from Firebase, right, Firebase off and then this off.

Inside, what it takes is a function where the parameter is what the user state is of the off on our

firebase project and our callback inside, we're going to call this dot set state where we're setting

current user to that user object.

So let's log it out as well just to see what it looks like.

Now, when we go back to our application and we open up our consul.

We actually see that this is our user, the one that we just signed in with with Google, so because

our application earlier when we selected signed with Google, it's already stored that user and it knows

that this application that's making that request has not yet signed out.

So that's why we're still seeing the object, even though our app refreshed when we saved our app just

now, Firebase is still aware that this was the last user.

Right.

That got signed in with and this is a really cool feature that we get from Firebase right out the box.

User authenticated session persistance.

This is actually a setting that you can change in Firebase, which we will definitely explore in a later

lesson.

But right now, I want to focus on the basics of Firebase because there's so much for us just to understand

what Firebase can do for us.

But this feature is awesome because if you think about it, we don't actually want our user to have

to resign in whatever we either refresh our page.

Where we see we're still getting now our user or if we close the window, right, without ever signing

out and then come back to our application.

And again, we get that user object from Firebase, which is great for us, because then we can decide

what to do with it, right?

Because we know that our user is still the same and firebases aware because it keeps track of all the

instances of the application that are open and communicating with it.

So it knows that, OK, a user came from this instance of the application before and they never signed

out.

So I'm just going to assume that they're still signed in.

And because of our subscriber here, our subscription is always listening to the OTH, the authors like,

oh, I'm going to send them that user authenticated object every time until they sign out.

So this is a really great feature because this is essentially how we're able to get persistence of our

user sessions without having to set up all this complicated stuff that it would normally require for

us to get this.

But let's look back at the actual user authenticated object that we're getting back from Firebase.

And on this, we just want to ignore a lot of these values because we don't need them, because it's

a Google user object.

It has a lot of stuff.

But the main one we want to look at is display name and email.

So we know this is that user that we just got.

And the great thing about this is that now we have off so easily right out the gate off essentially

allows users to sign in with any other third party service that they might already have.

And by doing this, we've reduced the barrier of entry for allowing users to sign into our application

because they don't have to actually go through an arduous sign-up process or remember their email and

password for our app.

They can just use sign with Google a lot.

Sinon is actually a very tedious and difficult thing to set up from scratch, but by using Firebase,

we got access to it with just a couple configurations and that's why Firebase is such an incredible

platform.

Now, the next thing we have to do is actually understand why this is an open subscription.

So this open subscription, it's an open messaging system between our application and our firebase app.

Whenever any changes occur on Firebase from any source related to this application, Firebase sends

out a message that says that the off status change the user has updated, whether they've signed in

through some service, such as our Google Sinon or our email and password sign up.

Or they've signed out and then they will give us this user and it will call it so we don't actually

have to manually fetch every time we want to check if that state has changed.

This connection is always open as long as our application component is mounted on our job.

But because it's an open subscription, we also have to close subscriptions when this unmount because

we don't want any memory leaks in our JavaScript application.

So how we do that is we would call a new method called unsubscribe.

From off, which by default is equal to none.

So we're setting up property called unsubscribe from off on our class.

And then we're going to say this equals off.

On off state changed, which gives us back a function that when we call closes the script subscription.

Right.

And we want to close it whenever our component on mounts.

So in this new Life-cycle method, a component will unmount.

We want to call this unsubscribe.

From off, and that will close the subscription.

And this is pretty much how we handle our application, being aware of any off changes on Firebase.

I know it's very conceptual and if you understand, that's awesome.

If you don't, that's perfectly fine.

It will make sense the more you do it.