Redux: Predictable State via a Single Source of Truth

WHY IT EXISTS Redux was created to solve the problem of unpredictable state changes in large applications. When many components can mutate state from many places, tracking down bugs becomes difficult. Redux enforces a strict, one-way data flow, making state management predictable and easier to debug.

THE MENTAL MODEL Think of your app's entire state as a single, immutable object in a central "Store." You can't change it directly. Instead, you dispatch an "Action"—a plain object describing what happened, like 'USER_LOGGED_IN'. A "Reducer" function then takes the current state and the action, and returns a completely new state object reflecting the change. The UI then rebuilds based on this new state.

HOW IT WORKS The data flow is unidirectional: UI dispatches an Action -> Middleware intercepts the Action for side effects -> Reducer calculates the new State -> Store saves the new State -> UI rebuilds from the new State. The core components are the Store (single source of truth), Actions (events describing changes), and Reducers (pure functions that execute changes). The flutter_redux package connects this logic to your Flutter UI with widgets like StoreProvider and StoreConnector.

WHEN TO USE IT Use Redux for large applications where state is shared across many screens or non-adjacent widgets. It's beneficial when you need features like undo/redo, state persistence, or detailed debugging, as the explicit action log enables "time-travel debugging." It excels in apps with complex user flows, like multi-step forms or shopping carts.

WHEN NOT TO USE IT Redux is often overkill for simple apps. If state is local to one widget or only shared between a parent and child, simpler solutions like StatefulWidget or Provider are more appropriate. The boilerplate of defining actions and reducers for every small change can slow down development on smaller projects.

ONE CANONICAL EXAMPLE A shopping cart. A user taps "Add to Cart." The UI dispatches an AddItemAction with the product ID. Middleware might first check stock via an API call. If successful, it passes the action along. The cartReducer receives the current state (the list of items in the cart) and the AddItemAction, then returns a new list containing the added item. The Store updates, and any widget listening to the cart state, like a badge icon, automatically rebuilds.