Working with Redux: Getting used to state
For my final project with Flat Iron School, we were tasked with creating a full stack application using React and RoR (Ruby on Rails). This app would use state management using a state management container. The curriculum with Flat Iron specified that we use Redux, which is quite well integrated with how React works. So, the use of the 2 was fairly simple. However, up until this point, I have not had to build a full stack, client side rendered application and I was doing this with Javascript, which I had only recently got to grips with. Nevertheless, I embarked on this journey knowing that I wanted to focus on delivering something rather than extending my skills. I wanted to practice JS more than anything and also understand React more intimately.
Overall, the project process was slow as there were many moving parts needed to yield a result. The need for the front end to create the request, the back end to handle it, and then the front end to utilise the returned data from the request was a new pattern for me and took some getting used to. Redux was extremely useful as I knew it’d always play its role correctly; handling the information via the Thunk middleware and showing me the action dispatched with the Redux devtools.
The above snippet is from my index.js file from the Cobalt Table Manager project. Here’s the link if you want to take a look. I won’t go into huge detail around Redux and how to instantiate app level state, or React, as there are definitely many resources out there that do a far better job than I could do. But, I do want to speak about the composeWithDevTools function. This was instrumental in me being able to complete this project as it allowed me to always visually confirm Redux managing my state for me. As the name implies, the function allows the DevTools to be baked into the store that is created. Then using the Provider component also packaged in react-redux, I was able to make this accessible across my entire app. But, how is it that we access this store when in the app? There are many, many ways to do this and all of them depend on the architecture of your application. I’ll show you end to end how my app does this, so that you don’t end up going down a rabbit hole for no returns.
First, we have to understand one fact about Redux. State is read-only. What does this mean though? The Redux intro from their website says it best:
The only way to change the state is to emit an action, an object
describing what happened.
So, changes to state only happen if there is an object that showcases the change. In Javascript, everything is an object. So, could we submit anything to make changes to state? Yes and no. Let’s take a look a reducer to see why.
The reducer is the cornerstone of what makes Redux work. These functions allow the app to understand what changes are being made. Notice how the different cases in the switch are returning objects? These are what the quote from the Redux website was referring to. These objects show what is going to change in the state once the action is emitted. But how is an action emitted? This is where the murkiness of making changes to state comes in. Theoretically, a change to state could be made without ever hitting the reducer using parts of React. As, all the reducer is doing is interpreting what action is being emitted. It will not stop a call to state using something like setState. As mentioned, I won’t be going into huge detail on React or Redux, but know that by using setState to manipulate app level state is a big no no. Instead, we use something called an action creator function. Let’s take a look at one.
This function is what we will use in our code to emit an action and carry out our state change. There is one key piece of this that is relevant to what we are talking about: the dispatch function. This function is what emits our action and causes our state to change. Most of this action creator is spent working with the API via fetch and using promises to handle the asynchronicity of the HTTP request (thanks to our Thunk middleware allows for while not having the app break). The objects being passed to the dispatch function are to trigger the specific pieces of the switch in our reducer. When these trigger, our state is accessible from this action creator and the state is updated. The Redux DevTools show these actions being emitted and the state difference before and after.
Working with Redux was difficult at first due to the high number of moving pieces (we’ve only looked at making one request to sign a user in), but I can say that out of all the libraries used in the Cobalt Table Manager project, this was by far the easiest to negotiate and implement due to the expansive ecosystem and the complete simplicity of making it work.
If you aren’t sure about using state management in an app you’re building, please take a look at the three principles for Redux. I think they will sell you on making use of this tiny, but powerful library.
