1
00:00:01,609 --> 00:00:05,600
We're going to test out our reducer in just a moment, but first, I want to go over a quick little

2
00:00:05,600 --> 00:00:06,470
side issue.

3
00:00:06,800 --> 00:00:10,370
So in the last couple of videos, you might recall that I told you several times, oh, yeah, we don't

4
00:00:10,370 --> 00:00:15,860
have to return our state object anymore from inside of our reducer because IMR is just going to automatically

5
00:00:15,860 --> 00:00:16,850
take care of everything.

6
00:00:16,850 --> 00:00:20,600
It's going to find all the changes we made towards the object, and that's pretty much that.

7
00:00:21,020 --> 00:00:22,610
So that's absolutely true.

8
00:00:22,850 --> 00:00:27,800
IMR is going to take a look at our state object, see what changes we made to it, and then automatically

9
00:00:27,800 --> 00:00:31,470
take care of providing Redox with our updated state object.

10
00:00:31,790 --> 00:00:37,460
However, there is a big Gocha here, and the reason that I want to go over this entire topic instead

11
00:00:37,460 --> 00:00:42,440
of a separate video is because if you just follow exactly what the IMR documentation says, which is

12
00:00:42,440 --> 00:00:47,120
pretty much what we did, you're going to very quickly run into a little issue with TypeScript.

13
00:00:47,720 --> 00:00:52,130
So let me show you a little problem that we have inside of our application right now because of how

14
00:00:52,130 --> 00:00:53,540
we have set up our producer.

15
00:00:54,200 --> 00:00:57,950
I'm going to go back over to my Staats file inside my state directory.

16
00:00:58,340 --> 00:01:01,070
So as a quick reminder, we are creating our store inside of here.

17
00:01:01,990 --> 00:01:06,610
A second quick reminder, I want to give you as if you ever want to manually get all the estate out

18
00:01:06,610 --> 00:01:09,970
of your store, you can call Staat, get state.

19
00:01:11,170 --> 00:01:17,620
So I'm going to assign that call to a variable I'm going to call state for just a moment and then go

20
00:01:17,620 --> 00:01:22,520
into mouseover state and we're going to take a look at the type of data that is returned from that gets

21
00:01:22,540 --> 00:01:23,230
date call.

22
00:01:24,130 --> 00:01:26,130
I want you to see something really clearly here.

23
00:01:26,710 --> 00:01:32,650
This is saying that we are returning or the state variable is going to be some kind of object that has

24
00:01:32,650 --> 00:01:33,220
a cels.

25
00:01:33,220 --> 00:01:40,210
Property sales is going to be of type either sell state or some object that has all these properties.

26
00:01:41,760 --> 00:01:45,900
If we keep on scrolling down a little bit, however, you'll notice that there's a little case down

27
00:01:45,900 --> 00:01:48,330
here that says or undefined.

28
00:01:48,750 --> 00:01:54,780
So it means that our state variable right there is going to be an object that has a sales property that

29
00:01:54,780 --> 00:02:00,030
conforms to either the cells state interface or it is going to be undefined.

30
00:02:00,810 --> 00:02:07,380
That means that if we ever tried to access state dot cells, dot, say, maybe data or air or loading

31
00:02:07,380 --> 00:02:11,030
any of these different properties, we're going to very quickly see an error message.

32
00:02:11,310 --> 00:02:16,680
And that's because states cells might possibly be undefined in such script, wants us to handle that

33
00:02:16,680 --> 00:02:17,130
case.

34
00:02:17,730 --> 00:02:21,720
So why would TypeScript think that state dot cells might be undefined?

35
00:02:22,240 --> 00:02:27,090
Well, again, it all comes back to how we just put together a producer reducer script has taken a look

36
00:02:27,090 --> 00:02:28,380
at the reducer we put together.

37
00:02:28,620 --> 00:02:33,480
And because there are some cases where we return undefined or nothing at all, TypeScript is saying,

38
00:02:33,480 --> 00:02:38,580
oh, well, whenever this reducer is called, it's going to either return something that satisfies the

39
00:02:38,640 --> 00:02:42,090
cells state interface or undefined.

40
00:02:43,010 --> 00:02:48,380
And that's the whole issue, because we are returning nothing in these cases, TypeScript, is incorrectly

41
00:02:48,380 --> 00:02:51,730
thinking that state cells might sometimes be undefined.

42
00:02:52,280 --> 00:02:56,630
And so to handle this, we would have to write in a lot of extra code to our project to say, hey,

43
00:02:56,810 --> 00:03:01,250
let's try to make sure that sales actually is defined and that we actually have some piece of state

44
00:03:01,250 --> 00:03:01,520
there.

45
00:03:02,060 --> 00:03:03,290
Well, that's one solution.

46
00:03:03,290 --> 00:03:08,570
But the other solution is to just go that extra little mile and for every single return statement,

47
00:03:08,870 --> 00:03:14,260
go ahead and do the return state anyways, even though it is not strictly necessary.

48
00:03:14,900 --> 00:03:19,010
So inside of our producer, we're going to find all of our different return statements and we are going

49
00:03:19,010 --> 00:03:21,440
to add in return state after all.

50
00:03:22,100 --> 00:03:23,180
So here's a case one.

51
00:03:24,100 --> 00:03:29,860
Case two, I got my return state, case three, I'm going to go into the statement and add in return

52
00:03:29,860 --> 00:03:30,310
state.

53
00:03:31,210 --> 00:03:33,970
There's another return right there, all that in return state.

54
00:03:36,730 --> 00:03:38,370
And then finally, we've got the last two done here.

55
00:03:38,500 --> 00:03:44,290
Did leave on the return state, so I should now be able to do a search inside this file or return.

56
00:03:44,590 --> 00:03:46,530
And besides, inside a random idea right there.

57
00:03:46,540 --> 00:03:50,560
Of course, all other return statements should be returning state.

58
00:03:51,160 --> 00:03:52,680
And I can definitely confirm that.

59
00:03:53,560 --> 00:03:59,470
Now, if I go back over to my Staats file, I'm no longer getting an air from state dot cells because

60
00:03:59,470 --> 00:04:04,490
now TypeScript is correctly seeing that in all cases we are in fact returning some state object.

61
00:04:04,840 --> 00:04:07,750
Now, again, this is not strictly necessary per say.

62
00:04:08,080 --> 00:04:13,720
Our entire application would work just fine if we ran it in the browser without going or returning that

63
00:04:13,720 --> 00:04:18,519
Steet object, because IMR is going to automatically find all those changes, make the state updates

64
00:04:18,790 --> 00:04:21,370
itself, and then return a state object for us.

65
00:04:21,700 --> 00:04:24,580
So this is just an extra little step to make TypeScript happy.

66
00:04:24,580 --> 00:04:25,180
And that's it.

67
00:04:25,180 --> 00:04:25,860
Nothing else.

68
00:04:26,680 --> 00:04:31,480
The whole reason I just wanted to go over this in great detail and I wanted to kind of show you what

69
00:04:31,480 --> 00:04:35,260
the IMR documentation says, which is that you don't technically have to return.

70
00:04:35,260 --> 00:04:40,240
State object is, again, just because the documentation says that, because if you just go and read

71
00:04:40,240 --> 00:04:45,280
the documentation, you might get tricked into thinking, oh, we don't need to return anything from

72
00:04:45,280 --> 00:04:45,970
our reducers.

73
00:04:46,210 --> 00:04:47,970
Well, you technically don't.

74
00:04:47,980 --> 00:04:49,570
But again, to make TypeScript happy.

75
00:04:49,600 --> 00:04:50,050
You do.

76
00:04:51,210 --> 00:04:55,950
So just to kind of show you the stuff in action, if you go back over to the Murdochs, all these different

77
00:04:55,950 --> 00:05:00,690
mutation things, these notes we've looked at again, in all cases, they never showed returning anything.

78
00:05:01,110 --> 00:05:04,710
You'll also see on the left hand side, there's an example reducer over here.

79
00:05:05,220 --> 00:05:11,010
And if you scroll down to the IMR example, again, they are not returning anything in this case either.

80
00:05:11,250 --> 00:05:14,340
But of course, in this case, they're using plain JavaScript, not typescript.

81
00:05:14,770 --> 00:05:16,050
So this would absolutely work.

82
00:05:16,050 --> 00:05:19,500
OK, with JavaScript you would technically work on with TypeScript as well.

83
00:05:19,810 --> 00:05:24,180
But again, to make TypeScript happy, we do have to return our state object.

84
00:05:25,160 --> 00:05:26,160
OK, so that's it.

85
00:05:26,180 --> 00:05:30,880
Just want to go over that little gotcha that you might run into as soon as you start making use of IMR.

86
00:05:31,430 --> 00:05:35,320
So now that we've made these updates, I'm going to go back over to my Staats file.

87
00:05:35,750 --> 00:05:39,380
I'm going to clean up everything inside there, those two lines of code I just added.

88
00:05:39,770 --> 00:05:41,510
So let's take another pause right now.

89
00:05:41,520 --> 00:05:46,130
And as I mentioned, we're going to try to do a little bit of manual testing of our retexture.

90
00:05:46,130 --> 00:05:48,970
Just make sure everything is working as expected in the next video.

