This course will be retired on April 12, 2021.
Now we're ready to move onto actually putting Redux into practice! In this lesson, you'll learn about action types and how they are used in Redux. Then we'll identify the explicit actions that the scoreboard application takes and define them as action types, which are defined in their own separate module.
[MUSIC] 0:00 In the previous stage we modularized the scoreboard app in order to make 0:04 the application easier to manage and in preparation for 0:08 introducing Redux features. 0:11 So now, we're ready to move on to actually putting Redux into practice. 0:12 So the best place to start is by answering the question, what actions does our 0:16 application have that will result in a change in application state? 0:20 We can answer that question by taking a closer look at our app. 0:24 Back in our project we want to look for any components that manage or 0:27 manipulate state either directly or through event methods. 0:31 Then we need to determine if state should be managed at an application level or 0:34 at the component level. 0:38 If we open up the scoreboard.js file we'll notice that there is an initial state 0:39 set for the players in our application and 0:44 note that this state is defined at the root level of our application. 0:47 Since scoreboard is the container component, 0:52 it passes this state down to other to other components. 0:54 So it would be a good candidate for 0:56 being included in what's called the Redux store which as you'll soon learn 0:58 is an object where the entire state of your application is stored. 1:02 But before we get started on integrating our player state into Redux 1:05 let's take a look at the rest of the app and 1:09 see if there are any other good state candidates to include in Redux. 1:10 If you quickly take a look at the rest of the components and the app you'll find 1:14 that the only other place where a managing state is within the stopwatch component. 1:18 So here in Stopwatch.js, 1:23 what you'll notice is that the state managed in the stopwatch is tightly 1:25 coupled to this component and has no dependencies on any other component. 1:30 This indicates that it's probably not the best candidate for 1:34 being a part of Redux and that it should be left alone. 1:37 You see, an important thing to consider when thinking about whether or 1:39 not to make a component state part of Redux is if the data you're 1:43 storing will be used by another component. 1:46 If the data is specific to only a single component, 1:49 like our stopwatch, then it's safe to keep that value in local state. 1:52 So we're going to focus on just the players aspect of the application. 1:56 So now that we've identified that for 2:00 this application we should manage our players array using Redux. 2:02 The next step is to identify what types of actions occur related to our players. 2:06 So in Scoreboard.js you'll see that there are three event handlers defined. 2:10 We have onScoreChange which changes a player score, onAddPlayer adds a player 2:15 to the scoreboard and onRemovePlayer removes a player from the scoreboard. 2:21 These represent the unique actions that may be taken that affect our player data. 2:26 So they also represent the type of actions will need to manage within Redux. 2:30 Now that we've identified the actiontypes the next step is to define 2:35 each of the actions explicitly as a string constant. 2:39 So let's create a new folder in the source directory called actiontypes. 2:42 Then in this new folder add a new file called Player.js. 2:51 In the file we'll store and export each action in a constant. 2:56 So we'll start with export const ADD_PLAYER, 3:02 make sure that it's an all caps, 3:08 equals the string, player/ADD_PLAYER. 3:11 Next, I'll go ahead and copy this constant and paste one right below. 3:16 And for this one, we'll say export const REMOVE_PLAYER = 'player/REMOVE_PLAYER'. 3:22 Paste another one right below and for this one we'll say, 3:31 UPDATE_PLAYER_SCORE = 'player/UPDATE_PLAYER_SCORE'. 3:37 All right, so we now have all of the explicit actiontypes defined as strings. 3:44 Now this pattern for 3:49 storing your actiontypes in a separate file is not required but 3:50 is useful for isolating your actiontypes from the rest of your application. 3:54 Plus as your application begins to grow, 3:58 you'll find that it's much easier to define actiontypes separately. 4:00 And for more information about actiontypes, 4:03 take a look at the resources I posted in the teacher's notes. 4:05 Coming up in the next video, we'll use the actiontypes we just created to implement 4:08 how the player data changes in response to an action. 4:12
You need to sign up for Treehouse in order to download course files.Sign up