1
00:00:00,810 --> 00:00:04,210
Are at my friends are all down with our blog application in this video.

2
00:00:04,210 --> 00:00:08,320
I want to do a quick wrap up on some of the really high points of some of the things that we learned

3
00:00:08,380 --> 00:00:09,340
inside this app.

4
00:00:09,370 --> 00:00:10,720
So let's get to it.

5
00:00:10,940 --> 00:00:15,910
Inside of a root index such as file we had imported redux thunk and then we imported.

6
00:00:15,910 --> 00:00:20,030
Are we wired up to a redux store through the use of Applied middleware right here.

7
00:00:20,200 --> 00:00:24,040
We called Applied middleware which is a function from the redux library itself.

8
00:00:24,090 --> 00:00:30,240
We passed the result of that into the second argument of the create store call when we apply that middleware

9
00:00:30,250 --> 00:00:31,150
of redux thunk.

10
00:00:31,210 --> 00:00:37,550
Anytime that we dispatch an action the action will be first sent to redux thunk as the middleware and

11
00:00:37,560 --> 00:00:42,450
then after redux thunked the action will be sent off to all of our different reducers when we wired

12
00:00:42,450 --> 00:00:46,190
up redux thunk it changed the rules of our action creators.

13
00:00:46,230 --> 00:00:51,660
So inside of our action creators file we no longer had to create action creators that always returned

14
00:00:51,730 --> 00:00:54,780
in action object instead with redux thunk.

15
00:00:54,780 --> 00:00:59,210
We could also optionally return a function if we return a function.

16
00:00:59,360 --> 00:01:03,960
It would be automatically called with the dispatch and get state arguments and that essentially gave

17
00:01:03,960 --> 00:01:09,240
us total control over changing or getting information out of our redux store.

18
00:01:09,540 --> 00:01:15,270
Anytime that we expect to make an API request from an actual creator we are always going to make use

19
00:01:15,270 --> 00:01:17,400
of something like redux stunk.

20
00:01:17,610 --> 00:01:23,340
There are other options out there to allow you to make API requests or otherwise async behaviors but

21
00:01:23,340 --> 00:01:25,670
redux thunk is by far the most popular one.

22
00:01:26,420 --> 00:01:30,720
When we return a function from our action creators we use this really interesting syntax right here

23
00:01:30,750 --> 00:01:37,060
and remember all that's going on right there is we have a function that returns a function like so.

24
00:01:37,890 --> 00:01:42,840
So we had the outer function outer function and then whenever we called it it automatically returned

25
00:01:42,840 --> 00:01:45,580
this inner function just as you see right there.

26
00:01:45,750 --> 00:01:48,500
The syntax that you see inside of here is very common.

27
00:01:48,510 --> 00:01:53,760
You're going to use it on quite a bit of projects any time that you make use of redux sunk.

28
00:01:53,820 --> 00:01:59,760
Now for the alternate solution to solving over fetching stuff we saw how we could create an action creator

29
00:01:59,820 --> 00:02:05,760
that somehow called other action creators and made sure that we still dispatch the result of calling

30
00:02:05,760 --> 00:02:08,440
those action creators.

31
00:02:08,460 --> 00:02:10,940
All right so the last thing really quickly are reduced.

32
00:02:10,950 --> 00:02:13,480
So we learned a ton about our reducers.

33
00:02:13,590 --> 00:02:18,810
We learned that the first argument is what I refer to as states and it is whatever was returned from

34
00:02:18,810 --> 00:02:24,180
this reducer or the last time that it ran so we run these reducers over and over again and whatever

35
00:02:24,600 --> 00:02:28,190
whenever we return shows up as that first argument.

36
00:02:28,680 --> 00:02:32,940
We learned that we usually make use of this switch statement syntax inside a very douceur.

37
00:02:33,000 --> 00:02:35,310
Again this is a extremely common pattern.

38
00:02:36,140 --> 00:02:41,150
Inside of our user's reducer we saw some other really common syntax that we're going to see in a lot

39
00:02:41,150 --> 00:02:42,070
of reducers.

40
00:02:42,090 --> 00:02:47,870
So remember anytime that we return some data from a reducer we always have to return a new array or

41
00:02:47,900 --> 00:02:53,990
a new object or a different valued string or a different value number if we expect redux to realize

42
00:02:53,990 --> 00:02:57,270
that we made a change to the data inside of our application.

43
00:02:57,530 --> 00:03:04,580
If we ever just return the exact same object or array redux has that very simple comparison where it

44
00:03:04,940 --> 00:03:09,010
just checks to see if that is the same object or array in memory.

45
00:03:09,140 --> 00:03:14,720
And if it is redux says oh no data has changed and it does not update the rest of your application and

46
00:03:14,720 --> 00:03:19,460
tell the Riak side of your app to actually re render itself and pull down new state and show some new

47
00:03:19,460 --> 00:03:20,870
content on the screen.

48
00:03:21,280 --> 00:03:26,230
OK so that's a quick highlight of some of the big topics that we discussed inside of this application.

49
00:03:26,420 --> 00:03:28,010
So we still have a lot more to learn.

50
00:03:28,010 --> 00:03:29,740
So let's take a pause right here.

51
00:03:29,780 --> 00:03:33,700
We'll start talking about the next application we're going to work on in just a little bit.