Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:02,150 --> 00:00:04,130
So, were you successful?
2
00:00:04,130 --> 00:00:06,050
Let's do the same for the password.
3
00:00:06,050 --> 00:00:08,330
Of course it should be fairly trivial.
4
00:00:08,330 --> 00:00:10,503
We create our passwordReducer
5
00:00:13,140 --> 00:00:14,850
which is an anonymous function
6
00:00:14,850 --> 00:00:18,640
that gets the last state and the action.
7
00:00:18,640 --> 00:00:21,680
And, yeah, well, we can just copy this, can we?
8
00:00:21,680 --> 00:00:23,423
We can copy this in here.
9
00:00:24,750 --> 00:00:27,400
The validation code needs to change
10
00:00:27,400 --> 00:00:28,325
because for the password,
11
00:00:28,325 --> 00:00:30,400
I'm checking the length.
12
00:00:30,400 --> 00:00:33,330
So, I wanna copy this code down there
13
00:00:33,330 --> 00:00:36,663
and use this here and here.
14
00:00:38,350 --> 00:00:41,100
The action names can be the same,
15
00:00:41,100 --> 00:00:41,933
but now of course
16
00:00:41,933 --> 00:00:45,313
we also need to call useReducer again here.
17
00:00:47,750 --> 00:00:50,200
Now, for the passwordReducer
18
00:00:51,610 --> 00:00:55,430
and what we get back therefore is the passwordState
19
00:00:56,320 --> 00:00:59,863
and the dispatchPassword function.
20
00:01:01,230 --> 00:01:02,900
We also wanna set an initial state
21
00:01:02,900 --> 00:01:07,080
which can be the same one as here for the email of course,
22
00:01:07,080 --> 00:01:11,923
just as object with no value and null isValid state.
23
00:01:14,140 --> 00:01:18,440
And now, we simply have to update the code accordingly,
24
00:01:18,440 --> 00:01:19,273
setFormIsValid,
25
00:01:21,490 --> 00:01:24,440
here I'm not interested in the enteredPassword,
26
00:01:24,440 --> 00:01:28,780
but instead, now that we do validation in here,
27
00:01:28,780 --> 00:01:33,780
I only want to access my passwordState
28
00:01:34,210 --> 00:01:36,123
and there the isValid prop.
29
00:01:37,510 --> 00:01:41,820
And when the password changes,
30
00:01:41,820 --> 00:01:44,660
I want to call dispatchPassword,
31
00:01:44,660 --> 00:01:47,720
pass an object where I have to USER_INPUT type
32
00:01:47,720 --> 00:01:52,343
and the val field which is the event.target.value.
33
00:01:54,730 --> 00:01:58,690
And here, when the password field blurs,
34
00:01:58,690 --> 00:02:00,917
I also have dispatchPassword
35
00:02:00,917 --> 00:02:03,263
and the type is just INPUT_BLUR.
36
00:02:05,180 --> 00:02:08,169
And here, I'm not caring about the enteredPassword
37
00:02:08,169 --> 00:02:10,669
but the password state
38
00:02:10,669 --> 00:02:14,083
and the value entered by the user.
39
00:02:15,310 --> 00:02:17,263
And then we can go down,
40
00:02:18,250 --> 00:02:20,230
and for the password field here,
41
00:02:20,230 --> 00:02:24,313
we have passwordState.isValid in our check,
42
00:02:25,310 --> 00:02:28,950
and we feed back the passwordState.value
43
00:02:28,950 --> 00:02:30,283
into the input field.
44
00:02:31,300 --> 00:02:32,543
And if I go up,
45
00:02:33,660 --> 00:02:36,360
we see, we use nothing here,
46
00:02:36,360 --> 00:02:38,980
so we can comment out these two useState calls.
47
00:02:38,980 --> 00:02:40,100
And with that,
48
00:02:40,100 --> 00:02:42,014
again, if we give this a try,
49
00:02:42,014 --> 00:02:44,740
this all should work just fine,
50
00:02:44,740 --> 00:02:45,593
and it does.
51
00:02:46,910 --> 00:02:49,220
Now that wasn't too difficult hopefully,
52
00:02:49,220 --> 00:02:52,700
it's again the same what we did for emailReducer.
53
00:02:52,700 --> 00:02:57,070
And, of course you might see potential here
54
00:02:57,070 --> 00:03:00,570
for using just one reducer function instead of two
55
00:03:00,570 --> 00:03:03,640
because it's almost the same.
56
00:03:03,640 --> 00:03:05,800
The validation logic is different though,
57
00:03:05,800 --> 00:03:08,980
so that's definitely refactorable
58
00:03:08,980 --> 00:03:11,160
but it takes a little bit more work
59
00:03:11,160 --> 00:03:13,050
which is why I'm not going to do it here.
60
00:03:13,050 --> 00:03:15,783
But generally, it's not too far off.
61
00:03:16,640 --> 00:03:17,890
And in addition,
62
00:03:17,890 --> 00:03:20,730
and that's the thing that matters more to me here,
63
00:03:20,730 --> 00:03:22,300
the foreign validity,
64
00:03:22,300 --> 00:03:26,220
of course also is a bit related to the input validity
65
00:03:26,220 --> 00:03:29,710
because the inputs are part of the overall form.
66
00:03:29,710 --> 00:03:34,020
So the code we have here is still not optimal
67
00:03:34,020 --> 00:03:36,420
because we still derive the foreign validity
68
00:03:36,420 --> 00:03:38,130
off of upper state,
69
00:03:38,130 --> 00:03:40,330
which is still not what we want
70
00:03:40,330 --> 00:03:42,510
due to the reasons I explained earlier
71
00:03:42,510 --> 00:03:44,800
with React's scheduling the state updates.
72
00:03:44,800 --> 00:03:47,660
So we might still refer to an old state here
73
00:03:47,660 --> 00:03:49,290
that does not change
74
00:03:49,290 --> 00:03:50,350
just because the state
75
00:03:50,350 --> 00:03:53,430
is coming from useReducer setFormIsValid,
76
00:03:53,430 --> 00:03:55,300
like this still is not optimal.
77
00:03:55,300 --> 00:03:56,730
And in addition,
78
00:03:56,730 --> 00:04:00,200
having our state that is split like this
79
00:04:00,200 --> 00:04:03,080
even though it's technically belongs together
80
00:04:03,080 --> 00:04:04,983
is also not something you might want.
81
00:04:05,830 --> 00:04:07,870
Now, whether you want this or not is up to you,
82
00:04:07,870 --> 00:04:11,840
but the fact that this is not optimal is a fact.
83
00:04:11,840 --> 00:04:13,020
So for this,
84
00:04:13,020 --> 00:04:15,030
let's comment this out again,
85
00:04:15,030 --> 00:04:17,040
and let's go back to the use of fact solution
86
00:04:17,040 --> 00:04:19,200
which actually is a nice solution.
87
00:04:19,200 --> 00:04:20,769
So we can go back to this,
88
00:04:20,769 --> 00:04:22,880
and just update it accordingly.
89
00:04:22,880 --> 00:04:25,290
Here, we have to emailState
90
00:04:25,290 --> 00:04:27,320
and there simply isValid.
91
00:04:27,320 --> 00:04:29,670
Instead of doing validation here,
92
00:04:29,670 --> 00:04:31,100
and the same for the password,
93
00:04:31,100 --> 00:04:33,800
we have the passwordState.isValid,
94
00:04:33,800 --> 00:04:34,960
just like this.
95
00:04:34,960 --> 00:04:35,830
And hence here,
96
00:04:35,830 --> 00:04:38,675
we care about the emailState
97
00:04:38,675 --> 00:04:40,508
and the passwordState.
98
00:04:42,024 --> 00:04:43,500
And this what now be a fine way
99
00:04:43,500 --> 00:04:45,390
of calling setFormIsValid,
100
00:04:45,390 --> 00:04:48,380
because since it's now inside of an effect,
101
00:04:48,380 --> 00:04:51,020
we still refer to our state snapshots,
102
00:04:51,020 --> 00:04:53,460
but this effect is guaranteed to rerun
103
00:04:53,460 --> 00:04:55,330
whenever these states change,
104
00:04:55,330 --> 00:04:56,600
and therefore ultimately,
105
00:04:56,600 --> 00:04:59,243
it will run with the latest state values.
106
00:05:00,230 --> 00:05:04,330
So this actually is now an okay way of updating a state
107
00:05:04,330 --> 00:05:06,090
based on other state
108
00:05:06,090 --> 00:05:07,540
because with use effect,
109
00:05:07,540 --> 00:05:10,050
we're guaranteed that this will run
110
00:05:10,050 --> 00:05:12,830
for every state update React performs,
111
00:05:12,830 --> 00:05:14,340
which was not the case before
112
00:05:14,340 --> 00:05:16,190
where maybe the code ran too early,
113
00:05:16,190 --> 00:05:19,110
useEffect only runs after state updates.
114
00:05:19,110 --> 00:05:20,703
So here, this is okay.
115
00:05:21,940 --> 00:05:23,060
Now, still here,
116
00:05:23,060 --> 00:05:24,690
we have a problem though,
117
00:05:24,690 --> 00:05:27,180
which is why I'm showing this to you.
118
00:05:27,180 --> 00:05:29,830
This now will run accordingly and correctly,
119
00:05:29,830 --> 00:05:31,360
and hence here indeed,
120
00:05:31,360 --> 00:05:33,083
if I enter something here,
121
00:05:34,420 --> 00:05:36,950
eventually does unlocks and works.
122
00:05:36,950 --> 00:05:40,210
But, the problem we'll have here is,
123
00:05:40,210 --> 00:05:43,473
that this effect runs too often.
124
00:05:44,520 --> 00:05:45,640
This will run
125
00:05:45,640 --> 00:05:48,740
whenever the email or the passwordState changed.
126
00:05:48,740 --> 00:05:51,240
Now that includes cases
127
00:05:51,240 --> 00:05:54,423
where maybe just the value changed,
128
00:05:55,490 --> 00:05:57,730
which might not be what we want.
129
00:05:57,730 --> 00:06:01,180
We actually only care about the validity here.
130
00:06:01,180 --> 00:06:03,480
Now it turns out that we updated the validity,
131
00:06:03,480 --> 00:06:06,250
now whenever the value changes as well.
132
00:06:06,250 --> 00:06:08,450
But, of course, if, for example,
133
00:06:08,450 --> 00:06:10,530
the input was valid already,
134
00:06:10,530 --> 00:06:13,490
and we then add an extra character to the password,
135
00:06:13,490 --> 00:06:14,700
it doesn't really change.
136
00:06:14,700 --> 00:06:17,440
It was valid before with the extra character,
137
00:06:17,440 --> 00:06:18,763
it's still valid.
138
00:06:20,070 --> 00:06:21,070
So here, for example
139
00:06:23,440 --> 00:06:25,290
if I have a password that is valid,
140
00:06:25,290 --> 00:06:26,570
if I add one more character,
141
00:06:26,570 --> 00:06:27,640
it's still valid.
142
00:06:27,640 --> 00:06:32,640
Nonetheless, our effect re-executed here.
143
00:06:34,890 --> 00:06:36,970
Now that's something we might wanna avoid
144
00:06:36,970 --> 00:06:38,730
and it re-executes at the moment
145
00:06:38,730 --> 00:06:40,180
because our dependency
146
00:06:40,180 --> 00:06:42,430
is the entire email and passwordState,
147
00:06:42,430 --> 00:06:45,020
not just the validity part of it
148
00:06:45,020 --> 00:06:47,370
which is actually the part we're interested in.
149
00:06:48,290 --> 00:06:49,410
Here, we can use a technique,
150
00:06:49,410 --> 00:06:50,350
which you need to know
151
00:06:50,350 --> 00:06:52,570
which is why I'm showing it to you.
152
00:06:52,570 --> 00:06:55,070
We can use object de-structuring,
153
00:06:55,070 --> 00:06:57,110
so the same as array destructuring,
154
00:06:57,110 --> 00:06:58,430
just with objects,
155
00:06:58,430 --> 00:07:02,610
to pull out certain properties of objects.
156
00:07:02,610 --> 00:07:04,720
For example, from emailState,
157
00:07:04,720 --> 00:07:06,920
we can extract isValid,
158
00:07:06,920 --> 00:07:09,560
and store it in a new constant of the same name.
159
00:07:09,560 --> 00:07:12,670
And we can do the same for the passwordState.
160
00:07:12,670 --> 00:07:16,200
But since I'm already using isValid in this constant now,
161
00:07:16,200 --> 00:07:20,170
we can use a variation of the object de-structuring syntax.
162
00:07:20,170 --> 00:07:22,120
We can add a colon here,
163
00:07:22,120 --> 00:07:24,470
which now won't assign a value
164
00:07:24,470 --> 00:07:26,660
because we're not creating an object here.
165
00:07:26,660 --> 00:07:29,410
We're using it on the left side of the equal sign.
166
00:07:29,410 --> 00:07:32,090
This is simply the syntax for object de-structuring.
167
00:07:32,090 --> 00:07:33,170
And with the object,
168
00:07:33,170 --> 00:07:36,830
we now assign an alias to de-extract that value,
169
00:07:36,830 --> 00:07:38,430
to de-extract the property.
170
00:07:38,430 --> 00:07:40,760
So we're pulling out the isValid property
171
00:07:40,760 --> 00:07:42,760
but we're storing it in a constant
172
00:07:42,760 --> 00:07:45,257
which actually could be named emailIsValid.
173
00:07:46,154 --> 00:07:47,900
At the same here for the password,
174
00:07:47,900 --> 00:07:50,060
we're pulling out the isValid property
175
00:07:50,060 --> 00:07:51,550
but we can store it in,
176
00:07:51,550 --> 00:07:55,290
let's say a passwordIsValid constant.
177
00:07:55,290 --> 00:07:57,290
So this is an alias assignment.
178
00:07:57,290 --> 00:07:58,950
This is not a value assignment,
179
00:07:58,950 --> 00:08:00,560
it's an alias assignment
180
00:08:00,560 --> 00:08:04,200
because it's part of this object de-structuring syntax
181
00:08:04,200 --> 00:08:06,680
which is the syntax you're automatically using
182
00:08:06,680 --> 00:08:08,460
if you're using those curly braces
183
00:08:08,460 --> 00:08:11,360
on the left side of the equal sign.
184
00:08:11,360 --> 00:08:15,130
And now we have the email and passwordIsValid constants
185
00:08:15,130 --> 00:08:16,713
which we can use here,
186
00:08:18,900 --> 00:08:20,413
as our dependencies,
187
00:08:21,610 --> 00:08:23,830
and as our values,
188
00:08:23,830 --> 00:08:26,910
your dependencies should be matched by your values
189
00:08:26,910 --> 00:08:28,270
and the other way around.
190
00:08:28,270 --> 00:08:32,653
So emailIsValid and passwordIsValid.
191
00:08:33,760 --> 00:08:36,010
Now the advantages that since now,
192
00:08:36,010 --> 00:08:38,730
I'm pulling out the isValid state here,
193
00:08:38,730 --> 00:08:41,070
whenever just the value changes
194
00:08:41,070 --> 00:08:43,870
and the validity did not change,
195
00:08:43,870 --> 00:08:46,220
this effect will not rerun.
196
00:08:46,220 --> 00:08:47,053
And you can see this,
197
00:08:47,053 --> 00:08:48,100
if I enter something here,
198
00:08:48,100 --> 00:08:49,370
of course, in the beginning,
199
00:08:49,370 --> 00:08:51,090
it will run.
200
00:08:51,090 --> 00:08:52,540
But once the passwordIsValid,
201
00:08:53,600 --> 00:08:55,590
if I'd have one extra character,
202
00:08:55,590 --> 00:08:57,980
you don't see an additional checking for
203
00:08:57,980 --> 00:08:59,290
in validity output,
204
00:08:59,290 --> 00:09:01,860
this is especially clear if I clean this.
205
00:09:01,860 --> 00:09:03,760
You see, I can type a lot of characters,
206
00:09:03,760 --> 00:09:05,160
this never checks again
207
00:09:05,160 --> 00:09:07,490
because the validity did not change.
208
00:09:07,490 --> 00:09:10,633
Of course, that's not the case if I make it too short.
209
00:09:11,670 --> 00:09:13,360
So, I wanted to show this
210
00:09:13,360 --> 00:09:15,340
because this is an important concept
211
00:09:15,340 --> 00:09:16,930
to further optimize useEffect
212
00:09:16,930 --> 00:09:21,040
and to avoid unnecessary effect execution,
213
00:09:21,040 --> 00:09:24,430
not just when using it with useReducer,
214
00:09:24,430 --> 00:09:26,850
but for example, also when doing so.
215
00:09:26,850 --> 00:09:28,860
Andother use case could be,
216
00:09:28,860 --> 00:09:32,300
if you have props as a dependency for your effect.
217
00:09:32,300 --> 00:09:35,370
You don't wanna rerun the effect whenever prompts change.
218
00:09:35,370 --> 00:09:36,203
You only wanna do
219
00:09:36,203 --> 00:09:37,580
is when some prompts change,
220
00:09:37,580 --> 00:09:40,040
for example, with object de-structuring,
221
00:09:40,040 --> 00:09:41,053
you can get there.
222
00:09:42,040 --> 00:09:45,000
So that's a little step back here to use a fact,
223
00:09:45,000 --> 00:09:46,750
but an important one,
224
00:09:46,750 --> 00:09:48,720
an equally important concept,
225
00:09:48,720 --> 00:09:50,793
of course, was useReducer though.
16500
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.