Let's take a moment to go over key Redux concepts and

review some of what we've implemented so far and

what we still have to do with regards to Redux on the scoreboard app.

This will help you understand each of the files we just wrote fit into the broader

Redux pipeline and where Redux fits into our entire application.

At the heart of a Redux application is the application store.

Now I've mentioned the term Redux store a few times in this course.

And the Redux store is the single source of truth for the application state.

This means that all state resides in one place, the store.

Isolating state to one container greatly simplifies how and

when application state is updated.

We're going to create the store in the next stage, and

that store will consist of the player data.

Redux will always maintain a history of the player data in the store whenever

actions like updating score or removing a player are taken within the application.

You learned that an action is an event that occurs in the application

that will result in a change in the underlying state.

In Redux, an action is a JavaScript object that has a type and

additional metadata associated with the action taken.

The type identifies the action and

the metadata of an action is the extra information required to update the store.

As you learned in the previous video,

actions are created in Redux by action creators.

For example, the action creators we wrote were JavaScript functions that generate

actions that change player data.

In order for actions to be interpreted and handled in Redux, a reducer is required.

For instance, in the scoreboard app, we created a reducer for the player data.

We wrote the reducers as a pure function that takes two arguments,

the current state, and the action that's been taken.

Once an action goes through the Redux store, a reducer catches the action,

interprets the incoming action by its type, and produces the new state.

[SOUND] Reducers are a big part of Redux.

They're registered and interact with the Redux store, and it's the composition of

the reducers that becomes the state container for your application.

So again, make sure that your reducers are implemented as pure functions and

that they do not mutate or alter the current state.

Finally, as I mentioned at the end of the previous video, in order for

reducers to receive actions, the actions must be dispatched.

Dispatched actions express an intent to change the state in the store.

This is done using a method called dispatch, and it's important to remember

that invoking an action creator alone is not enough to trigger a change in state.

The action that's created must be dispatched.

You'll learn how to provide a dispatch in the next stage when we connect

the scoreboard container to Redux.

Now that we've had a chance to take a closer look at how our actions and

reducers will fit into our application we need to

implement the remaining Redux elements.

This means creating our Redux store wiring up our scoreboard app to connect to Redux,

and provide relevant properties to all downstream components.

See in the next stage.