How we Redux — Part 1 (Introduction)

For anyone new to React, Flux and other buzzwords, today I wanted to explain how we implement Redux, a certain flavor of Flux architecture, in MeteorJS. Over the past few weeks, the Meteor community has seen a surge of developers replacing the previous view layer, Blaze, which was predominantly “reactive” templating to React, JSX, and all the trinkets the React community has provided.

If you want some insight into Templating vs. JSX, you can read my blog post introducing the change to JSX here.

This blog post will be a series, this post being an introduction to high level concepts of Redux. We’ll start coding in the next chapter.

Enter Redux

If you want some more info on Redux, check this blog post by Dan Abramov here. To summarize it, Redux holds the state of your application in one place and gives you some powerful tools to both interact and reason about this state. The 3 principles of Redux are outlined here.

One thing you’ll notice about Redux immediately is the “single state atom”. This is probably new to current Meteor developers as most of our application state is held either in rogue Session variables or template scoped reactive variables. In Redux, state lives in a central Store with built-in descriptions on how this state changes. These descriptions are called “Reducers”. Reducers are “pure” functions that take some state, an object to describe the state change (action) and returns a new state.

Interacting with your state this way allows your code to be more straightforward and can introduce some really cool concepts like time-travel debugging and reproducible error-reporting.

Check out this diagram below!

Now that you’ve read all about Redux, the first question you may ask yourself is…How do I even use this in Meteor? What happens to Minimongo? What happens to Tracker? Why do I want to use this at all?

Okay so don’t get worried! Everything you like about Meteor remains the same when we use Redux! The overall goal with integrating anything outside the Meteor community is to reach an equillibrium where the libraries can work together. The worst thing we can do for our application is have an implementation that neither is the Meteor way nor the way of the library we’re choosing to integrate. Before we get deep into it, let’s talk about the types of state we have in our Meteor applications.

UI State

A huge misconception in Meteor-Redux implementations is the belief that ALL of your state goes into a Redux store. Let’s distinguish between the 2 types of state we typically find in our Meteor applications.

UI State describes how our front end interface is presented to the user. In Meteor, we use UI state for TONS of things. We use it to conditionally add CSS classes to elements, toggle sections of content, open dialogs, among a few other things. This is exactly what should go into a Redux store when it comes to Meteor applications. Current Meteor applications are probably dealing with this state in several places. You may have layouts utilizing Session variables or reactive vars to achieve the state mutations that fit our liking. The problem with all these methods is we really don’t have any bird’s eye view of the state that governs our application. We don’t know what all the possible states are, nor do we know the possible mutations! This makes debugging hard as well, as when we get into a weird UI states we have to spend some time understanding what piece of code triggered that change. Since Meteor also makes no opinions on folder structure, some Meteor applications have HUGE files and lack of organization. Imagine digging through all this code just for small state changes for debugging!!

Domain State

Let’s talk about Meteor’s bread and butter: Domain State. Domain State is the state that governs the backend of our application. Whether it be via Publications or Meteor Methods, the state we receive from the server is considered Domain State.

Let’s look at two of the seven Meteor principles and how they relate to Domain State:

Data on the Wire: The server sends data and lets the client render it.

Database Everywhere. You can use the same methods to access your database from the client or the server.

Meteor applications are “data-driven”. We have apis to interact with this server data on the client and our domain state is stored in a client side cache called Minimongo. Having this replica set on the client is super powerful as we can achieve optimistic user interfaces way easier! Meteor gives us the tools to achieve synchronity with our domain state via Minimongo, Pub/Sub, and Meteor Methods. We can’t throw that away when a shiny new toy comes around! These are the core ways our applications are built, thus we should keep this state in what we’re used to rather than mix them with our UI State.

What we’re building

So if you haven’t already, take a look at the Redux tutorials here. This tutorial is excellent and authored by Dan Abramov himself. Do this first. What we’ll be building is the Meteor version of the Todo Application built in this video series. You will get a good feel for functional programming and the Redux paradigms.

If you want a sneak preview of the Todo App in Meteor, you can check out this repo I’ve made here. We’ll go step by step throughout the next blog posts to get you a nice little todo app. Yeah Yeah Yeah, todo apps aren’t glamorous, but this will definitely give you a good introduction to Redux and how it can fit in the Meteor world.

Part 2: https://medium.com/@abhiaiyer/how-we-redux-part-2-setup-c6aa726fa79e#.hei1f8qnb