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
French
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
Polish
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 by now we learned a lot
about the important basics of Redux and how we use it.
Now the more complex our projects become
the more complex it can get to use Redux correctly.
Now the good thing is that in this course
you will of course see many examples also bigger projects
than this one but another good news
is that there is a slightly easier way
of using Redux as well.
Now I wanted to show you the core foundation first
so that you understand how it works
but now I want to dive into an approach
that's a bit easier to set up and maintain.
Before we do that though, let's identify a couple
of potential problems we could be facing here
if our application would continue to grow.
So if we manage more and more state with Redux.
One potential issue can be our action types.
These identifiers, I mentioned it before,
you of course have to avoid typos.
If you dispatch an action, you have to make sure
that you don't mistype the identifier here
otherwise it of course won't be handled by the reducer
or won't be handled correctly.
Now that's not a problem in a small app like this
but in bigger applications with a lot of developers working
on the app and with a lot of different actions
it's super easy to imagine
that you could mess up one of these identifiers.
You could even have clashing identifiers there
so clashing identifier names.
So therefore having some way
of defining those identifiers once
and then reusing them would be nice.
And that is something we can do with JavaScript
and something I will come back to in a second.
Another potential problem is the amount
of data which we manage here.
The more data we have the more different pieces
of state we have, the bigger our state objects get.
And that means that we need to copy a lot of state
when we update the counter we still need to copy
and keep all the other state properties,
and it also means that this reducer function gets longer
and longer and all of a sudden
we might have an unmaintainable big Redux file.
And you might recall that I brought this up
as one potential disadvantage of React Context.
If we put everything into one context provider file.
Now we can end up with the same problem with the Redux
but thankfully there are solutions for that with Redux.
Another potential problem we could be facing
is the state immutability which we have to respect.
I talked about it in the last lecture.
We have to ensure that we always return
a brand new state snapshot
and that we don't accidentally change
the existing state anywhere.
And especially if you have more complex data
with nested objects and arrays it's easy to mess this up
and accidentally change some nested data
even though you didn't want to.
So it would be great if we would have
some help with that as well.
And if we could ensure that we don't accidentally
manipulate nested data or anything like that.
Now for all those problems there are solutions
we could implement on our own.
For example, for ensuring that we have unique identifiers
and we don't miss type we could create constants,
let's say a constant named increments
which stores this identifier,
and we then export this constant
and we check that constants value here and we then import
and use that constant in the counter component
so that here we use the type increment
and we just import increments.
So we import increment from going up store index.
That is something we could do to fix this issue.
And these are approaches which we typically used
in the past with Redux.
There also are solutions for splitting your reducer
into multiple smaller reducers
so that you don't get this large super big file,
and there also our solutions and third-party packages
which allow you to automatically copy state
and ensure that you don't accidentally edit it.
But we actually don't need to dive
into those various solutions anymore.
Instead there is another library called Redux Toolkit.
And you can just Google for Redux Toolkit
to find its official page.
It's actually developed by the same person
or the same team as React Redux and Redux itself
and Redux Toolkit simply as an extra package
which makes working with Redux more convenient and easier.
You don't have to use it, unlike Redux and react Redux
which we installed before, you don't have to install
and use Redux toolkit but if you use it,
certain things will get easier.
And therefore, in the next lecture
we're going to get started with Redux Toolkit.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.