Menu

In my last blog post, I created the TaskList app and it worked, despite a couple of bugs. I want to convert it to use the Flux architecture. This architecture is prevalent in the React space and basically says there is one source of truth (the store) for the app. The most well-known flux implementation doesn’t technically implement flux, but it still stays true to the tenets of Flux. It’s called Redux and I’ve written about it for web apps before. Switching my TaskList app to Redux will enable me to switch the whole app over to a cloud-enabled app much more easily later on. Note that you don’t have to implement Redux in order to store the data in the cloud. It just makes it easier.

With that, let’s take a look at what I will need to do.

Create the redux store, reducers and action creators.

Move the main app into a component and wire it up to redux.

Create a new main app that wraps the component in a Redux store.

Three parts and all are fairly straight forward.

Create the Store, Reducers and Action Creators

If you look at the main app, you will note that I have two distinct parts – the modal manager and the list of items. I think I want to leave the modal manager with the main app, so that leaves the list of items in the store. Create a directory application/redux to store everything. Let’s put the store in application/redux/store.js with the following boilerplate code:

I love boilerplate. The Redux team have done a great job of making this stuff simple. Now, on to the action creators. Create a new directory application/redux/actions and edit the file tasks.js within that directory with the following code:

Each case statement is based on the original code I wrote last time. It’s just been placed in a reducer instead. The important fact about the reducer is that you never CHANGE state. You return the new state without adjusting the old one. A reducer is said to be idempotent – you can run the same function with the same state and the same action and it will always producer the same output. This is great for testing. Note that my store imports reducers, and not individual reducers. Basically, Redux only deals with one root reducer (which can be a combination of many reducers), so if you want to deal with more, you need to combine them. Here is application/redux/reducers/index.js that does exactly that:

Again – this is boilerplate. When I am writing my redux implementation, I’m really only writing the reducer and the action creators. Everything else is boilerplate.

Move the Main App into a Component

The React bindings for redux are also a solid library. In essence, any component can get a view of the store by writing two methods (mapStateToProps and mapDispatchToProps) and then call connect to wrap the component in the redux store. To assist with that, I’ve created a new component called application/TaskListApp.js that does this. I’ve removed all the state handling and delegated that to the redux implementation. I’ve highlighted the lines that have changed here:

Wrap Up

It’s amazing how much easier it is to write and understand Redux now. This stage of the project took me less than 30 minutes. It’s easy to see why Redux is the preferred implementation for Flux. However, there are others out there. The one I hear about most often as an alternative is MobX, which gets rid of the reducers – actions mutate state directly. If I were choosing one for a commercial project, then I’d likely try to implement a simple async app with network activity (like this one will be) with each one and decide which is better for my situation. However, for my personal projects, I like the simplicity of Redux.

Next time, I’m going to deal with async actions and hook up my TaskList app to a store in the cloud. Until then, you can find the code for this project on my GitHub Repository.