Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
So far we've done a lot to get the user authenticated.
There are still some issues we'll need to address before we can move onto the login form.
One of those issues is connecting the user with their data.
In Firebase, we're storing the user's information in two separate services, the authentication and
the store service.
At the moment, we don't have a way to connect the two.
We don't know which document belongs to which user.
In the authentication service, there is one common value between the two services.
That would be the email.
I don't recommend using the email to keep track of the user.
It's because emails can change.
If the email changes, we'll have to change the email in the list of users and the database.
We want something that will be consistent once the user has registered.
Luckily, there is a value we can use.
Navigate to the authenticated section in the Firebase console.
Every user is assigned a user uid this value is unique.
It will never change.
We will want to store this value in the database to know which piece of data belongs to which user in
our Firebase sample location.
Likewise via store will assign a unique ID to each document.
Navigate to the database in the Firebase console.
Select the users collection.
If it hasn't been auto selected already in the middle column, we'll find a list of random strings.
These are unique IDs assigned to each document.
The ID is automatically generated for us.
We'll want to change this.
Instead of using a randomly generated ID, we're going to use the ID assigned to the user in the authentication
service.
Before we get started, I want to make one point clear.
This issue is a firebase related issue.
It is not a view issue.
Storing the user in the database and keeping track of their data is something a back end developer has
to worry about as frontend developers.
Our responsibility is to send the data to the correct endpoint and storing the token we receive from
the back end.
The token permits us to interact with the database.
Other than that, everything else is back end related.
However, with that being said, I still want to show you how to accomplish this task with Firebase.
Some of you may want to use it as your back end solution.
That's fine.
Even if you decide to use a different backend, the process on the front end is still the same.
All right, let's get started.
We'll start by modifying the request to the database.
We made that request inside the store file.
We'll scroll to the register.
Action.
There are two steps we'll need to make.
Firstly, we'll need to retrieve the ID generated by the authentication service.
Secondly, we'll update the request to store the user's ID in the resource section of this lecture,
I provide a link to the function we used for creating the user.
The documentation will help us with finding the information we need.
We already know that the function returns the user's credentials.
If we scroll down, we'll come across a section of what will be returned.
It's an object called user credential.
Let's click on the link to find out more about the returned object.
It'll tell us that the object user credential will have four properties.
The one we care about is the user property.
We'll click on the link again for more information.
This page is where we'll find the information we'll need.
The user object comes with properties for reading and interacting with the user in the service.
Under the list of properties, the one will need is called UUID.
If we click on it, it'll tell us the following.
The user's unique ID.
This property is exactly what we're looking for.
To be clear, this is the ID assigned to the user in the authentication service.
We're going to save this ID in the database.
Let's switch back to the editor.
We'll be working in the register action for the first request.
We're going to assign the functions return value to a variable.
The variable will be called user credentials.
We're finished with step one.
The second step is to update the request to the database to use the ID.
Firebase has two functions for inserting the data into the collection we're using.
The first one.
The ADD function will insert a document into a collection with the generated ID.
It doesn't allow you to generate an ID or self.
If you'd like to use a custom ID then you'll need to use the other function.
The second function is called set.
We aren't able to use the set function because it's not available through the collection.
If we'd like to use the set function, we'll need to select a document.
First, let's look at what the code looks like and then I'll explain in the second request before we
call the ADD function chain a function called document.
The document function allows you to select a document in a collection.
However, the document does not exist because we're trying to edit to the database.
That's perfectly fine.
The document function will create the document if it doesn't exist.
This function gives us the opportunity to assign an ID to the document.
It has one argument which is the name of the ID we'll pass in the following user credentials.
Dot user dot uid.
Firebase will store the document with the ID we passed in.
The ID is not the only thing we'll want to change.
The document function returns the document.
The object does not come with a function called AD and said we need to change this to set.
The set function will add or modify existing properties in a document.
The argument is an object of changes we'd like to make.
We don't need to make any changes to the object being passed in.
This will still work.
Before we test things, I want to perform one more task.
I haven't been completely honest.
The authentication service can store additional information about the user, but it's limited.
Every user registered comes with a pro file.
There are two things you can store in the profile a display name and a profile image.
We'll store the display name in the service, for example purposes.
After storing the user in the collection, we'll call a function called user credentials.
Dot User dot update profile.
It has one argument.
It's an object of properties.
We'd like to update on the profile.
There are two properties we can update on the profile, the display name and profile image.
We won't have a profile image, so we'll set the display name property.
This task is asynchronous.
We'll add the await keyword before it to wait for the response.
Let's give things a test.
On my end, I'll receive a success message.
If I were to inspect the console, I wouldn't find any errors.
Fantastic.
Let's verify things in Firebase.
Navigate to the authenticated section.
In the authenticated section, we'll find the newly created user take note of the ID assigned to the
user.
It should match the ID assigned to the document in the database.
Let's switch over to the database to check if that's true.
Plainly enough, the IDs match.
Everything works like we wanted it to.
We've successfully connected the user's data in the database to their authenticated account.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.