We took our first step into the world of React back in 2014 when we used it to rebuild and improve the checkout experience on Tictail. Since then we’ve been big fans of it and have embraced it in almost all of our projects — from building our marketplace that renders both on the server and on the client, to progressively replacing the old Backbone stack that runs the dashboard for all of our brand owners.

A common problem that we encountered early with our React apps as they started to grow was finding a good structure for the code that doesn’t (and shouldn’t) reside within our views. Facebook has come out with their own proposed solution to this with an application architecture that they call Flux.

Flux is an application structure that utilizes a unidirectional data flow to govern how updates in your application state should happen.

The views send actions containing its type (usually defined as a constant) and any additional data through a central dispatcher. Various stores containing the application’s data and business logic subscribe to dispatched actions and bind handlers based on the different action type constants that update the stores accordingly. The dispatcher enforces these updates to be made synchronously, and provides methods that help stores make sure updates are performed in the correct order.

A common practice is to have certain controller-views that are allowed to read from the different stores and pass the data down the tree. Whenever a store updates, the controller-view triggers a re-render of itself and all of its children.

Flux’s unidirectional data flow.

So we started thinking in Flux and wrote some of our own utilities to reduce boilerplate and make it easier to work with.

To remove the need for defining and dealing with actions constants, we introduced naming conventions to automatically bind store handlers to actions. We used promises to handle asynchronous tasks that would dispatch multiple actions during their life-cycles. In essence we wrote a lot of utilities to hide the dispatcher from our application code, while still conforming to the Flux structure.

But why spend all this effort on in making the dispatcher seemingly disappear, when we can make it actually disappear?

This, combined with the idea of using Immutable data to describe our state, was the initial idea that eventually spawned the state management library that we today call Tide. The first version was built in June 2015 and we have been using it in production since then, across all of our React apps.