All language subtitles for 106 Storing User Data In Our App.en_US

Now, inside of our jails, we're calling that new create user profile document function that we just

made.

What we want to do is we want to make sure that we also.

Call our set state with current user, with the actual object itself.

So what we'll do here is we will modify our code to make sure that we understand what's actually happening.

So first, let's change the user to user off, because now we know what we're getting back is a user

off and we'll say if the user off object is not null, meaning if it exists, right.

We remember that user could be no more signing up and we don't want to set anything here.

Right.

If it's if we're signing up.

We remember what we get back from our function.

Is the user ref, we made sure that we were passing back the user riff raff object, right?

Right here at the end.

We want it because we're going to use it to check if our database has updated at that reference with

any new data.

Very similar to our on off state change, we're kind of seeing if the snapshot has changed.

But chances are it won't have because we are not going to update the user ever inside of our code,

but the process of what this method will do, which I'll show you in a second, is that the moment it

instantiates, meaning that the moment our code runs it, it will still send us a snapshot object representing

the data that is currently stored in our database.

And that method is on snapshot.

Calling on snapshot is very similar to calling on Off-stage changed.

And what we get back is the snapshot object and on the snapshot object is where we're going to get the

data related to this user that we just possibly stored.

Right.

If it was a new authentication or the data related to the user that is already stored in our database.

Let's talk about these snapshot objects.

A document snapshot object is one that, of course, we get from our document reference object, right,

using the doGet method, as we saw.

It allows us to check if the document exists, as we know, but it also allows us to get properties

of that data using the DOT data method.

We actually do not get any data until we use the data method, so I'll show you.

If right now I simply can't so log my snapshot.

Here we get our snapshot.

You see that it has the exists, it has the it, but it doesn't have any of the properties we have to

call data in order to actually see what our data looks like.

And it'll come back to us as an object with those properties inside of our database.

Right.

So the display name email, the created out, of course, are the properties that we use to store in

here.

So this is the main thing that we need to use, but we see that we don't have the ID now if you remember

on the snapshot itself was the idea of where we currently are in our user rough.

Right, as well as the ID that represents the data of our snapshot right here.

So we need to use these two things combined and call our set state of our current user right here.

And what we're going to do is we're just going to call set stay here, passing in an object.

With our current user value.

Going to the idea of our snapshot.

EDD.

And then we're going to spread in snapshot data, right, because we get back the object representing

the values, so we're just creating a new object that has both all of the properties of our snapshot

that we want, as well as the idea that we want.

And then just to make sure we're getting everything right, let's just console log this dot state,

right, just to make sure that we're getting this through.

Now, outside of this function.

Outside of this function call where we're checking whether or not the user off exists.

We also want to make sure that our app is aware if the user auth is null, meaning if the user signs

out, we still want to set current user to nothing as well.

So if the user off object comes back and it's null, then what we want to do after this is called this

dot set state.

Where current user goes to our user off, which we know is not right, so this is equivalent to saying

current user to know.

So now what will happen is if a user signs in, right, we'll check if they're actually signing in because

we'll see if there's a user off.

So if there is, we will get back the user ref from our create user profile document method from the

user auth object being passed in.

If there was a document there, we will simply just get back to user.

If if there is no document there, we will create a new object and document right in that place and

we'll still get back the user f and then we're going to subscribe.

Meaning we're going to listen to this user ref for any changes to that data, but will also get back

the first state of that data.

So then using that, we are going to set the state of our local abcess with the snapshot ID and the

snapshots data, and then if the user ever logs out, we'll make sure to set the current user to know.

Right, setting it to the null that will get back from the library.

And now that we have all of this, let's actually see what happens.

We made a mistake with our console log.

So if you remember, our console log can't go after substate state because set state is a synchronous

meaning that there's a chance that when we call it sets, it is not actually finished being called.

The only way for us to make sure that set state is fully called.

And then we're able to see what the state of it is, is.

We pass a second function, right, as a parameter in such state as the second parameter.

Where we do the actual logging and sets that will then call our function after a state as fully propagated.

So now we see that we're actually storing our current user.

And this is actually all of the data that we got from our database as well as the created that sign

and the ID.

So hopefully this was not too overwhelming.

I know that this is a lot of new code that we just covered.

And it's definitely a lot of code that we haven't seen before, all related to the fire store, fire

base library.

We've also mixed and matched the off and the fire story library code together to create these new objects

inside of our database and then bring them back in and then store them.

There's a lot of back and forth.

I know it's a lot of confusing code, but also a confusing flow.

But I promise you, the more you practice with both these Raef objects and the snapshot objects, the

better you'll understand the purpose of what each is for.

And this is actually pretty much the core of how we use the Firestone Library.

It's actually really simple once you've mastered and understood these concepts that we've just covered.

Now, let's get rid of this, because we don't need this anymore, and we'll work on our sign up next.

Right, which is more with our auth library.

But now that we've done this flow inside of our APGAR'S, if we add our sign up with email and password

write, this code is all still going to work the exact same because we've compartmentalized our actual

storage and our actual sextape separately from our authentication.

And that'll make more sense once we actually start writing the sign up, but definitely rewash these

last few videos.

If you feel confused about Firebase, it's incredibly powerful and it does have a bit of a learning

curve to get used to how to use it.

But it's very valuable because this is actually way, way easier than any other way of spinning up our

own backend server and authentication service.

So let's tackle sign up next.