The path to Influitive’s Front End stack — Part 1

In this blog entry, I’d like to talk about how the front end developers at Influitive decided on our front end stack. It was a winding path with plenty of pitfalls and I’m pretty sure we hit all of them in the process so I thought it might help a few people looking to make similar changes.

I actually started at Influitive during the process to switch our front end stack. We had already decided to switch from Rails views + Backbone to React. I won’t go into the details about why we chose React, but the long and short of it was we had never seen UI code so declarative, so understandable.

Everything has state?

In the beginning, every component we built maintained it’s own state. This made sense at the time, allowing us to drop in components wherever they were needed and not worry about the plumbing.

Local state works fine up to a point. Sometimes you want to use the same component but with a slightly different behaviour, and you have to either make it configurable for that exact behaviour or make a new component. After lots of trial and error we decided that maintaining state inside a component should be done sparingly. All state should be passed into components as props or handlers.

Since we decided to give up on (most) local state, we soon found the functional style of component made sense (over the OO classes). This would eventually lead us to solidify us to a bunch of useful libraries:

• ramda — our FP library (map, contains, etc) of choice. It’s like lodash (or underscore) but fully functional.
• recompose —easily wrap components with higher order components that can replace mixins + inheritance without the headache.

Using recompose in particular, we can reuse the same dumb component with different wrappers, adding conditionals without adding a lot more code. If you NEED to introduce state, there is a function for that!

So then where IS the state?

Since we’re trying to avoid local state on our components, we needed state somewhere. Soon after Facebook announced the flux pattern, we attempted to build our own application state manager. It implemented it’s own unidirectional data listeners and supported multiple stores. Unfortunately, it was pretty unwieldy. We tried reflux but we found it wasn’t very composable, nor functional. An interesting library we found was freezer but we decided it allowed too much freedom and within our team it would be too easy to deviate from good practice. Finally, like so many others, we landed upon redux.

Redux provides us with a clear statement of intent for how an action is handled. The middleware support allows for a variety of very tiny but useful utilities (logging, debugging, tracking, etc.)

So redux, the holy grail yes?

If only. Redux is very nice, it’s simple, elegant, and it’s extensible. The one thing that redux is not is succinct. Boilerplate in redux abounds. It helps that the boilerplate is simple but you may need to create three different actions for every async call you have. Don’t get me started on async. So, we needed some help.

• redux-thunk — Basically allows your actions to be functions that call other actions or do async operations.
• redux-act — a tiny library that makes creating actions and associating them with reducers easier.
• redux-saga — a generators based async action handler. Heavier than redux-thunk but useful for long running, complex async operations.

These libraries combined allow us to reduce some of the burden that redux requires. We use redux-act as mostly just syntactic sugar. We try to use thunks over sagas when possible because thunks require less setup. Sagas are a nice to have in case there are external events that you may want to listen to.

So that’s all right?

This post really only covered some basics of our stack, the high level overview. In further entries, I will go into testing practices with the mentioned libraries, our CSS toolchain, and more details on how we handle async and dependent actions.