Effector
By Effector team
Effector is a reactive state manager for JavaScript and TypeScript that models application logic as a graph of events, stores, and effects connected by explicit data-flow declarations, rather than relying on a single global reducer or…
Definition
Effector is a reactive state manager for JavaScript and TypeScript that models application logic as a graph of events, stores, and effects connected by explicit data-flow declarations, rather than relying on a single global reducer or action-dispatch pattern. It emphasizes framework independence and fine-grained reactivity, allowing individual stores to update and trigger UI re-renders selectively, without funneling every change through one centralized dispatch step.
Overview
Effector was designed around the observation that many state-management libraries force all application logic through a single dispatch-and-reducer bottleneck, even when much of an app's state and logic are naturally independent of one another. It instead treats state management as a reactive data-flow graph, where each unit, whether an event, a store, or an effect, declares explicitly how it derives from or feeds into other units. Mechanically, Effector's primitives are events, which represent something that happened and carry a payload; stores, which hold a piece of state and update in response to events or other stores via a reducer function passed to their .on method; and effects, which wrap asynchronous or side-effecting operations like API calls and expose pending, done, and fail events automatically. Units are connected declaratively, for example a store might call .on(fetchUser.done, (state, {result}) => result) to update itself whenever an effect resolves, and derived stores can be created with combine or map to compute new state from existing stores without manual subscription management. Because each store only recomputes when its specific dependencies change, UI bindings built with effector-react only re-render components subscribed to the stores that actually changed, rather than re-evaluating a whole connected tree. Compared to Redux, Effector removes the central reducer switch statement and the requirement to dispatch a single action type through one store; state can be split into many small, independently updating stores connected by explicit wiring, which some teams find scales better for large applications with many semi-independent domains. Compared to MobX, another reactive state library, Effector favors explicit unit declarations and a more functional style over Mobx's observable classes and implicit dependency tracking via property access, which some developers find easier to trace through code. In practice, Effector sees adoption particularly in the Russian and broader Eastern European frontend developer community where it originated, and among teams building complex, long-lived single-page applications that want framework-agnostic business logic that could in principle be reused across React, Vue, or vanilla JavaScript UIs, since Effector's core has no dependency on any view library. The trade-offs of Effector include a smaller global community and job market recognition compared to Redux or Zustand, meaning fewer Stack Overflow answers, third-party integrations, and hiring familiarity, plus a learning curve around its specific vocabulary of units, domains, and effect lifecycle events that does not map directly onto more common patterns. Teams should weigh its genuinely powerful reactive modeling against these ecosystem and onboarding costs before adopting it for a new codebase.
Key Features
- Models state as a graph of events, stores, and effects
- Provides automatic pending, done, and fail events for async effects
- Supports derived stores via combine and map without manual wiring
- Enables fine-grained re-renders limited to changed store subscribers
- Works independently of any specific UI framework
- Offers first-class TypeScript support with strong type inference
- Avoids a single centralized reducer or dispatch bottleneck