redux-utilities/flux-standard-action

★ 4,718JavaScriptAudience · developerComplexity · 1/5Setup · easy

Mindmap

mindmap
  root((flux-standard-action))
    Spec fields
      type required
      payload optional
      error flag
      meta optional
    Utilities
      isFSA check
      isError check
    Use cases
      Redux apps
      Flux apps
      Shared tooling
    Audience
      Frontend developers
      Redux users

mindmap root((flux-standard-action)) Spec fields type required payload optional error flag meta optional Utilities isFSA check isError check Use cases Redux apps Flux apps Shared tooling Audience Frontend developers Redux users

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Enforce a shared action format across a Redux codebase so every developer and middleware expects the same object shape.

USE CASE 2

Use the isFSA() utility to validate that actions flowing through middleware are correctly formed before processing them.

USE CASE 3

Represent both success and failure with one action type by toggling the error flag, instead of creating separate action type names.

Tech stack

JavaScriptnpm

Getting it running

Difficulty · easy Time to first run · 5min

In plain English

Flux Standard Action (FSA) is a specification that defines a consistent shape for action objects in JavaScript applications that use Flux or Redux for state management. In those patterns, an "action" is a plain JavaScript object that signals something has happened in the app, like a user submitting a form, and the rest of the system reacts to it. Without a shared convention, different libraries and codebases define these objects in incompatible ways, making it hard to build tools that work across projects. The spec is intentionally minimal. A compliant action must be a plain JavaScript object with a type field that identifies what kind of event occurred. It may optionally have a payload field for the data associated with the event, an error field set to true when the action represents a failure, and a meta field for any extra information that does not belong in the payload. No other fields are allowed. Treating errors as a first-class concept is a core motivation for the spec. Rather than creating separate action types for success and failure cases (like LOAD_SUCCESS and LOAD_FAILURE), FSA allows a single action type to carry an error flag, keeping the action type focused solely on identifying what happened rather than mixing in status information. The repository also ships a small npm package called flux-standard-action with two utility functions: isFSA(action) checks whether a given object conforms to the spec, and isError(action) checks whether an action represents an error. The README lists several compatible libraries, including redux-actions, redux-promise, and redux-rx, which are built to work with FSA-shaped actions.

Copy-paste prompts

Prompt 1

I'm building a Redux app. Show me how to structure a fetch-user action as a Flux Standard Action, including both the success and error cases.

Prompt 2

Using the flux-standard-action package, write a middleware that validates every dispatched action with isFSA() and logs a warning if it fails.

Prompt 3

Refactor these two Redux action creators to conform to the FSA spec: one for login success and one for login failure.

Prompt 4

Explain the difference between putting error info in the payload vs setting the error flag to true in an FSA action.

Open on GitHub → Explain another repo

← redux-utilities on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.