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
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
Now as kind of a bonus,
you could say to this module
we can also practice working with useReducer again
because what did we learn about useReducer?
When does it shine or when is it worth considering using it?
We learned that it's great to use users, user
or that it's worth a thought to use useReducer
if we need more power.
So if you have a lot of different possible state values
and a lot of complex state updating logic
but also if we have related pieces of state
which are managed in individual states
especially if those states depend on each other.
Now, arguably, that's not really the case here.
We never have a lot of different state values
nor a very complex state updating logic here.
And in addition we do have multiple states
that kind of belong together
the value and the touch state.
They both kind of represent the state of the input element
but they don't really depend on each other.
That would not really be true to state this
nonetheless to practice working with useReducer again,
I will import useReducer here now instead of useState
and now use useReducer for
managing these two state pieces here.
But again, it's not strictly required
it's mainly another practice for useReducer.
So I'll start by adding a reducer function,
input, state reducer function we could say,
and you'll learn that this reducer function
takes two main arguments.
The previous state snapshot, which will be provided
and passed in automatically by React
and an action which will also be passed
into this function automatically by React.
But which is the action you dispatched somewhere
in your code.
And then ultimately you have
to return a new state snapshot here,
and we can return a default state snapshot
which we always return unless we change it in code
we're about to add, and that could contain our value.
So the value for this input
which initially is an empty string
and the is touched state,
which initially is false.
And then here in the use input hook,
we can call useReducer
and pass our input state reducer function to useReducer
and also provide our initial state
which is basically this state here
and hence I'll add the number of constant
initial input state
which simply holds this object.
And I returned this object here
and I also set this here as an initial state.
So the initial input state.
Now useReducer as you learned returns an array
with exactly two elements, just like useState.
And the first element is always the state managed
by the reducer.
So the input state as we could call it.
And the second element is always a dispatched function
which allows you to dispatch actions against that reducer.
So I'll name it dispatch,
but you can of course pick any name you want here.
Now we can get rid of these two states license here now,
and now instead start working with input state and dispatch.
For example, here for validating the value there
we can now use input state dot value.
We know that our input state will have a value property
because that is the structure our state here will have
the state managed by this reducer.
We can also get the touch state from there
input state is touched.
Now when value change handler executes
we wanna dispatch an action against our reducer
and you learn that it's totally up to you
how is such an actual looks like, but it often is an object
with a type property which identifies the action
and here I'll sets type to a string called input
and it can also carry a payload.
And here I'll add a value property to this object
which holds event target value as a value.
And then I can get rid of this line here,
where we set, entered to value.
Now we also wanna dispatch in the end input blur handler
and there we could use the identifier blur
and we can also provide a value here
but we're not actually interested in the value here.
So there instead,
I can also just pass in an action like this.
Now, when we reset
we can dispatch an object where to type is reset.
For example, now when we return,
I wanna return the value
and that would be input state dot value
and data's already it with that we're good here.
So now we just need to handle these free action types
input blur and reset in this reducer.
So we can check if action dot type is equal to input
or if action type is equal to blur
or if action type is equal to reset.
Now, if it is equal to input then
I wanna return a new state object
where I in the end
set value to action dot value
because in the input action case here,
we will have a value property on the action object,
which carries the entered value.
And I wanna set the state.
Now I don't wanna set is touched to true
because whilst we have a keystroke
the user didn't finish typing yet.
So I don't wanna set is touched to true
otherwise we would kind of break to
behavior rebuilt over this module
where we only present error messages
once the user is really done,
hence here, instead I wanna copy the existing state.
So I will set is touched here to state dot is touched
using the previous states is touched value.
Now in the blur case I wanna return a new object as well.
And here I wanna set is touched to true
because that is what we do when the input blurs
it should now be marked as touched
on the other hand here I don't care about the value
we could update it.
We could get it from this event object in
the input blur handler
but we don't really need to do that
since we're updating the value on every keystroke anyways.
So hence here I can set value to state dot value
simply using the existing value.
And if we reset,
I return an object where I said is attached to false
and value back to an empty string to reset this.
And this is now our custom hook using useReducer.
If you now check does again here
you still get the same behavior as before
where we can fill out the form to make it work
and where we still also get errors, if we will have errors.
So that all still works as before.
But now with the useReducer simply as
a little extra exercise.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.