Flux and Redux: Understanding the Relationship

A comprehensive guide to understanding how Redux evolves the Flux pattern

Introduction

Redux is an evolution of the concepts introduced by Flux. Having a solid understanding of Flux provides an excellent foundation for mastering Redux. In this tutorial, we'll explore the relationship between these two architectural patterns and see how Redux builds upon and refines the principles established by Flux.

Learning Objectives

By the end of this tutorial, you will be able to:

  • Describe the relationship between Redux and Flux
  • Explain the three core principles that Redux follows
  • Understand the complete Redux data cycle and how it differs from Flux
  • Implement basic Redux patterns in your applications

What is Flux?

Flux is not a library or a framework—it's an architectural pattern developed by Facebook specifically for building client-side web applications. While it was created to complement React, Flux can be used with any view library or framework.

The fundamental concept behind Flux is unidirectional data flow. This means data in your application flows in one direction only, making your application more predictable and easier to reason about than traditional MVC (Model-View-Controller) patterns where data can flow bidirectionally.

Unidirectional Flow Analogy

Think of Flux as a one-way river. Information flows downstream from its source to its destination, never back upstream. This is in contrast to a two-way street where traffic (data) can move in both directions, potentially causing congestion and confusion.

In a Flux application, when you want to update the UI, you don't directly manipulate it. Instead, you send a message (an action) downstream, letting the natural flow of the river carry that message to where it needs to go, eventually resulting in UI updates.

Let's break down the core components of the Flux architecture:

Core Components of Flux

Actions

An action is the starting point of the data flow in Flux. It's a simple JavaScript object that must contain a type property indicating what kind of action is being performed. Actions may also include additional data (called the "payload") necessary for updating the application state.

// Example of a Flux action
{
  type: 'ADD_TODO',
  text: 'Learn Flux architecture'
}

Think of actions as "event tickets" that describe something that happened in your application, such as a user clicking a button, a form submission, or data arriving from an API.

Dispatcher

The dispatcher acts as the central hub of your Flux application. Its job is to distribute (or "dispatch") actions to the store(s). In Flux, the dispatcher is essentially a registry of callbacks into the stores.

When an action is dispatched, all stores receive the action. Each store then decides if and how to respond to that action.

Dispatcher Analogy

Think of the dispatcher as a post office. When you drop off a letter (action), the post office ensures it gets delivered to all the addresses listed (stores). The post office doesn't decide what happens with your letter once it's delivered—it simply ensures delivery.

Store

The store contains the application state and logic. In Flux, you'll typically have multiple stores, each responsible for a different domain of your application. Stores register themselves with the dispatcher to receive actions.

When a store receives an action, it uses the action's type to determine if and how it should update its state. After updating its state, the store emits a "change" event to notify subscribers (typically views) that the state has changed.

// Simplified example of a Flux store
const TodoStore = {
  todos: [],
  
  getAll() {
    return this.todos;
  },
  
  handleAction(action) {
    switch(action.type) {
      case 'ADD_TODO':
        this.todos.push({
          text: action.text,
          completed: false
        });
        this.emitChange();
        break;
      // Handle other action types...
    }
  },
  
  emitChange() {
    // Notify subscribers that the state has changed
  }
};

View

In Flux, the view is responsible for rendering the user interface and capturing user interactions. Views listen to change events emitted by the stores. When a store's state changes, the view re-renders to reflect those changes.

Views can also create and dispatch actions themselves in response to user interactions. For example, when a user clicks a "Add Todo" button, the view might dispatch an ADD_TODO action.

View Analogy

Think of views as digital display boards. They show information based on what data they receive (from stores). They can also feature buttons and input fields (event handlers) that send new information into the system when users interact with them.

The Flux Data Flow

The Flux pattern creates a unidirectional data flow that looks like this:

  1. Action Creation: An action is created, often in response to user interaction or system events like API responses.
  2. Dispatch: The action is sent to the dispatcher.
  3. Store Processing: All stores receive the action from the dispatcher and update their internal state accordingly.
  4. View Updates: Views listening to the stores notice the state change and re-render.

This creates a circular flow: Views trigger actions, which flow through the dispatcher to the stores, which update and notify the views, which might trigger new actions, and so on.

Real-World Example: Todo Application

Let's walk through how Flux works in a simple todo application:

  1. A user types a todo item and clicks "Add".
  2. The view dispatches an ADD_TODO action with the text as payload.
  3. The dispatcher forwards this action to all registered stores.
  4. The TodoStore handles the ADD_TODO action by adding a new todo to its list.
  5. The TodoStore emits a change event.
  6. The TodoList view, which is listening for changes from the TodoStore, gets the updated list of todos and re-renders.

From Flux to Redux

Redux is a library that implements a specific variant of the Flux pattern. Created by Dan Abramov in 2015, Redux simplifies some aspects of Flux while maintaining its core principle of unidirectional data flow.

Redux is distributed as an npm package that provides the infrastructure to implement this pattern in your applications. While it's commonly used with React, Redux can work with any view library.

Key Differences Between Flux and Redux

Feature Flux Redux
Stores Multiple stores Single store
Dispatcher Central dispatcher required No separate dispatcher, store handles dispatch
State handling State can be mutated in stores State is immutable, reducers return new state
Update logic Stored in the stores Separated into reducer functions
Debugging Basic tools Advanced tools (time-travel debugging)

The Three Principles of Redux

Redux is built on three fundamental principles that guide its design and usage:

1. Single Source of Truth

The entire state of your application is stored in a single JavaScript object within a single store. This object is often referred to as the "state tree."

// Example Redux state tree
{
  todos: [
    { id: 1, text: 'Learn Redux', completed: false },
    { id: 2, text: 'Read documentation', completed: true }
  ],
  visibilityFilter: 'SHOW_ALL',
  user: {
    id: 'user123',
    name: 'Jane Doe',
    preferences: {
      theme: 'dark',
      notifications: true
    }
  }
}

Single Source of Truth Analogy

Think of your Redux store as a bank vault. All your application's valuable data is kept in one secure location, rather than being dispersed across multiple safety deposit boxes around town. This centralization makes it easier to track, protect, and manage your assets.

Benefits:

  • Makes state easier to track and debug
  • Simplifies saving and loading app state (persistence)
  • Allows for easier state rehydration between sessions
  • Reduces redundancy and potential inconsistencies

2. State is Read-Only

The only way to change the state in Redux is to dispatch an action—an object describing what happened. This ensures that neither the views nor network callbacks ever write directly to the state.

// Instead of directly changing state:
// state.todos[0].completed = true; ❌ WRONG!

// Dispatch an action to request the change:
store.dispatch({
  type: 'TOGGLE_TODO',
  id: 1
}); // ✅ CORRECT

Read-Only State Analogy

Think of your application state as a museum exhibit. Visitors (components) can view the exhibits but aren't allowed to touch or modify them. If a change is needed, visitors must submit a formal change request (action) to the museum curator (Redux), who carefully reviews and implements the change according to established procedures.

Benefits:

  • Makes state changes predictable and traceable
  • Enables powerful debugging tools
  • Prevents race conditions
  • Forces you to think more carefully about state changes

3. Changes Are Made with Pure Functions

Reducers are pure functions that take the previous state and an action and return the next state. A pure function is one that:

  • Returns the same output for the same input
  • Produces no side effects
  • Does not modify its inputs
// A Redux reducer (pure function)
function todosReducer(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      // Return a new array with the new todo added
      return [
        ...state,
        {
          id: action.id,
          text: action.text,
          completed: false
        }
      ];
      
    case 'TOGGLE_TODO':
      // Return a new array with the updated todo
      return state.map(todo =>
        todo.id === action.id
          ? { ...todo, completed: !todo.completed }
          : todo
      );
      
    default:
      // Return the unchanged state for unhandled actions
      return state;
  }
}

Pure Function Analogy

Think of reducers like pastry chefs. When given ingredients (the current state and an action), they always follow the same recipe to create a new pastry (the new state). They never modify the original ingredients, and they don't cause side effects like changing other dishes or contaminating the kitchen.

Benefits:

  • Makes state changes predictable
  • Enables time-travel debugging
  • Simplifies testing
  • Facilitates server-side rendering
  • Makes hot reloading possible

The Redux Data Flow

While Redux follows the same unidirectional flow concept as Flux, there are subtle differences in how data moves through the system:

  1. Action Creation: An action is created, typically by an action creator function.
  2. Dispatch: The action is dispatched to the Redux store.
  3. Reducer Processing: The store passes the action and current state to the root reducer.
  4. State Update: The root reducer calculates the new state and returns it to the store.
  5. Notification: The store notifies all subscribed components.
  6. View Updates: Subscribed components re-render with the new state.

A Complete Redux Cycle Example

Step 1: Define Action Types

// actionTypes.js
export const ADD_TODO = 'ADD_TODO';
export const TOGGLE_TODO = 'TOGGLE_TODO';

Step 2: Create Action Creators

// actions.js
import { ADD_TODO, TOGGLE_TODO } from './actionTypes';

let nextTodoId = 0;

export const addTodo = text => ({
  type: ADD_TODO,
  id: nextTodoId++,
  text
});

export const toggleTodo = id => ({
  type: TOGGLE_TODO,
  id
});

Step 3: Write Reducers

// reducers.js
import { combineReducers } from 'redux';
import { ADD_TODO, TOGGLE_TODO } from './actionTypes';

const todos = (state = [], action) => {
  switch (action.type) {
    case ADD_TODO:
      return [
        ...state,
        {
          id: action.id,
          text: action.text,
          completed: false
        }
      ];
    case TOGGLE_TODO:
      return state.map(todo =>
        todo.id === action.id
          ? { ...todo, completed: !todo.completed }
          : todo
      );
    default:
      return state;
  }
};

const visibilityFilter = (state = 'SHOW_ALL', action) => {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter;
    default:
      return state;
  }
};

const rootReducer = combineReducers({
  todos,
  visibilityFilter
});

export default rootReducer;

Step 4: Create the Store

// store.js
import { createStore } from 'redux';
import rootReducer from './reducers';

const store = createStore(
  rootReducer,
  window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__()
);

export default store;

Step 5: Connect React Components

// With React-Redux
import React from 'react';
import { connect } from 'react-redux';
import { addTodo } from './actions';

const AddTodo = ({ dispatch }) => {
  let input;

  return (
    <div>
      <form
        onSubmit={e => {
          e.preventDefault();
          if (!input.value.trim()) {
            return;
          }
          dispatch(addTodo(input.value));
          input.value = '';
        }}
      >
        <input ref={node => (input = node)} />
        <button type="submit">Add Todo</button>
      </form>
    </div>
  );
};

export default connect()(AddTodo);

Step 6: Use the Connected Components

// index.js
import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import store from './store';
import App from './components/App';

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

Redux Middleware

Middleware is a powerful feature in Redux that allows you to intercept actions before they reach the reducers. Middleware provides a third-party extension point between dispatching an action and the moment it reaches the reducer.

Middleware Analogy

Think of middleware as checkpoint stations along a highway. Every vehicle (action) traveling on the highway must pass through these checkpoints. At each checkpoint, officials can inspect the vehicle, modify it, replace it, or even stop it from proceeding further. Similarly, Redux middleware can process actions, modify them, dispatch additional actions, or prevent them from reaching the reducers.

Common use cases for middleware include:

Example: Redux Logger Middleware

// A simple logging middleware
const logger = store => next => action => {
  console.log('dispatching', action);
  let result = next(action);
  console.log('next state', store.getState());
  return result;
};

// Apply middleware when creating the store
import { createStore, applyMiddleware } from 'redux';
import rootReducer from './reducers';
import logger from './middleware/logger';

const store = createStore(
  rootReducer,
  applyMiddleware(logger)
);

Popular Redux Middleware

Redux Thunk

Redux Thunk is middleware that allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action, or to dispatch only if certain conditions are met.

// Async action using Redux Thunk
const fetchTodos = () => {
  return async (dispatch) => {
    dispatch({ type: 'FETCH_TODOS_REQUEST' });
    
    try {
      const response = await fetch('/api/todos');
      const todos = await response.json();
      dispatch({ 
        type: 'FETCH_TODOS_SUCCESS', 
        payload: todos 
      });
    } catch (error) {
      dispatch({ 
        type: 'FETCH_TODOS_FAILURE', 
        error: error.message 
      });
    }
  };
};

Redux Saga

Redux Saga is middleware that uses JavaScript generators to make asynchronous operations easier to manage and test. Sagas are like background threads in your Redux application that are responsible for handling side effects.

Practical Exercise: Building a Counter with Redux

Let's build a simple counter application to demonstrate Redux principles in action.

Step 1: Project Setup

Create a new folder called redux_counter with the following files:

redux_counter/
├── index.html
└── src/
    ├── index.js
    ├── actions.js
    ├── reducer.js
    └── store.js

Step 2: Define Actions

Create the src/actions.js file:

// Action Types
export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';
export const RESET = 'RESET';

// Action Creators
export const increment = () => ({
  type: INCREMENT
});

export const decrement = () => ({
  type: DECREMENT
});

export const reset = () => ({
  type: RESET
});

Step 3: Create Reducer

Create the src/reducer.js file:

import { INCREMENT, DECREMENT, RESET } from './actions';

const initialState = {
  count: 0
};

const counterReducer = (state = initialState, action) => {
  switch (action.type) {
    case INCREMENT:
      // Return a new state object with count incremented
      return {
        ...state,
        count: state.count + 1
      };
      
    case DECREMENT:
      // Return a new state object with count decremented
      return {
        ...state,
        count: state.count - 1
      };
      
    case RESET:
      // Return a new state object with count reset to 0
      return {
        ...state,
        count: 0
      };
      
    default:
      // Return the unchanged state for unhandled actions
      return state;
  }
};

export default counterReducer;

Step 4: Create Store

Create the src/store.js file:

import { createStore } from 'redux';
import counterReducer from './reducer';

const store = createStore(
  counterReducer,
  window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__()
);

export default store;

Step 5: Create HTML Interface

Create the index.html file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Redux Counter</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            text-align: center;
            margin-top: 50px;
        }
        #counter {
            font-size: 72px;
            margin: 20px;
        }
        button {
            padding: 10px 20px;
            margin: 5px;
            font-size: 16px;
            cursor: pointer;
        }
    </style>
</head>
<body>
    <h1>Redux Counter</h1>
    <div id="counter">0</div>
    <div>
        <button id="increment">Increment</button>
        <button id="decrement">Decrement</button>
        <button id="reset">Reset</button>
    </div>
    
    <script src="https://unpkg.com/redux@4.2.0/dist/redux.min.js"></script>
    <script src="src/index.js" type="module"></script>
</body>
</html>

Step 6: Connect Redux to the UI

Create the src/index.js file:

import store from './store.js';
import { increment, decrement, reset } from './actions.js';

// DOM elements
const counterDisplay = document.getElementById('counter');
const incrementBtn = document.getElementById('increment');
const decrementBtn = document.getElementById('decrement');
const resetBtn = document.getElementById('reset');

// Update the UI when the state changes
function render() {
  const state = store.getState();
  counterDisplay.textContent = state.count;
}

// Subscribe to store updates
store.subscribe(render);

// Initial render
render();

// Wire up the buttons
incrementBtn.addEventListener('click', () => {
  store.dispatch(increment());
});

decrementBtn.addEventListener('click', () => {
  store.dispatch(decrement());
});

resetBtn.addEventListener('click', () => {
  store.dispatch(reset());
});

Exercise Challenges

Once you have the basic counter working, try extending it with these challenges:

  1. Add Increment/Decrement by 5: Create new buttons and actions to increment or decrement by 5.
  2. Add a Counter History: Modify your reducer to keep track of all previous count values.
  3. Implement Undo/Redo: Add buttons to go back to the previous state or forward to the next state.
  4. Add Async Increment: Use Redux Thunk to implement a delayed increment (e.g., increment after 1 second).

When to Use Flux vs. Redux

Choosing Between Flux and Redux

Both Flux and Redux are patterns for managing state in front-end applications, but each has its strengths and ideal use cases.

Consider Flux When:

  • You have a simpler application with less complex state management needs
  • You prefer more flexibility in how you structure your stores and state management
  • You're working within the Facebook ecosystem and want to use their official implementation
  • You need multiple independent stores with their own logic and don't want to combine them

Consider Redux When:

  • You want a standardized state management solution with a large ecosystem of tools and extensions
  • You need powerful debugging capabilities like time-travel debugging
  • Your application has complex state interactions that benefit from a single source of truth
  • You want predictable state updates enforced by pure functions
  • You need middleware for handling side effects like API calls
  • You require a smaller bundle size (Redux is more lightweight than most Flux implementations)

Real-World Decision Making

Let's consider a few application types and which pattern might be more suitable:

Application Type Recommendation Reasoning
Simple personal blog Neither / React Context State is minimal and localized; a simpler solution like Context is sufficient
E-commerce site Redux Complex state for cart, user preferences, product filtering; benefits from a single source of truth
Dashboard application Redux Multiple widgets sharing data; time-travel debugging helps with complex state changes
Form-heavy application Redux (with Redux Form) Complex form state management benefits from Redux's ecosystem
Real-time chat Redux + middleware Asynchronous operations and complex state updates benefit from Redux middleware

Redux Best Practices

Structure Your State Carefully

One of the most important aspects of using Redux effectively is designing your state structure properly:

  • Keep state normalized: Store data in a flat structure with references between entities, similar to a database
  • Avoid deeply nested state: Flatter state is easier to update immutably
  • Separate UI state from domain data: Domain data represents your business entities; UI state represents the current view state

Good State Structure Example:

// Instead of:
{
  users: [
    {
      id: 1,
      name: 'John',
      posts: [
        { id: 1, title: 'Hello World', content: '...' },
        { id: 2, title: 'Redux is nice', content: '...' }
      ]
    }
  ]
}

// Use:
{
  users: {
    byId: {
      '1': { id: 1, name: 'John', postIds: [1, 2] }
    },
    allIds: [1]
  },
  posts: {
    byId: {
      '1': { id: 1, title: 'Hello World', content: '...', authorId: 1 },
      '2': { id: 2, title: 'Redux is nice', content: '...', authorId: 1 }
    },
    allIds: [1, 2]
  }
}

Use Action Creators

Always use action creators instead of creating action objects directly in your components:

  • Makes your code more maintainable
  • Centralizes the logic for creating actions
  • Makes it easier to track where actions are being dispatched from
// Instead of:
dispatch({
  type: 'ADD_TODO',
  text: inputValue
});

// Use:
const addTodo = (text) => ({
  type: 'ADD_TODO',
  text
});

dispatch(addTodo(inputValue));

Write Pure Reducers

Ensure your reducers remain pure functions:

  • Don't mutate state directly
  • Don't generate random values inside reducers
  • Don't make API calls or trigger side effects
// BAD: Mutating state
const badReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'ADD_TODO':
      state.todos.push({ // Direct mutation! ❌
        id: Date.now(), // Side effect! ❌
        text: action.text,
        completed: false
      });
      return state;
    // ...
  }
};

// GOOD: Creating new state
const goodReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        todos: [
          ...state.todos,
          {
            id: action.id, // ID generated outside the reducer
            text: action.text,
            completed: false
          }
        ]
      };
    // ...
  }
};

Use Selectors for Accessing State

Create selector functions to access data from your store:

  • Encapsulates the state shape
  • Makes it easier to change the state structure later
  • Can optimize performance with memoization (e.g., using the Reselect library)
// selectors.js
export const getTodos = state => state.todos;
export const getVisibleTodos = state => {
  const todos = getTodos(state);
  const filter = state.visibilityFilter;
  
  switch (filter) {
    case 'SHOW_COMPLETED':
      return todos.filter(todo => todo.completed);
    case 'SHOW_ACTIVE':
      return todos.filter(todo => !todo.completed);
    default:
      return todos;
  }
};

// In your component:
import { getVisibleTodos } from '../selectors';

// With React-Redux hooks
const visibleTodos = useSelector(getVisibleTodos);

Consider Using Redux Toolkit

Redux Toolkit is the official, opinionated toolset for efficient Redux development:

  • Reduces boilerplate code
  • Includes useful utilities like createSlice
  • Sets up Redux DevTools automatically
  • Includes Redux Thunk for handling async logic
  • Uses Immer under the hood to let you write simpler immutable updates
// With Redux Toolkit
import { createSlice, configureStore } from '@reduxjs/toolkit';

const todosSlice = createSlice({
  name: 'todos',
  initialState: [],
  reducers: {
    addTodo: (state, action) => {
      // Can write "mutating" logic that becomes immutable updates
      state.push({
        id: Date.now(),
        text: action.payload,
        completed: false
      });
    },
    toggleTodo: (state, action) => {
      const todo = state.find(todo => todo.id === action.payload);
      if (todo) {
        todo.completed = !todo.completed;
      }
    }
  }
});

export const { addTodo, toggleTodo } = todosSlice.actions;

const store = configureStore({
  reducer: {
    todos: todosSlice.reducer
  }
});

Advanced Redux Topics

Handling Asynchronous Operations

Redux itself is synchronous, but real-world applications often need to perform asynchronous operations. There are several approaches to handling this:

1. Redux Thunk

The simplest approach is to use Redux Thunk middleware, which allows action creators to return functions instead of plain objects.

// Using Redux Thunk
import { createAsyncThunk } from '@reduxjs/toolkit';

// With Redux Toolkit's createAsyncThunk
export const fetchTodos = createAsyncThunk(
  'todos/fetchTodos',
  async () => {
    const response = await fetch('/api/todos');
    return response.json();
  }
);

// Traditional thunk
export const fetchTodos = () => {
  return async (dispatch) => {
    dispatch({ type: 'FETCH_TODOS_REQUEST' });
    
    try {
      const response = await fetch('/api/todos');
      const todos = await response.json();
      dispatch({ type: 'FETCH_TODOS_SUCCESS', payload: todos });
    } catch (error) {
      dispatch({ type: 'FETCH_TODOS_FAILURE', error: error.message });
    }
  };
};

2. Redux Saga

Redux Saga uses ES6 generators to make asynchronous flows easier to read, write, and test.

// Using Redux Saga
import { call, put, takeEvery } from 'redux-saga/effects';

// Worker saga
function* fetchTodos() {
  try {
    yield put({ type: 'FETCH_TODOS_REQUEST' });
    const response = yield call(fetch, '/api/todos');
    const todos = yield call([response, 'json']);
    yield put({ type: 'FETCH_TODOS_SUCCESS', payload: todos });
  } catch (error) {
    yield put({ type: 'FETCH_TODOS_FAILURE', error: error.message });
  }
}

// Watcher saga
function* watchFetchTodos() {
  yield takeEvery('FETCH_TODOS', fetchTodos);
}

3. Redux Observable

Redux Observable uses RxJS observables to create "epics" that listen for actions and respond with new actions.

Normalized State Shape

For complex applications, normalizing your state (similar to a database schema) is essential for performance and maintainability:

  • Store entities in objects keyed by their IDs
  • Use separate "tables" for different entity types
  • Use arrays of IDs to represent ordered relationships
// Normalized state example for a blog
{
  // "Tables" for entities
  articles: {
    byId: {
      '1': { id: '1', title: 'Redux Basics', authorId: '1' },
      '2': { id: '2', title: 'Advanced Redux', authorId: '1' },
      '3': { id: '3', title: 'React Patterns', authorId: '2' }
    },
    allIds: ['1', '2', '3']
  },
  
  users: {
    byId: {
      '1': { id: '1', name: 'Jane', articleIds: ['1', '2'] },
      '2': { id: '2', name: 'John', articleIds: ['3'] }
    },
    allIds: ['1', '2']
  },
  
  comments: {
    byId: {
      '1': { id: '1', text: 'Great article!', articleId: '1', authorId: '2' },
      '2': { id: '2', text: 'Thanks!', articleId: '1', authorId: '1' }
    },
    allIds: ['1', '2']
  },
  
  // UI state is separate from entity data
  ui: {
    currentArticleId: '1',
    isLoading: false,
    notification: null
  }
}

Reselect and Memoization

Reselect is a library for creating memoized selectors that only recalculate when their inputs change:

import { createSelector } from 'reselect';

// Simple selectors
const getTodos = state => state.todos;
const getFilter = state => state.visibilityFilter;

// Memoized selector that depends on both todos and filter
export const getVisibleTodos = createSelector(
  [getTodos, getFilter],
  (todos, filter) => {
    // This calculation only happens if todos or filter changes
    switch (filter) {
      case 'SHOW_COMPLETED':
        return todos.filter(todo => todo.completed);
      case 'SHOW_ACTIVE':
        return todos.filter(todo => !todo.completed);
      default:
        return todos;
    }
  }
);

Benefits of using Reselect:

  • Improves performance by avoiding unnecessary recalculations
  • Makes it easy to compose selectors
  • Makes your Redux code more modular and testable

Real-World Redux Examples

E-commerce Platform

For an e-commerce application, Redux can manage:

  • Shopping cart contents and calculations
  • User authentication and profiles
  • Product catalog and filtering
  • Order history and tracking

Sample Redux State Structure:

{
  auth: {
    user: { id: 'user123', name: 'Jane Smith', email: 'jane@example.com' },
    isAuthenticated: true,
    token: 'jwt-token-here'
  },
  products: {
    byId: {
      'prod1': { id: 'prod1', name: 'Headphones', price: 99.99, categoryId: 'cat2' },
      // ... more products
    },
    allIds: ['prod1', 'prod2', 'prod3', ...],
    categories: {
      byId: {
        'cat1': { id: 'cat1', name: 'Electronics', parentId: null },
        // ... more categories
      },
      allIds: ['cat1', 'cat2', ...]
    }
  },
  cart: {
    items: [
      { productId: 'prod1', quantity: 2 },
      // ... more items
    ],
    totals: {
      subtotal: 199.98,
      tax: 16.00,
      shipping: 5.99,
      total: 221.97
    }
  },
  ui: {
    productListView: 'grid',
    filters: {
      priceRange: [0, 200],
      categories: ['cat2']
    },
    loading: {
      products: false,
      cart: false
    }
  }
}

Social Media Application

For a social media platform, Redux might manage:

  • User feed and timeline
  • Messaging and notifications
  • User relationships (friends, followers)
  • Content creation and interaction (posts, comments, likes)

Middleware like Redux Saga would be valuable for handling real-time updates using WebSockets, while thunks could manage standard API requests.

Content Management System (CMS)

For a CMS, Redux could manage:

  • Document editing state with undo/redo history
  • Media library and uploads
  • User permissions and workflows
  • Publishing and scheduling features

The time-travel debugging capability of Redux would be particularly valuable for a CMS with complex editing features.

Conclusion

Understanding the relationship between Flux and Redux is valuable for any front-end developer working with modern web applications. While Flux established the fundamental principle of unidirectional data flow, Redux refined these concepts into a more structured and predictable pattern.

Key Takeaways:

  • Flux introduced unidirectional data flow, making application state more predictable
  • Redux built upon Flux by adding constraints that lead to better maintenance and tooling
  • Redux's three principles (single source of truth, read-only state, pure functions) guide its design
  • The Redux data cycle creates a predictable pattern for state updates
  • Middleware allows for powerful extensions like async operations and logging
  • Both patterns have their place, with Redux being more suitable for complex applications

Whether you choose Flux, Redux, or another state management solution depends on your specific project needs. The important thing is to understand the principles behind these patterns and how they can help you build more maintainable and predictable applications.

"The value of Redux is not that it gives you a solution, but that it gives you a set of constraints within which you find your own solution." — Dan Abramov, Redux creator

Further Resources