Original subtitles

OK, guys, so now that we have our Google Sinon, we have to actually figure out how to store this

authenticated user into our database, because right now the authenticated user that we're getting back

from our off library is not actually something in our database.

So when we actually sign in with our Google sign in.

What we get back is this user authentication object that has a lot of properties on it that we don't

actually want.

So there are so many properties on this because a lot of these are related to things that you might

want to do with a Google auth object from Google's own API.

So this is supposed to integrate with many of their other services or what they offer in their Google

Sinon to other platforms, other libraries.

It's all unrelated to what we need in our application.

In fact, the only things that we really need in our application is this display name, this email.

And possibly, maybe a phone number, right, but the most important thing is this Eweida this UUID

represents the dynamically generated I.D. string that Google made for us when we authenticated this

user using the Google sign it.

In fact, if we go into our authentication and we look at our user inside of our off tab, whenever

a user signs in to our application using the off library that we have.

Regardless of if it's email, Sinon or Google sign in, we will get this user right and this user has

this UUID.

We have to take this user off object.

Figure out the properties that we want from it and put it into our database.

Particularly, what we want to do is put it into our users collection.

Now we're going to write some code that will allow us to do this, as well as understanding what the

Firestorm Library actually does for us, because there's actually certain rules or certain things that

we have to abide by in order to use and update the fire store database.

And I'll explain them as we write out this function.

So the function that we're trying to write is going to be one that allows us to take that user off object

that we got back from our authentication library and then store inside of our database.

So what we're going to call it is this function called create user profile document.

Right.

And this is going to be an asynchronous thing because we're making an API request.

Right.

That's an asynchronous action.

So we're going to call async.

And what we're going to pass into it is, of course, our user object, right, that we get back from

the library, that's that same object that we were logging right here.

We're going to pass that in.

And then we're also going to pass in possibly any additional data that we might need, so this could

be something that we're going to use later when we do our sign up.

But for now, we're just going to say we also might want some additional data that will come in in the

format of an object.

And I'll show you what we'll do with this additional data.

Now.

As we saw, when our user signs out, we actually get back nul from this library, right?

If I were to sign out right now, we'll see that we log nul.

So we only want to perform this save to our database if we get back a user off object, which means

that they signed in, not that they signed out.

So our function has to make sure that we're checking if we're actually getting back a valid object.

So inside of our code, what we're going to do is we're going to say if there is no user off, right.

Because this will evaluate null.

Right.

And if it's null, then it's false.

And with the bang, we're going to say we want to reverse it.

So if it's not false.

Right.

So I know that context is confusing, but this is essentially a saying if the user auth object does

not exist, then we want to return from this function.

We don't want to do anything else.

We want to exit from this function.

If it does exist, though, what we're going to do is we are going to query inside a fire store for

the document to see if it already exists.

Now, in order for us to do this, we have to understand what it is that we're going to get back.

Now, inside of here, I have a actual slide for us to understand, the Firestorm Library gives us back

one of two different types of potential objects.

We either get back a query reference or a query snapshot.

They're both different objects that do different things in firestorm.

But let's talk about what a query is first.

A query is simply us asking Firestar for some document or collection.

If you remember from the last lesson where we talked about Firestorm, we called dot, dot or dot collection

and then passed that string to the location inside of the database.

Right.

For either collection or a document, that act of asking is what a query is.

And what we'll get back when we query is a query reference, and it can either come in the format of

a document or a collection if we're praying for a document or collection, respectively.

A firestorm will always return us these objects, whether it be the reference or the snapshot, which

we'll talk about later, Firestorm will give us the object because using the object, we can determine

whether or not there's any data there.

Now, the reference is simply a object that represents that current place in the database that we're

asking for.

So let's actually try it out.

And we can call it either using DOT Doc passing in the collections this way.

Right.

Or DOT collections and passing in the path to that collection.

We explore that earlier in a previous lesson, but let's try it out.

What we're going to do here is we are simply going to console log the firestorm and then calling for

the dock users and then a random user I.D., one that we definitely know doesn't exist.

Right, because our collection is empty anyways.

If we were to save this and pass this into our apgar's right, we import it in and we use it whenever

we get back and off object.

We know that this will be a asynchronous because we're going to, of course, make a potential API request

right, to our fire store.

And then what we'll do is instead of setting the stage here.

We are going to console oh, wait, sorry, we're just going to fire this using our user off object

that we know that we're getting back from our off library.

If we were to save, we go back to our application, we see that we're getting back this document reference

object.

We also see that the random I.D. that we pass to it is here.

We see that we get the path that we also passed in, right, so we know where the current location of

this document reference is.

But we are always getting back this object, even though it doesn't exist inside of a database.

So why is that?

Well, the reason is because we actually use this reference object to tell Firestar whether to save

data to this place inside of our database or to get data from this location in the database.

It does not have the actual data related to the document.

Instead, it gives us properties that tells details about it, like the I.D. and the path to this specific

query reference, as we already saw.

But what we're also able to see if this is a query reference, right.

Meaning it's a document reference, is that the parent is a collection reference representing the collection

that this document is in.

So here we'll see in this collection reference that we have our idea of users and the path is just users.

Now, the difference between the document reference and the collection reference is that the document

reference object we used to perform are crude methods on our Firestar crud being either creating, retrieving,

updating or deleting the data in that place, that location.

Now, when we actually retrieve the data, right, we're calling DOT get right and don't get is us pulling

out a snapshot object of that place in the database.

And that snapshot object was that second type of object that I was telling you that faster could give

us back, we'll actually use it and we'll be able to use that snapshot object in order for us to determine

with our code whether or not there's any data in this current reference in our fire store.

So I'll show you what that is as well.

But again, the snapshot object we get back from calling doGet, right?

So we either call document refought get.

Or we call collection rough, like a collection ref also gives us back a snapshot of the collection,

but it's different from what we're going to use in our current code.

But it's just good to know that this is something that you might possibly have to do.

And of course, from the document, we're going to get a document snapshot.

So let's actually take a look at that.

So back in our code, what we're going to do here is we are going to move this into a contest of some

kind.

Right.

So consed user ref equals fast or dot doc getting that user.

And then I'm going to hear say, how do we get the snapshot.

Well it's going to be snapshot equals user raef.

Right.

So we have our user reference dot get.

Now, this is an async, right, so we're going to await this.

And then we're just going to log the snapshot, so we take a look at what it is that we're getting now,

we see that this is our document snapshot object.

And on it is this property exists.

The exists property tells us whether or not there's any data there.

The I.D. tells us, of course, the idea of the same document.

Metadata gives us certain information about things like when it was created, right, whether or not

it's cached at whether or not there's pending rights, meaning if there's anything that needs to be

updated right to the snapshot, don't worry about this for now, but just know that this is something

that you might want to use if you get really, really deep with Firestorm.

And then, of course, we can also always reference back to the document reference object that we queried

our snapshot from.

Now, instead of using this fake one, what we want to use is the user off UID right, because we now

want to see whether or not the user off object that we get back from authentication library actually

already exists in our database.

So here we're able to say instead of using an actual string, what you string interpolation, I will

say users at our user off dot uid.

We will get back the user reference at that location and then we'll get a snapshot and using that snapshot,

we're going to figure out whether or not there is data there, right.

Whether or not we've already stored this user object that we've authenticated.

And here we'll see that the existence is false, of course, right?

But the idea is now that it that we were getting back from our awful library.

So what we're going to say is we're going to check inside of our code, right, using that snapshot.

Exists property.

So if it doesn't exist, we want to actually create a piece of data there and we're going to create

it using, argues Şeref, because if you remember from our slide, in order for us to create, we have

to use the document reference object, not the snapshot.

The snapshot simply represents the data.

Any methods of creating, getting, updating or deleting that data.

We have to use the document reference object for.

So here, what we're going to do before we create it is we need to see what properties we actually want

to store, right.

What are the data that we want to use in order to create this actual document?

So what we want is the display name.

And the email from our user off, right, as we remember from that giant object that we first logged,

we want the display name.

We want the email.

And we also want to make sure that we know inside of our database when we made that document.

So by calling New Date, we're creating a new JavaScript data object that tells us the current date

at the current time when this was invoked.

And what we're going to do is we're going to wrap this inside of a try catch block.

Because what we're going to do is an asynchronous request to our database to actually store this data

now.

So what we're going to do is we're going to await our user ref calling dot set.

Dots, that being the create method, and we're going to make an object, right, we're going to pass

on an object where we have the display name, we have the email, we have the created up, and we're

also spreading in any other additional data that we might want.

So as you remember I mentioned earlier, we're going to pass this additional data into this function

as an object.

If this has any issues, we're going to console log error, creating user right and when they're work

to log out the error message as well.

And if this snapshot doesn't exist now will create data in that place.

That's all this code is doing.

We're checking if there's any data in that place.

If there isn't, create a new user using the data from our user auth object.

Now, what this function will also do is always return us back our user ref.

Because there's a chance that we want to use this user reference, object to do other things, write

this code simply creates the snapshot, it creates the data, but we might still want to use a reference

in our code for something.

So that's why we're going to return it from this user.

And now when we call to create user profile document.

Right, our opinion realized, you see, we didn't log, so we probably created something in our database

and we check there is our user in our database.

Our current user is now being stored, and if we refresh, as we know, are functional for every time

because of is always persisting.

Despite that, we've only still got the one user, we're not making multiple copies because our code,

again, checks if the snapshot at this place exists or not.

So that's what our code is doing.

We're checking and now we're making these new users inside of our database based on that user off object.

And now that we have these objects being stored in our database and being pulled into our application,

let's actually figure out how to store this data so that we can use it in our application.