Redux and the State ADT
Adapt Redux Actions/Reducers for Use with the State ADT
By using the State ADT to define how our application state transitions over time, we clear up the need for a some of the boilerplate that we typically need for a solid Redux integration. We can keep our action names and creators in the same file as the reducer they are used in, as we no longer need to have separate files to hand the same action across different portions of our state.
We will build our a single reducer that will handle the integration with Redux and organize our State ADT based reducers in their own files and bring them into our main reducer to handle running our state transitions and the cases where we do not have an transition for a given action.
Instructor: [00:00] We start with this create action helper that we'll use to create simple Flux standard actions. It's defined as a function that takes a string to a function that takes any type A to an action of A, with an action being an object with type and payload keys.
[00:14] We first pass it a type for its action name, followed by a payload for the action, and then combine them into an object to return a simple FSA. To see how we can use this curried interface for making action creators, we'll build a function called silly verb that calls create action, passing to it an action name of, well, silly verb.
[00:35] We now have a function that will return us an FSA with its payload loaded with whatever we pass to it, as we see here by calling it with a string of orange dash square. We happen to already have one implemented called select card that uses this select card action to prime a call to create action.
[00:53] To see this in, dare I say, action, we'll import it into our index file from its location, which will hold all of our reducers at data reducers turn. We see that a quick call to select card down below with the same orange square yields us our expected action.
[01:11] Back in our reducer file, we not only define our action names here. We also pull in our state transitions from our model, like this answer transition that is defined as a function that takes a string to a state app state of unit, giving us a Kleisli by combining these other transactions.
[01:28] We then use these transitions in our reducers, which are currently defined as functions that take a given action of A to either a state app state of unit or a null value.
[01:38] We pluck both type and payload from our action, and then switch on our type, matching our action names to our state transitions. Then return the result of passing in the payload. If none of the actions match this reducer, a null value is returned.
[01:53] Let's pop back over to our index and import our reducer from the default off of our reducer file, and then supply it with a select card action downstairs to get back our expected state instance.
[02:05] To get back our transition state, we'll need to call exec with and supply it with this mock application state which holds a short list of cards, as well as some integers to track the moves the player has left and the moves a player has already taken.
[02:19] When we provide this mock state to exec with, we get back our transition state ready to be given back to Redux. A null value is returned when an action isn't covered, like silly verb falling through our switch case to this default null. We'll start our integration with Redux in our reducers index file by creating this reducer function and importing in our turn reducer.
[02:41] We'll create a shiny new function that we simply call reducer, then bring in our arguments for our previous state and the current action. For now, we'll just return the result of calling turn with our action. Even though this doesn't do much, it does give us something that we can start to work with.
[02:58] We export it from our file and then jump back over to our index, removing the turn reducer we previously brought in, replacing it with this new reducer, which we pull from data reducers.
[03:09] We update our call downstairs, passing our state to the first argument. Getting back a null value for silly verb and calling it with select card gives back a state instance. Hungry for some state, which we feed it by calling exec with, returning our transition state.
[03:25] This call to exec with should really live inside of our main reducer. Let's just pluck it out of here and jump over to our main reducer for a little remodeling. We'll store the result of calling turn in this cleverly named variable, returning the outcome of a ternary that uses the crocks predicate is same type against our result to see if we have a state instance.
[03:46] When we have a state instance, we know it's safe to call exec with and pass it our previous state. If we don't have one, then we just echo this state back. A quick save shows select card applied to our state while silly verb now leaves our state untouched.