Intro to ‘Flux’ Pattern

If you’ve ever built a React application of any decent size, you know just how quickly state management and passing props can get out of hand.

The Flux pattern was designed by Facebook to assist with how data flows through an application, and while Flux itself is now in “maintenance mode”, the alternatives (think Redux, MobX, Pullstate, RxJS, Reflux, Fluxible, and many more), tend to use the same, or very similar architecture. What interested me most, is that you don’t even have to use Redux or it’s alternatives at all to access the convenience of the Flux pattern — React’s Context API and React Hooks now allow the same ability to manage data and control state without passing props down through an entire component hierarchy.

So, what is Flux?

The main concept is that there is a single source of truth, the stores, and they can only be updated by triggering actions, which call a dispatcher, that is subscribed to by the store(s) to watch for changes, and update their own data to reflect.

Once a dispatch is triggered, the store is updated, and the views can re-render based on that change event.

Flux Flow

The key here is that data flows in one direction, and is kept entirely in the stores.

The views may allow for a user to to make an action or a change that will be propagated through the system.

Actions can trigger a dispatcher, which store(s) can subscribe to for updates, and emit a change event that can re-render the view with the new data.

Using this pattern, you can now update state and change views based on the data within the stores, that can be updated by user actions sent to a dispatcher. No more passing “user” down 50 levels, it’s now accessible from any component via the store!

That’s all for today.. I’ll be back soon with more on Flux pattern and the Context API in React.

Cheers!