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
We've got the template design loading in like we want it to.
The next step is to make the app functional, but the question is where do we start?
There are so many areas to cover.
I always prefer to start with the user system.
Most applications, regardless of their use, rely on a user system to work.
You can't upload a song unless you know who's uploading it.
It depends on the needs of your app.
For this example, I think it would be a good starting point.
In order to have users, we need to be able to store and manage users.
We'll need to have a way to authenticate or register them.
Authentication and registration is a good starting point.
We'll begin with the user system.
Before we begin coding the logic, we first need to understand something called State.
The word state is a word that's thrown around a lot in the world of JavaScript.
But what exactly does it mean?
State refers to the data in the application.
This can be data retrieved from a database or API data like a blog post product or media content.
You can use the state to store application data too.
There are certain types of data you wouldn't normally store in a database.
However, they are still necessary for your app to function correctly.
For example, a simple dropdown.
If a user clicks on a dropdown button, then the contents of that dropdown should be shown.
If they click away from that dropdown, then the content should be hidden.
This is the type of data you would have to keep track of.
Another example would be keeping track of the page the user is currently on.
Are they on the home page or contact page?
Depending on the URL.
You would display different content.
You provides one way of storing data by adding the data function to a component, while not wrong.
It's considered good practice to have one single source of truth.
All of this is considered the state of the application when you hear the word state.
It's another way of saying data.
It's data that is carefully kept track of while the application is live on a user's browser.
If the user is on the home page, then you can call this the home state.
If they're logging in, then you can call this the authentication state.
It's used to describe what is currently happening in the application.
So don't think of state as the data from the database.
It's also the data that keeps track of the little things.
The route this course.
We've been using the data property as a way to keep track of things.
The data property can be considered a way to store local state its data that only one component needs.
However, what if we need to share data across multiple components?
We need a way to have global state.
Global state is when data is shared across multiple components.
We have the option of passing down data to other components using prompts to send data back to the parent
component.
You could use a callback, function or image and events.
In this example, let's say I had data that was used in child components B and C.
Child component C is capable of updating the data to perform updates on data.
We first have to pass down a callback function to child component A and then to C.
Child component C can use the callback function to update the data inside the parent component.
Lastly, the updated data would be sent to component B.
This is the usual flow of data.
It's what we've been doing up until now for a small to a medium sized application.
This works fine.
It's a bit annoying to have to pass down everything, but it's certainly doable and manageable.
For larger applications, this process of managing global estate can become quite tedious very quickly.
Imagine if you had ten layers of components in your application.
That means you would have to pass down a callback function ten times.
That isn't very fun.
Luckily, Vue allows you to create your own library to manage state on a global level.
We won't be going down that route.
It's not necessary to do so.
Instead, there are already libraries out there that will do this for us.
The most popular solution is called Pernilla.
Pernilla is a library for storing data in a central location.
You won't have to pass it down from component to component.
The state is directly accessible to all components.
It doesn't matter how deeply nested your components are, the data can be retrieved or updated.
Any changes to the data are reflected in all components.
This means it's no longer necessary to pass down data through several children components.
Data is handled in one centralized location.
Fania is maintained by the core developers of Vue.
You don't have to worry about compatibility issues.
This is the library we'll be using for the rest of this course.
There's one important point I want to stress.
Centralised state is completely optional.
Even if you have it installed.
Sometimes you'll have data that will be used in a single component.
If you don't plan on passing it down onto other components, you don't need to store it inside.
These centralised state components can still have their own set of data.
That's important to understand.
You don't want to clutter your state.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.