DEV Community: SDuX Vault

Behaviors Are Why the Pipeline Stays Predictable

SDuX Vault — Tue, 04 Aug 2026 22:55:26 +0000

Most state tools describe updates as a blur of callbacks, middleware, and side effects. SDuX™ makes the flow explicit by running each FeatureCell™ through Behaviors: small, stage-bound units with one job and one execution slot. That is why the pipeline stays predictable even as a feature grows.

The key idea is simple: a Behavior is not a loose plugin that can run whenever it wants. It is a focused unit of responsibility that is validated during FeatureCell configuration, placed into the correct stage automatically, and constrained to the data available at that stage.

Key takeaway: Predictability does not come from hoping engineers register logic in the right order. It comes from explicit registration, fixed stage boundaries, and Behaviors that do exactly one thing.

What a Behavior Actually Is

A Behavior is a composable, stage-bound unit of responsibility inside the SDuX pipeline. That definition matters because it rejects a common state-management habit: lumping unrelated concerns into one reducer chain, one middleware stack, or one service that quietly does everything.

Instead, each Behavior carries a clear contract. It has a type that identifies where it belongs, a unique key for diagnostics and tooling, a critical designation for pipeline correctness, a stage-specific context, and callbacks that perform only the work allowed at that point in execution.

That separation keeps the mental model tight. A Behavior can resolve input, filter a candidate, reduce state, observe a committed snapshot, shape an error, or persist output. It does not need to know how every other concern works, and it does not reach across the pipeline to invoke its neighbors directly.

Why Stage Boundaries Matter

Stage boundaries are what stop a pipeline from collapsing into hidden control flow. Behaviors are aware of when they are permitted to run and what they are allowed to operate on. That means a Behavior never has to guess whether it is looking at raw input, candidate state, finalized state, or post-commit output.

This is the practical reason the pipeline stays readable. When every unit is bound to a stage, you can reason locally. A filtering Behavior is about filtering. A persistence Behavior is about persistence. An observational Behavior is about observing what has already been committed. You do not have to infer timing from naming conventions or registration order.

⚠️ Warning: If a state tool lets extension logic overlap concerns freely, predictability becomes a convention. SDuX keeps that from happening by enforcing stage isolation automatically.

Core Behaviors vs Addon Behaviors

Behaviors are split into two groups: core Behaviors and addon Behaviors. That distinction explains how the pipeline can stay stable without becoming rigid.

Category	How It Enters	What It Does
Core	Always present	Provides scheduling, input normalization, default merge behavior, immutable state snapshots, and core error handling.
Addon	Registered explicitly	Adds optional concerns such as filtering, taps, caching, persistence, encryption, and other feature-specific extensions.

The important detail is that addon does not mean ad hoc. Optional Behaviors still execute only inside their declared stage and still respect the same boundaries as the core pipeline. You get extensibility without letting extensions redefine the execution model.

Why Explicit Registration Changes the Design

Behaviors are never implicitly enabled. If a Behavior is not registered, it is not executed. That rule changes architecture in a useful way because it forces pipeline composition to be visible at the boundary where the FeatureCell is defined.

This is also where predictability stops being an abstract promise. During configuration, SDuX validates what you registered and inserts each Behavior into the correct stage. The engineer declares participation; the runtime enforces placement and ordering.

import { FeatureCell, Vault } from '@sdux-vault/react';

Vault({
  logLevel: 'off',
  devMode: false
});

export const counterCell = FeatureCell<number>(
  {
    key: 'counter',
    initialState: 0
  },
  [
    // optional Behaviors can be registered here
  ]
);

counterCell.initialize();

In Angular, the registration boundary is the provideFeatureCell() call. In React, Vue, and Svelte, the same boundary is still explicit: you create the cell, initialize it once, and then let framework components consume the stable reference. The wiring changes by framework, but the predictability rule does not.

How Behaviors Make FeatureCells Composable

Composability is the outcome of all the rules above working together. Because Behaviors share a common contract, they can be combined without knowing about one another. Because they are bound to stages, each one stays inside a narrow responsibility. Because they are registered explicitly, the pipeline stays inspectable.

That is a different design from monolithic configuration. You are not authoring one giant state container and then hoping every new concern cooperates with every old one. You are assembling a FeatureCell from focused units that the runtime can place, validate, and execute predictably.

Key takeaway: Behaviors do not make the pipeline more abstract. They make it more legible. Each registered unit tells you what concern exists, where it runs, and why it belongs there.

If you have ever debugged state logic that felt like a chain of invisible callbacks, this is the architectural shift to notice. Predictability is not a side effect of discipline. In SDuX, predictability is a property of how Behaviors are defined, registered, and isolated.

Deeper Dive

Continue with these references to see how explicit registration turns into a stable runtime contract:

Plain TypeScript, Zero Magic: State Management Without Framework Lock-In

SDuX Vault — Wed, 29 Jul 2026 19:22:18 +0000

Most state libraries are really framework libraries with a state API attached. SDuX Vault™ flips that model. Its core is Plain TypeScript, Zero Magic™, and the framework layers are thin adapters. That means your state architecture is not trapped inside Angular, React, Vue, or Svelte. It stays portable as teams, products, and runtimes change.

Most State Libraries Are Secretly Framework Libraries

State management is supposed to protect business rules from churn, but most libraries tie those rules to a rendering story. NgRx is an Angular story. Pinia is a Vue story. Redux is more portable in theory, but many teams still end up adopting it through framework-specific providers, hooks, selector conventions, effect patterns, and store bootstrapping. The result is the same: change the framework, and your state layer becomes migration work.

That coupling is expensive because state logic usually outlives UI trends. Product teams replatform screens, split applications, introduce server-side orchestration, or move shared logic into tools and background jobs. If the state engine only makes sense inside one framework, the rewrite cost shows up every time the platform moves.

Key takeaway: Framework lock-in rarely starts in your components. It starts when your state model depends on a framework lifecycle, a framework container, or a framework-only runtime assumption.

What Plain TypeScript, Zero Magic Actually Buys You

Plain TypeScript, Zero Magic is not branding language. It is an architectural constraint. SDuX Vault does not depend on reflection, runtime patching, framework lifecycles, or hidden side effects. Its core concepts, including FeatureCells, pipelines, reducers, filters, interceptors, lifecycle signals, and immutable state snapshots, are language-level primitives composed in TypeScript.

Because the runtime is explicit, the guarantees stay stable everywhere the code runs. A cell is still registered explicitly. Initialization is still explicit. The pipeline still executes in a deterministic order. State is still committed as immutable snapshots. Framework adapters improve ergonomics, but they do not rewrite the underlying rules.

Identical state semantics across platforms
Explicit lifecycle control everywhere
No framework lock-in
Predictable behavior in any runtime
Frameworks add ergonomics, not rules

One State Engine Across Angular, React, Vue, and Svelte

The reason portability is real instead of aspirational is simple: the core contract stays the same. Angular uses dependency injection and Signals-friendly helpers. React, Vue, and Svelte consume the same committed snapshots through their own reactive surfaces. The state owner does not change, the pipeline does not change, and the lifecycle rules do not change.

The original post compares the same FeatureCell with framework-specific wiring only:

Angular Registration

// app.config.ts

export const appConfig: ApplicationConfig = {
  providers: [
    provideVault({ logLevel: 'off' }),

    provideFeatureCell(EmployeeService, {
      key: 'employees',
      initialState: []
    })
  ]
};

// employee.service.ts
import { Injectable } from '@angular/core';
import { FeatureCell, injectVault } from '@sdux-vault/angular';

@FeatureCell<Employee[]>('employees')
@Injectable({ providedIn: 'root' })
export class EmployeeService {
  readonly vault = injectVault<Employee[]>(EmployeeService);

  constructor() {
    this.vault.initialize();
  }
}

Core Runtime Registration

// main.ts
import { FeatureCell, Vault } from '@sdux-vault/core';

Vault({ logLevel: 'off' });

// employee.cell.ts
export const employeeCell = FeatureCell({
  key: 'employees',
  initialState: []
});

employeeCell.initialize();

The Angular version adds DI-friendly registration. The plain core version is what powers React, Vue, Svelte, Node.js, Bun, and Vanilla JavaScript integrations. Different wiring, same state semantics.

Redux Knowledge Still Transfers

This is not an argument that everything you learned in Redux was wrong. Pure reducers, immutable state evolution, selectors, and deterministic thinking all transfer directly. The change is where the architecture lives. Redux usually centers the application on a global store and dispatch flow. SDuX Vault centers it on the owning FeatureCell and a deterministic pipeline.

The migration mapping is straightforward: Redux centralizes state through a global store and reducer tree, while SDuX Vault scopes state to independent FeatureCells and executes updates through a deterministic pipeline. Existing reducer logic often transfers cleanly as long as it remains pure and deterministic. Redux and SDuX Vault can also run side by side, so migration does not have to be a rewrite.

Concern	Redux	SDuX Vault
Primary architecture	Global store and dispatch-centric integration	Scoped FeatureCell ownership and direct state intent
Framework relationship	Usually adopted through framework-specific bindings	Thin adapters that do not change runtime rules
Migration path	Concepts transfer, but store wiring often stays central	Can run beside Redux while features migrate cell by cell

Why Runtime-Agnostic State Matters for Teams

Teams rarely live in a single runtime forever. An Angular product team adds a React microsite. A frontend flow needs shared logic in a Node.js worker. A proof of concept becomes a long-lived internal tool. Runtime-agnostic state means the architectural investment can move with those decisions instead of being thrown away by them.

That matters operationally too. Shared state rules become easier to document, review, and test when they are not hidden behind four different framework-specific abstractions. You can teach one mental model, keep one set of guarantees, and let each framework focus on rendering rather than owning correctness.

Key takeaway: The win is not just portability. It is organizational consistency. One runtime-level state model is easier to migrate, easier to review, and easier to share across teams than four separate framework-native patterns.

Framework Ergonomics Without Framework Lock-In

Thin adapters are the right compromise. Angular can use DI and Signals-friendly consumption. React can use hooks. Vue can use the Composition API. Svelte can bind reactive values naturally. None of those conveniences require the core runtime to become framework property.

Platform	Adapter Ergonomics	What Stays Fixed
Angular	DI registration, decorators, injectVault, Signals support	Explicit init, deterministic pipeline, immutable snapshots
React	Hook-based consumption of committed state	FeatureCell ownership, lifecycle rules, pipeline semantics
Vue	Composition-friendly consumption and reactive bindings	Identical state semantics and explicit control
Svelte	Natural fit with fine-grained reactivity	Same runtime guarantees and state correctness model
Node.js and Deno	No UI adapter required	The same core runtime used in browser applications

That is the practical meaning of Plain TypeScript, Zero Magic. The library stays small enough to travel, explicit enough to trust, and stable enough to survive framework churn.

Deeper Dive

Explore the full Supported Languages page, compare the same feature side by side in the framework comparison demos on sdux-vault.com, and review the migration guide to see how Redux concepts transfer directly. If you want runnable examples, the official StackBlitz demos cover Angular, React, Vue, Svelte, Node.js, Bun, and Vanilla JavaScript through the same core runtime.

State Management Without a UI — Running SDuX Vault on Deno

SDuX Vault — Tue, 21 Jul 2026 19:34:09 +0000

"State management" is almost always sold as a UI concern — a store bolted onto a component tree. But a FeatureCell™ is plain TypeScript with no framework dependency, so it runs anywhere a runtime does. This post shows SDuX Vault™ orchestrating deterministic, pipeline-committed state inside Deno with nothing but @sdux-vault/core.

Why State Management Isn't Just a UI Problem

The moment you have a value that changes over time, that multiple operations read and write, and that must stay consistent while async work is in flight, you have a state management problem — whether or not a screen is involved. A CLI that fetches records in batches, a job that hydrates a cache, an edge function that tracks a counter: all of them coordinate mutable state under concurrency.

Most libraries answer that problem only for the browser. They wire their store to a component tree and assume a render loop exists. A FeatureCell makes no such assumption. It is a headless runtime primitive: you create it, you commit to it, and you read confirmed snapshots back — no DOM, no framework, no render cycle required.

A FeatureCell Is Plain TypeScript

A FeatureCell is not a UI widget with state attached. It is a typed state pipeline. On Deno, you import @sdux-vault/core through an npm: specifier, initialize the Vault runtime once, create a cell, and activate it. That is the entire bootstrap — the same runtime you would use inside a browser app.

import { FeatureCell, Vault } from 'npm:@sdux-vault/core';

// Initialize the Vault runtime once, before any cell is created
Vault({ logLevel: 'off', devMode: false });

// A counter cell with a zeroed initial state — no framework bootstrap
const cell = FeatureCell<CounterState>({
  key: 'counter',
  initialState: {
    count: 0,
    label: 'Counter Example',
    lastUpdate: new Date().toISOString()
  }
});

// Explicit activation starts the pipeline
cell.initialize();

Key takeaway: This snippet is the @sdux-vault/core headless runtime — it is identical whether it runs in a browser tab or a Deno process. There is no framework-specific variant because there is no framework involved.

How State Interaction Maps From Redux

If you reach for Redux the instant you hear "shared state," the headless model is a small shift. Redux positions its store as application UI state wired to a component tree. A FeatureCell commits deterministic state through the same pipeline regardless of where it runs — the interaction surface does not change when the UI disappears.

Concern	Redux	SDuX Vault
Where state lives	One global store wired to the component tree	The owning FeatureCell instance — no tree required
Reading state	Selectors project from a global tree	`state` property / `state$` stream on the cell
Updating state	`dispatch` broadcasts an action to every reducer	`mergeState()` / `replaceState()` target the cell directly
Runtime	Assumes a browser render loop	Runs anywhere a JavaScript runtime does

Use Case — Collection Orchestration in a CLI or Script

A script that accumulates records — log lines, imported rows, discovered files — needs append semantics, not replacement. Register withArrayAppendMergeBehavior at cell creation and every mergeState() call concatenates the incoming array onto the committed collection instead of overwriting it. Previous entries are never discarded, only extended.

import { withArrayAppendMergeBehavior } from 'npm:@sdux-vault/addons';
import { FeatureCell, Vault } from 'npm:@sdux-vault/core';

Vault({ logLevel: 'off', devMode: false });

const cell = FeatureCell<Example[]>(
  // FeatureCell descriptor (identity + initial state)
  {
    key: 'examples',
    initialState: [{ id: 66, name: 'Darth', lastName: 'Vader' }]
  },

  // Definition-time behaviors — configure the merge stage of the pipeline
  [withArrayAppendMergeBehavior],

  // Controllers — none used in this example
  []
);

cell.initialize();

// Each merge concatenates, it does not replace
cell.mergeState({ loading: false, value: input, error: null });

The behavior array is a definition-time argument, so the merge rule is fixed for the life of the cell. Your script never has to remember to concatenate manually — the pipeline does it on every write.

Live demo: StackBlitz — deno/array-append-example.

Use Case — Async Data Loading With Derived State in a Job

A background job that loads users from a remote API has two recurring needs: track each entry through its loading lifecycle, and keep a derived total consistent with the committed collection. A reducer registered before initialize() recomputes the derived value after every commit, so there is no manual counting scattered across call sites.

const cell = FeatureCell<UsersState>({
  key: 'users',
  initialState: {
    users: [],
    totalLoaded: 0,
    lastRefresh: new Date().toISOString()
  }
});

// Pure reducer: recompute totalLoaded from the committed collection.
// Runs after every pipeline commit — no manual counting in call sites.
cell
  .reducers([
    (current) => ({
      ...current,
      totalLoaded: current.users.filter((u) => u.status === 'loaded').length
    })
  ])
  .initialize();

Each write commits a loading placeholder first, then the resolved or errored entry — and a failed fetch is isolated to its own entry without disturbing the rest of the collection. Because the reducer runs inside the pipeline, totalLoaded can never drift out of sync with the users array.

Live demo: StackBlitz — deno/promise-example.

Use Case — Deterministic State for Edge Functions and Prototyping

When you need a single value replaced atomically — a counter, a config object, a session record — replaceState() swaps the entire committed value in one write. Readers always see a fully consistent snapshot, never a half-updated object. That determinism makes a FeatureCell a clean fit for edge functions and for prototyping state logic before any UI exists.

cell.replaceState({
  loading: false,
  error: null,
  value: { count, label, lastUpdate: new Date().toISOString() }
});

// Clear the value without destroying the cell or its pipeline
cell.reset();

Live demo: StackBlitz — deno/replace-example.

Honest Limits — These Are Demos, Not Production Servers

The Deno examples are teaching scripts. They prove that the runtime is genuinely headless and that the pipeline behaves the same off the browser — they are not a blueprint for a production service. Each script exits explicitly once its sequence completes, because an open state$ subscription keeps the Deno event loop alive.

Warning: Treat these as proofs of concept. A server that runs long-lived cells needs its own lifecycle management — unsubscribing from state$, deciding cell ownership per request or per process, and handling shutdown. The examples demonstrate the runtime, not deployment architecture.

Deeper Dive

The headless runtime is the same one the framework bindings wrap — so everything you learn writing a Deno script transfers directly to a browser app. Explore the FeatureCell API to see the full interaction surface, or read the migration guide to map your existing Redux store, selectors, and reducers onto a FeatureCell.

Atomic State Commitment — Why Components Never See Partial Updates

SDuX Vault — Tue, 14 Jul 2026 13:19:31 +0000

Atomic State Commitment — Why Components Never See Partial Updates

In Redux, a selector can read intermediate state in the middle of a dispatch, and middleware can dispatch while another dispatch is still running. SDuX Vault removes that entire category of bugs by separating computing the next state from committing it. The pipeline either commits one complete snapshot or changes nothing at all — your components never see torn state. And because there is no global store to funnel through, many FeatureCells can be resolving updates at the same moment while each one stays perfectly atomic on its own.

Redux Angle: Redux routes every update through a single global store and dispatch system, so intermediate state can be visible during dispatch and middleware re-dispatch.

SDuX Vault Angle: SDuX Vault scopes state to isolated FeatureCells and defers commitment to a microtask boundary, guaranteeing atomic snapshots with no partial visibility.

Partial State Visibility in Redux

Redux dispatch is synchronous and eager. When you call dispatch(action), the action travels through middleware and then through the reducer tree, and the store's state is replaced as that work unfolds. This creates two well-known hazards.

First, intermediate visibility. If middleware or a subscriber reads the store while a dispatch is still in flight, it can observe a state that is neither the fully previous value nor the fully next value — a partially updated tree.

Second, re-dispatch during dispatch. Middleware that dispatches a new action while the current one is still being processed interleaves two updates. The ordering of what each subscriber sees becomes dependent on middleware composition and call timing.

Both hazards share a root cause: computing the next state and making it visible are the same operation. There is no boundary between them.

There is a second, quieter cost to the single global store: every dispatch in the entire application funnels through one reducer tree. Atomicity — to whatever degree Redux provides it — is coupled to a single global serialization point. Unrelated slices of state cannot settle independently because they all share the same dispatch channel.

How Atomic Commitment Works

SDuX Vault executes every state update in two distinct phases that are never interleaved: pipeline computation and state commitment. Pipeline computation determines what the next state should be. State commitment determines when and how that result becomes visible to synchronous getters, reactive observers, callbacks, and DevTools.

During computation, the pipeline performs all of its work without mutating state — interceptor evaluation, resolve behavior execution, operator, filter, and reducer processing, error normalization, and the final outcome decision. Only after the pipeline has fully determined a final outcome does SDuX Vault proceed to commit.

Key takeaway: Partial results, intermediate reducer output, and transient values are never observable outside the pipeline. Either the entire snapshot is committed, or no state change is visible at all.

State ownership lives in independent FeatureCells, each with its own isolated state and execution lifecycle. Here is how you create one:

// main.ts
import { Vault } from '@sdux-vault/core';

Vault({ logLevel: 'off' });

// cart.cell.ts
import { FeatureCell } from '@sdux-vault/core';

export const cartCell = FeatureCell({
  key: 'cart',
  initialState: { items: [], total: 0 }
});

cartCell.initialize();

The Microtask Boundary

Once pipeline computation completes, SDuX Vault schedules state commitment on a microtask boundary. Signal updates, state callbacks, DevTools notifications, and controller notifications are all executed inside a queueMicrotask callback.

This boundary guarantees three things:

Guarantee	What it prevents
The current pipeline run completes fully before any observer is notified	Partial snapshot visibility
No observer can trigger a new pipeline run while a commit is in progress	Interleaved updates and re-entrant writes
All observers see the same finalized snapshot	Timing-dependent inconsistencies between subscribers

The result is an atomic snapshot: fully resolved, fully filtered, fully reduced, and fully normalized. Observers never see intermediate states or partially reduced values. This atomicity applies equally to synchronous inputs, promises, observables, and streams.

Atomicity Without a Global Bottleneck

Atomic commitment in SDuX Vault is not enforced by a single global lock. There is no global store, no global dispatch channel, and no shared selector tree that every update must pass through. Instead, each FeatureCell owns its own execution boundary — its own Conductor and queue — and serialization is scoped to that cell alone.

The practical consequence is worth sitting with: a cart cell, a user-profile cell, and a notifications cell can all be resolving updates in the same tick. Each runs its own compute-then-commit cycle and finalizes on its own microtask boundary. None of them waits on the others, and none of them can leak a half-finished value into another. Atomicity is preserved per cell, in parallel, rather than rationed through one global chokepoint.

Key takeaway: Because serialization is scoped to a single FeatureCell, N cells can update concurrently while every cell still commits one complete, atomic snapshot. Independence is the default — not something you coordinate.

Concern	Redux global store	SDuX Vault FeatureCells
Serialization scope	One global dispatch channel	Per-cell — one Conductor queue each
Independent settlement	No — all slices share the reducer tree	Yes — each cell finalizes on its own microtask
Cross-slice interference	Possible via shared dispatch and subscribers	Structurally impossible — no shared state tree

This is why atomicity in SDuX Vault scales with the number of features rather than contending against it. Adding a new FeatureCell adds an independent execution boundary — it never widens a global surface that every other update has to negotiate.

Reentrancy Is Structurally Impossible

Because state commitment is deferred to a microtask, any attempt to trigger a new state update from within a reducer, a state callback, a DevTools hook, or an error handler always occurs after the current commit has completed. There is no window in which a new update can wedge itself into an in-progress one.

This eliminates entire classes of bugs common in Redux-style systems:

Dispatching during reducer execution
Promise resolution interleaving with state writes
Observer-triggered infinite loops

Warning: Because commitment is deferred, reading a FeatureCell's state synchronously on the same tick you triggered an update returns the previous committed snapshot — not the pending one. In tests, use the settlement API to wait for the pipeline before asserting.

it('commits a complete snapshot', async () => {
  // act — trigger a state update
  cartCell.mergeState({ value: mockItems });

  // settle — wait for the pipeline to commit
  await vaultSettled('cart');

  // assert — verify the committed snapshot
  expect(cartCell.state.total).toBe(42);
});

Video

Watch the Pipeline Isolation walkthrough for a visual explanation of how each FeatureCell keeps its execution and state fully isolated: https://www.youtube.com/watch?v=TRlvCmluBcE

Deeper Dive

Atomic commitment is not an incidental optimization — it is a deliberate architectural boundary that separates computation from visibility. Read the Pipeline Execution Guarantees for the full execution contract, and the Redux migration guide to see how your existing reducer and selector knowledge carries directly into SDuX Vault.

No createStore, No combineReducers, No Provider — Setting Up State in 3 Lines

SDuX Vault — Tue, 07 Jul 2026 12:35:16 +0000

Redux setup is a ceremony. You create a store, compose your reducers into a root tree, wrap your app in a Provider, register middleware, and configure enhancers — all before you write a single line of feature logic. SDuX Vault™ replaces that entire ceremony with two function calls and zero root configuration.

Redux Store Ceremony

A typical Redux application requires several files and configuration steps before state management is operational. Here is what a minimal Redux setup looks like for a single feature:

// store.ts
import { createStore, combineReducers, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import { userReducer } from './reducers/userReducer';

const rootReducer = combineReducers({
  users: userReducer,
});

export const store = createStore(
  rootReducer,
  applyMiddleware(thunk)
);

// App.tsx — Provider wrapper required
import { Provider } from 'react-redux';
import { store } from './store';

function App() {
  return (
    <Provider store={store}>
      <UserList />
    </Provider>
  );
}

That is 20+ lines of configuration across multiple files — and it only covers one feature. Add a second feature and you are back in the combineReducers file, composing another slice into the tree. Add middleware and you are threading enhancers through applyMiddleware. Add DevTools and you are composing composeWithDevTools on top.

Every new feature touches the root configuration.

Redux Requirement	What It Does
createStore()	Creates the single global store instance
combineReducers()	Composes feature reducers into a root tree
applyMiddleware()	Registers middleware (thunk, saga, etc.)
Provider	Makes the store available to all components via context
composeWithDevTools()	Enables Redux DevTools integration

⚠️ Warning: Every entry in that table is root-level configuration. Adding a new feature means editing the root reducer composition, possibly the middleware stack, and potentially the Provider hierarchy. Root configuration is a shared dependency — every team touches the same files.

Vault + FeatureCell Setup

SDuX Vault does not have a root store. There is no reducer tree to compose, no middleware to register, and no Provider to wrap. Setup is two function calls:

Initialize the Vault (once, at application startup).
Register a FeatureCell (per feature).

Vault({
  devMode: true,
  logLevel: 'debug'
});

export const employeeCell = FeatureCell({
  key: 'employees',
  initialState: []
});

That is the entire setup. No root reducer. No combineReducers. No Provider wrapper. No middleware composition. The FeatureCell is self-contained — it owns its state, its pipeline configuration, and its execution lifecycle.

Adding a second feature does not require editing any root configuration. You register a second FeatureCell and it operates independently:

Vault({ logLevel: 'debug' });

export const employeeCell = FeatureCell({
  key: 'employees',
  initialState: []
});

export const cartCell = FeatureCell({
  key: 'cart',
  initialState: { items: [], total: 0 }
});

Each FeatureCell is registered independently. They share nothing — no root reducer, no global namespace, no store-level coupling. Adding the tenth feature is exactly as simple as adding the first.

Key takeaway: In SDuX Vault, there is no root configuration ceremony. Each FeatureCell declares its own state, its own behaviors, and its own controllers. The Vault coordinates execution — you do not compose a global tree.

No Provider Required

Redux requires a Provider component at the root of your application to make the store available via React context. Every component that needs state must be a descendant of that Provider.

SDuX Vault has no Provider. FeatureCells are registered at application startup and are globally accessible by direct import (React, Vue, Svelte, Node) or injection (Angular). There is no context hierarchy to manage and no Provider nesting to debug.

Concern	Redux	SDuX Vault
Store creation	createStore() + combineReducers()	Vault() — one call
Feature registration	Add to root reducer tree	FeatureCell() — independent
Middleware	applyMiddleware() composition	Pipeline behaviors — declarative
Provider wrapper	Required at app root	Not needed
Adding a feature	Edit root reducer + store	Register a new FeatureCell
DevTools	composeWithDevTools()	Built-in — zero config

Side-by-Side Coexistence During Migration

Because SDuX Vault does not use a global store, it can run alongside Redux in the same application. You do not need to rewrite your Redux setup to start using FeatureCells. Register a Vault, add a FeatureCell for your next feature, and let the two systems coexist.

Your existing Redux store continues to manage its features. New features use FeatureCells. Over time, features can be migrated one at a time — each migration is isolated and does not affect the Redux store or other FeatureCells.

There is no big-bang migration. No root configuration rewrite. No flag day.

Key takeaway: For a complete mapping of Redux concepts to SDuX Vault equivalents, see the Migration Guide.

Try It Yourself

See the full FeatureCell registration API and configuration options:

Effects Without Middleware — How Pipeline Stages Replace Thunks and Sagas

SDuX Vault — Wed, 01 Jul 2026 14:15:42 +0000

Redux effects are middleware — thunks dispatching thunks, sagas yielding sagas, observables piping into more observables. Every async operation becomes a dispatch chain that resolves at arbitrary times with no ordering guarantee. SDuX Vault™ eliminates middleware entirely. Asynchronous inputs resolve through pipeline stages with serialized execution, deterministic ordering, and atomic state commitment.

The Middleware Problem

Redux was designed around synchronous reducer composition. When applications needed async operations — API calls, WebSocket messages, timer coordination — the core model had no answer. The community responded with middleware: thunks, sagas, and observables.

Each middleware layer intercepts dispatched actions and performs side effects before (or instead of) reaching the reducer. The result is a parallel execution system layered on top of the store:

// A thunk dispatches multiple actions at arbitrary times
function fetchUsers() {
  return async (dispatch) => {
    dispatch({ type: 'FETCH_USERS_START' });

    try {
      const response = await fetch('/api/users');
      const users = await response.json();
      dispatch({ type: 'FETCH_USERS_SUCCESS', payload: users });
    } catch (error) {
      dispatch({ type: 'FETCH_USERS_FAILURE', payload: error });
    }
  };
}

// Dispatch the thunk
dispatch(fetchUsers());

This pattern introduces three separate dispatches for a single logical operation. Each dispatch broadcasts to the entire reducer tree. The timing of the success or failure dispatch depends on network latency — which means ordering relative to other operations is non-deterministic.

// A saga yields effects that resolve at framework-controlled times
function* fetchUsersSaga() {
  yield put({ type: 'FETCH_USERS_START' });

  try {
    const users = yield call(api.fetchUsers);
    yield put({ type: 'FETCH_USERS_SUCCESS', payload: users });
  } catch (error) {
    yield put({ type: 'FETCH_USERS_FAILURE', payload: error });
  }
}

// Root saga watches for trigger actions
function* rootSaga() {
  yield takeLatest('FETCH_USERS_REQUESTED', fetchUsersSaga);
}

Sagas add a generator-based orchestration layer. They listen for actions, perform async work, and dispatch new actions. The complexity compounds: watchers, forks, races, channels — an entire concurrency framework layered on top of a state container.

⚠️ Warning: The fundamental issue is not the middleware libraries themselves. It is that Redux has no built-in model for async state resolution. Middleware exists because the core architecture cannot coordinate asynchronous inputs within its own execution model.

How Async Resolution Works in the SDuX Pipeline

SDuX Vault does not use middleware. Asynchronous input is handled through the Resolve stage — a core pipeline stage that normalizes all incoming inputs into a canonical value before downstream processing begins.

The Resolve stage accepts multiple input forms and resolves them under pipeline coordination:

Input Form	Resolution
Plain state values	Passed through immediately
Deferred factories (functions returning Promises)	Invoked and awaited under pipeline control
Observable-based inputs	Subscribed and resolved within pipeline lifecycle
Structured state envelopes	Unwrapped and normalized
Angular HttpResourceRef (@sdux-vault/angular)	Observed until a concrete value emits, then resolved

Regardless of how the input originates, the Resolve stage guarantees that downstream pipeline stages — operators, filters, reducers — always receive a predictable, normalized upstream value. No stage ever reasons about transport, timing, or source-specific concerns.

Key takeaway: The Resolve stage is a core pipeline stage. It is always present and executes automatically. You do not install or configure it. Every FeatureCell™ includes resolve behavior by default.

Resolve Behaviors vs Thunks

A Redux thunk dispatches new actions at arbitrary times. The store has no knowledge of when those actions will arrive or in what order. Multiple thunks executing concurrently can interleave their dispatches unpredictably.

In SDuX Vault, you submit a deferred factory directly to the owning FeatureCell. The pipeline resolves the async value under its own coordination — serialized through the conductor queue, committed atomically in a microtask boundary.

import { FeatureCell } from '@sdux-vault/core';

const userCell = FeatureCell('users', { value: [] });

// Submit a deferred factory — the pipeline resolves it
userCell.mergeState({
  value: () => fetch('/api/users').then((r) => r.json())
});

Compare the two approaches side by side:

Concern	Redux Thunk	SDuX Resolve
Dispatch count per operation	3+ (start, success, failure)	1 (single mergeState call)
Ordering guarantee	None — resolves at arbitrary times	Serialized through conductor queue
Reentrancy risk	Possible — dispatch during dispatch	Structurally impossible
State commitment	Immediate on each dispatch	Deferred to microtask boundary
Middleware required	Yes — redux-thunk	No — built into the pipeline

The pipeline does not dispatch new actions after resolution. It resolves the input, processes it through operators, filters, and reducers, and commits the final state — all within a single pipeline execution. No secondary dispatch. No intermediate states visible to observers.

Controllers vs Saga Orchestration

Redux Sagas provide orchestration through generators — watching for actions, forking concurrent tasks, racing competing effects. The entire concurrency model lives outside the store in a parallel execution layer.

SDuX Vault provides orchestration through Controllers. Controllers govern execution authority for pipeline attempts — they evaluate whether an update is allowed, denied, or aborted before pipeline computation begins.

Concern	Redux Saga	SDuX Controller
Execution layer	External middleware	Pipeline Policy stage
Coordination model	Generator-based (yield, fork, race)	Policy evaluation before computation
Relationship to state	Dispatches actions that reach reducers	Does not touch data — governs execution authority only
Concurrency handling	Manual (takeLatest, takeEvery, race)	Serialized by conductor queue
Testability	Generator stepping with mocked effects	act → settle → assert with vaultSettled

Controllers do not dispatch, yield, or fork. They declare policy. The pipeline enforces that policy deterministically. This separation means your coordination logic never interleaves with your data transformation logic — they occupy different pipeline layers entirely.

Key takeaway: Controllers operate in the Policy Layer — the first stage of pipeline execution. They evaluate before any data processing occurs. Reducers operate in the Processing Layer, separated by multiple stage boundaries. The two concerns never mix.

The Execution Guarantee

Both thunks and sagas share a fundamental limitation: they dispatch actions at arbitrary times with no guarantee about ordering relative to other concurrent operations. Two thunks resolving simultaneously can interleave their dispatches. Two sagas forked in parallel can commit conflicting state.

SDuX Vault eliminates this entire category of bug through architectural constraints:

Every pipeline attempt is serialized through a FIFO conductor queue — one at a time, deterministic order
Pipeline computation is pure and side-effect free — no state mutation until computation completes
State commitment is deferred to a microtask boundary — observers never see partial results
Reentrancy is structurally impossible — no observer can trigger a new pipeline run while a commit is in progress

These are not conventions you must remember. They are architectural guarantees enforced by the runtime. You cannot accidentally bypass them.

Redux Comparison

Redux handles async through middleware that dispatches new actions at arbitrary times. SDuX Vault resolves async inputs through pipeline-coordinated stages with serialized execution.

Dimension	Redux (Thunk/Saga/Observable)	SDuX
Async model	External middleware layer	Built-in Resolve stage
Coordination	Manual (takeLatest, debounce, race)	Pipeline-managed serialization
Side effect scope	Anywhere in middleware chain	Contained within pipeline lifecycle
Ordering guarantee	None without manual effort	FIFO queue ensures deterministic order
State visibility	Intermediate states visible between dispatches	Only final atomic snapshots are observable
Dependencies	redux-thunk, redux-saga, or redux-observable	None — resolve is a core pipeline stage

Try It Yourself

Explore how SDuX Vault handles async state resolution without middleware:

Introducing the SDuX Vault Pipeline Video'

SDuX Vault — Tue, 30 Jun 2026 16:24:34 +0000

Introducing the SDuX Vault Pipeline Video

Today I'm excited to share something I've wanted to build for a long time — the first SDuX Vault™ video. It walks through the entire deterministic pipeline from end to end, and it marks a real step forward in how we deliver world-class documentation and training for engineers.

Why Video

Written documentation is the backbone of any serious library. But some concepts — especially a 10-stage pipeline that executes atomically — benefit from seeing the flow animated in real time. Video lets you watch state move through each layer and stage without jumping between doc pages.

This is the first of many. The pipeline overview sets the foundation; future videos will dive into individual stages, testing patterns, and real-world integration scenarios.

What the Video Covers

The video walks through the complete SDuX Vault pipeline architecture in under 5 minutes. Here's the breakdown:

Chapter	Description	Timestamp
What is SDuX Vault	High-level introduction to the framework-agnostic state management engine	0:00
Pipeline Definition	What a pipeline is and how it differs from traditional dispatch models	0:39
Pipeline Parts	The core building blocks that compose a pipeline execution	1:18
Pipeline Layers	Conductor, Orchestrator, and FeatureCell definitions — the three execution boundaries	1:35
Pipeline Stages	All 10 stages defined — Resolve through After Tap	2:30
Pipeline is Atomic	How the pipeline guarantees all-or-nothing state commitment	3:24
SDuX Vault Guarantees	The execution guarantees enforced at every pipeline boundary	4:22

Watch It

The video is available now on YouTube:

SDuX Vault Pipeline — How Every State Change Flows Through a Deterministic Pipeline

This is just the beginning. More videos are coming — each one focused on making SDuX engineering knowledge accessible to every developer, regardless of framework.

Explore the Docs

Want to dig deeper into what the video covers? Start with the Pipeline Architecture page or jump straight to the Complete Pipeline Spec.

Global Store Is a Shared Dependency — Why Scoped State Ownership Wins

SDuX Vault — Tue, 23 Jun 2026 22:20:29 +0000

Redux popularized the idea of a single global store — one tree of state, one set of reducers, one source of truth. It works well with one team and ten slices. It breaks down with five teams and fifty. The global store isn't just where your state lives — it's a shared dependency that every feature, every team, and every pull request must coordinate around. SDuX Vault™ eliminates that coordination cost by scoping state to independent FeatureCells™.

The Single Store Assumption

Redux centralizes state through a global store and reducer tree. Every feature adds slices to the same root object. Every selector projects from the same tree. Every action broadcasts to every reducer.

At small scale, this is manageable. One developer understands the full tree. Renames are safe because the blast radius is visible. Selectors compose predictably because nobody else is changing the shape under you.

At team scale, the single store becomes a shared mutable dependency — not in the Redux sense of mutable state, but in the organizational sense. Every team's code touches the same tree. Every refactor requires cross-team awareness. Every selector is one shape change away from a silent regression.

Why Global State Becomes a Liability

The problems are structural, not conceptual. Redux's ideas about immutability, pure functions, and predictable state transitions are sound. What breaks is the organizational model.

Shape coupling: Selectors depend on the global tree structure. When Team A renames a property in their slice, Team B's selector that composes across slices breaks silently.
Action namespace collisions: Two teams define RESET action types. Both reducers respond. Neither team realizes the collision until production.
Middleware interference: Team A adds logging middleware. Team B adds analytics middleware. Both intercept the same actions. Registration order determines behavior — and nobody documents what the correct order is.
Merge conflict magnets: The root reducer file, the root state interface, and the barrel export index are touched by every feature branch. They become the most contested files in the repository.

None of these problems are bugs in Redux. They are consequences of putting every feature's state in one shared structure. The global store doesn't scale with teams — it scales with discipline. And discipline doesn't survive deadline pressure.

Scoped Ownership with FeatureCells

In SDuX Vault, state is owned by independent FeatureCells. Each cell encapsulates its own typed state, its own pipeline, and its own lifecycle boundary. No other cell can read or write another cell's state directly.

import { Vault, FeatureCell } from '@sdux-vault/core';

Vault({ devMode: true, logLevel: 'off' });

// Team A owns cart state
export const cartCell = FeatureCell({
  key: 'cart',
  initialState: { items: [], total: 0 }
});

// Team B owns user profile state
export const userProfileCell = FeatureCell({
  key: 'user-profile',
  initialState: { name: '', preferences: {} }
});

// Team C owns notifications state
export const notificationsCell = FeatureCell({
  key: 'notifications',
  initialState: { items: [], unreadCount: 0 }
});

Three teams. Three cells. Zero shared state. Team A can rename every property in the cart state shape without Team B or Team C knowing or caring. There is no root reducer file. There is no global state interface. There is no barrel export that every branch touches.

Key takeaway: Each FeatureCell is identified by a unique key and may be registered exactly once. No other cell can access its state directly — isolation is enforced by architecture, not by team agreement.

What Changes for Your Team

The organizational impact is immediate. When state ownership is scoped to cells, team boundaries align with state boundaries.

Global Store	FeatureCell Ownership
Every team touches the root state interface	Each team owns only its cell's type
Selector changes require cross-team review	State access is scoped to the owning cell
Action namespace collisions are possible	No actions — updates target the owner directly
Root reducer file is a merge conflict magnet	No root reducer — cells are registered independently
Middleware affects all state	Pipeline behaviors are scoped per cell
Feature removal requires tree surgery	Remove the cell registration — done

This isn't just a technical improvement — it's an organizational one. Teams stop coordinating around shared files. Pull requests shrink because they only touch the code their feature owns. Refactors become safe because the blast radius is bounded by the cell boundary.

Key takeaway: Redux scopes state by convention (slice naming, selector discipline, action prefixing). SDuX Vault scopes state by architecture — the cell boundary is enforced, not agreed upon.

Try It Yourself

Read the full Redux Concepts in SDuX Vault page for a section-by-section mapping of State, Actions, Dispatch, Reducers, Effects, Selectors, and Testing. Explore the FeatureCell API documentation to see the full registration surface, or jump into a live StackBlitz demo to create your own isolated cells with typed state and scoped ownership.

StateManagement #Redux #alternative

I Built a State Engine Because Redux Broke My Trust

SDuX Vault — Tue, 16 Jun 2026 14:22:15 +0000

I set out to build a state management library — a deterministic pipeline. After years of Redux boilerplate that everyone accepted as normal, action creators you were told to "write once and copy-paste," and reducer sprawl that buried intent under ceremony — I stopped tolerating it and started building something clean. SDuX Vault™ 1.0.0 is the result.

The Breaking Point

There's a moment every developer recognizes — the moment you realize you're spending more time writing boilerplate than solving problems. Action types. Action creators. Reducer switch statements. Selector files. Effect classes. Barrel exports to wire it all together. And the justification was always the same: "You write it once and then copy and paste."

That was never good enough for me. Copy-paste isn't architecture. It's capitulation. Every pasted block is a block nobody reads, nobody questions, and nobody maintains — until it breaks. And when you have hundreds of pasted action-reducer pairs across a codebase, "find the bug" becomes "find the needle in a haystack of identical-looking files."

My standard has always been clean, readable, deterministic code. Code where the intent is obvious from the structure. Code where a new team member can open a file and understand what it does without cross-referencing four other files. Redux's boilerplate was the opposite of that — it buried intent under ceremony and called it a pattern.

I couldn't take the bloat anymore. Not the volume of files, not the ritualistic repetition, and not the industry consensus that this was somehow acceptable. So I stopped patching around it and started building something that didn't need patching.

Key insight: If your state management architecture requires you to copy and paste the same scaffolding for every feature, the architecture is the problem — not your productivity.

What Deterministic Actually Means

The boilerplate problem isn't just about volume — it's about what the volume hides. When you scatter intent across action files, reducer files, effect files, and selector files, you lose the ability to read a feature and understand it. That's the opposite of clean code. Clean code is readable. Readable code is deterministic. Deterministic code tells you exactly what will happen without chasing references across a directory tree.

"Deterministic" gets thrown around a lot. Redux calls itself predictable. NgRx calls itself reactive. But predictable doesn't mean deterministic, and reactive doesn't mean ordered. Predictable means you can guess what might happen. Deterministic means: same input, same pipeline, same result. Every time. Enforced by the architecture, not by your discipline.

That distinction mattered to me because I wanted code I could trust on sight. In SDuX Vault, every state transition flows through a single, ordered execution pipeline. No middleware chain running in whatever order it registered. No action dispatch intercepted by an effect you forgot existed. No selector returning stale data because something changed underneath it.

One pipeline. One direction. One result. You read it, you know it. That's deterministic — and that's what clean code demands.

The Pipeline Is the Contract

Redux's boilerplate exists because the architecture doesn't give you structure — so you build your own, file by file, pattern by pattern, copy by paste. I wanted the opposite: an execution model that is the structure. No scaffolding required. No ceremony to maintain. The pipeline itself is the contract, and the contract eliminates the need for all that boilerplate.

That's why the pipeline isn't a feature of SDuX Vault — it is SDuX Vault. Every state transition flows through nine ordered stages. Each stage has a single responsibility. No stage can skip ahead, run out of order, or silently fail. You don't need action creators to describe intent — the pipeline stage is the intent.

Controllers → Interceptors → Resolve → Merge → Operators → Filters → Reducers → State → Extensions

Controllers govern policy — when, how, and whether execution proceeds. Interceptors guard and transform incoming actions before they reach the pipeline. Operators refine or suppress candidates before resolution. Resolve normalizes incoming input into a resolved candidate value. Merge combines the current committed state with the resolved candidate. Filters gate execution based on conditions. Reducers compute the finalized candidate state. State commits and exposes finalized state snapshots. Extensions handle post-commit work like encryption and persistence.

This isn't a plugin system you bolt together with boilerplate. It's a contract you define once, read plainly, and trust completely. When you open a pipeline definition, you know exactly what will happen, in what order, every time. No cross-referencing. No ceremony. That's what I spent years building toward.

Key takeaway: The pipeline is the contract. The contract is the truth. Every transition explicit. Every output guaranteed. No exceptions.

Nine Stages — One Direction — Zero Ambiguity

Redux gives you a reducer and tells you to figure out the rest. Need async? Write a middleware and its boilerplate. Need validation? Another middleware, another set of files. Need logging? Another one. Every concern adds another layer of copy-pasted scaffolding, and none of it has a guaranteed execution order.

I built SDuX Vault to replace that sprawl with nine explicit stages. No middleware to wire. No action types to declare. Each stage has a defined role:

Stage	Role
Controllers	Policy-driven governance — control when, how, and whether execution proceeds
Interceptors	Guard and transform incoming actions — validate, enrich, or reject at the gate
Resolve	Normalize incoming input into a resolved candidate value
Merge	Combine committed state with the resolved candidate value
Operators	Refine or suppress candidates before resolution
Filters	Conditional execution gates — skip or allow pipeline continuation
Reducers	Compute the finalized candidate state — deterministic with zero side effects
State	Commit and expose finalized state snapshots
Extensions	Post-commit behaviors — encryption, persistence, all acting on committed output

Every stage is composable and opt-in. You don't pay for what you don't use. But when you do use a stage, you know exactly where it sits in the execution order, what it receives, and what it produces. No boilerplate to maintain. No surprises. Just clean, readable definitions.

Why 1.0.0 Now

Why did it take so long to ship 1.0.0? Because I refused to ship until the code was as clean as I demanded it to be — not just the library code, but the code you write when you use it.

Every stage needed to be provably deterministic. Every boundary needed referential isolation — deep-cloned data at every pipeline boundary so no stage can corrupt another's input. Every execution needed an atomic guarantee — either the full pipeline completes and state commits, or nothing changes. No partial updates. No torn state. And critically: no boilerplate tax on the developer.

The testing model needed to be as clean as the pipeline itself: act, settle, assert. No marble diagrams. No fake timers. No flaky async waits. Three steps, readable on sight.

// act → settle → assert
it('updates cart', async () => {
  cartCell.mergeState({ value: mockItems });
  await cartCellSettled(<cart-cell-key>);
  expect(cartCell.state.total).toBe(42);
});

The framework story needed to be real — not "we support React too" as an afterthought, but a pure TypeScript core with first-class bindings for Angular, React, Vue, and Node. One runtime. Every platform. Zero dependencies on any framework.

1.0.0 ships because all of those contracts are now proven. Not promised — proven. Thousands of tests. Real production patterns. A Pipeline Builder that generates type-safe TypeScript from a visual interface. StackBlitz examples you can run without installing anything. And not a single line of copy-paste boilerplate required.

I built SDuX Vault because I believe state management code should be as clean and intentional as the rest of your application. 1.0.0 is the moment it stops being my standard and starts being available as yours.

Ready to see it? Visit sdux-vault.com to explore the architecture, launch the Pipeline Builder, or try a live StackBlitz example — no install required.

Pipeline Anatomy — What Happens When You Update State in SDuX Vault

SDuX Vault — Wed, 10 Jun 2026 13:43:46 +0000

What actually happens when you call replaceState or mergeState in SDuX Vault? The answer is not "the value gets written to a store." The answer is a deterministic, multi-stage pipeline that resolves, filters, reduces, and commits your state change — atomically, every time.

This post walks through that journey step by step.

A State Update's Journey

When you update state in SDuX Vault, your value enters a structured pipeline. The pipeline is not a metaphor — it's a literal, ordered sequence of stages that every state update passes through before it becomes visible to your application.

Here's the path, in order:

Policy (Controllers) — Can this update proceed at all?
Interceptors — Should this update be admitted?
Resolve — Normalize the input into a resolved candidate value.
Merge — Combine the candidate with the current committed state.
Operators — Refine or suppress the merged candidate.
Filters — Further refine or reject the candidate before reduction.
Reducers — Compute the finalized state from the processed value.
Taps — Observe the result (before and after reduction).
Persist / Encrypt — Store the committed snapshot externally.
State Commitment — Emit the final, immutable snapshot.

Every stage is opt-in. A minimal FeatureCell uses only the core stages (resolve, merge, state). When you add a filter behavior, it runs at the filter stage. When you add a persistence behavior, it runs at the persist stage. Nothing runs unless you declare it.

Key takeaway: The pipeline is not a black box. Every stage has a fixed position, a clear responsibility, and explicit opt-in registration.

Behaviors — The Data Path

Behaviors are the composable building blocks that occupy pipeline stages. Each Behavior performs exactly one function: resolving input, filtering values, reducing state, observing snapshots, or persisting output.

Here's what makes Behaviors different from middleware or effects in other state systems:

Stage-bound. A Behavior runs at exactly one pipeline stage. A filter Behavior cannot run during reduction. A persist Behavior cannot intercept input. The pipeline enforces this structurally.
Explicitly registered. A Behavior participates only if you include it in the FeatureCell declaration. If it's not listed, it doesn't execute. There is no implicit behavior discovery.
Composable without coupling. Behaviors don't invoke or coordinate with each other. Each one operates on the inputs provided to its stage and returns a result. The pipeline handles ordering and execution.

There are two categories:

Core Behaviors — Always present. These handle scheduling, input normalization, default merge, and error finalization. You don't register them; they're guaranteed for every FeatureCell.

Addon Behaviors — Optional, engineer-selected. These provide capabilities like filtering, operators, taps, persistence, encryption, and error shaping. You register them explicitly when configuring a FeatureCell.

export const employeeCell = FeatureCell(
  EmployeeCell,
  {
    key: 'employees',
    initialState: []
  },
  [
    // Addon behaviors — each occupies a specific pipeline stage
    withArrayMergeBehavior,
    withDistinctUntilChangedOperator,
    withLocalStoragePersistBehavior
  ]
);

In this declaration, three addon Behaviors extend the pipeline:

withArrayMergeBehavior runs at the merge stage, replacing the default merge strategy with array-aware merging.
withDistinctUntilChangedOperator runs at the operators stage, suppressing duplicate emissions.
withLocalStoragePersistBehavior runs at the persist stage, writing committed snapshots to localStorage.

Each one has a fixed position in the pipeline. You don't think about ordering — SDuX Vault validates and inserts each Behavior into the correct stage automatically.

Controllers — The Policy Path

While Behaviors handle the data path (what happens to the value), Controllers handle the policy path (whether execution proceeds at all).

Controllers are coordinating authorities. They don't transform state. They don't produce values. Instead, they mediate, arbitrate, and finalize control decisions that govern how the pipeline executes.

Think of Controllers as policy enforcement for your state updates:

A throttle controller limits how frequently updates can run.
A max-failures controller halts the pipeline after repeated errors.
A tab-sync controller coordinates state updates across browser tabs.
A stepwise controller manages multi-phase resolution.

Controllers operate across pipeline stages rather than within a single stage. They observe requests emitted by Behaviors, apply centralized decision logic, and issue authoritative outcomes — proceed, deny, buffer, or retry.

export const employeeCell = FeatureCell(
  EmployeeCell,
  {
    key: 'employees',
    initialState: []
  },
  [
    withStepwiseResolveBehavior // Behavior (data path)
  ],
  [
    withStepwiseController // Controller (policy path)
  ]
);

The fourth array in a FeatureCell declaration is the controller array. Like Behaviors, Controllers are explicitly registered. If a Behavior requires a Controller for coordination, both must be declared — SDuX Vault fails fast if a dependency is missing, rather than silently executing with incomplete authority.

Key takeaway: Behaviors define what happens to your data. Controllers define whether and when it happens. This separation keeps control logic centralized and deterministic instead of scattered across middleware.

The Execution Guarantee

This is where SDuX Vault fundamentally differs from other state management systems. The pipeline doesn't just process your update — it guarantees how that processing occurs.

Compute First, Commit Later

SDuX Vault executes state updates in two distinct phases:

Pipeline computation — Determines what the next state should be. All interceptor evaluation, resolve execution, operator/filter/reducer processing, and error normalization happens here. No state is mutated during this phase.
State commitment — Makes the result visible. Signal updates, state callbacks, DevTools notifications, and controller notifications all occur inside a queueMicrotask after computation completes.

These phases are intentionally separated and never interleaved. No mutation, signal emission, or observer notification occurs until pipeline computation has completed successfully. Partial results and intermediate values are never observable outside the pipeline.

Atomic Snapshots

Every successful pipeline execution produces exactly one atomic snapshot. That snapshot is:

Fully resolved
Fully filtered
Fully reduced
Fully normalized
Fully encrypted and persisted (if applicable)

Observers never see intermediate states, partially reduced values, or pre-normalized data. Either the entire snapshot is committed, or no state change is visible at all.

Reentrancy Is Structurally Impossible

Because state commitment is deferred to a microtask, any attempt to trigger a new state update from within a reducer, state callback, or error handler will always occur after the current commit has completed.

This eliminates entire classes of bugs:

Dispatching during reducer execution
Promise resolution interleaving with state writes
Observer-triggered infinite loops

These aren't prevented by convention or lint rules. They're prevented by architecture.

Why This Matters: Before vs. After

Before (Traditional State Management)

In a typical Redux-style system, a state update triggers middleware, reducers, and effects — often in unpredictable order. Side effects fire during reduction. Observers see partial state. Race conditions emerge when async actions resolve out of order.

Debugging means tracing through action dispatches, middleware chains, effect handlers, and selector memoization — with no guarantee that what you see in DevTools represents what actually happened.

After (SDuX Vault Pipeline)

A state update enters the pipeline. It passes through declared stages in deterministic order. Every Behavior has a fixed position. Controllers enforce policy before data processing begins. Computation finishes completely before any observer is notified.

Debugging means looking at one pipeline execution: input in, snapshot out, every stage visible in DevTools with timing and category markers.

The difference isn't incremental. When your state system guarantees atomic, deterministic, reentrant-safe execution by construction, entire categories of bugs simply cannot exist.

Try It Yourself

Open a live StackBlitz demo to see the pipeline in action — trigger state updates and watch each stage execute in real time:

Open a StackBlitz demo →

For the full pipeline stage reference, see the Pipeline Architecture documentation. To understand how Behaviors and Controllers compose, start with What Is a Behavior? and What Is a Controller?.

What Is SDuX Vault? A Pipeline-Based State Engine for Every Framework

SDuX Vault — Tue, 02 Jun 2026 13:42:51 +0000

State management in modern web applications is harder than it should be. Boilerplate, hidden side effects, race conditions, and framework lock-in turn what should be straightforward into a source of ongoing friction. SDuX Vault is a deterministic, reactive state engine built around a streaming pipeline — and it works the same way in Angular, React, Vue, and Svelte.

The Problem With State Management Today

If you've worked on a large frontend application, you've probably felt these pain points:

Too much boilerplate. Actions, reducers, selectors, effects — you write pages of scaffolding before expressing a single line of business logic.
Dispatch indirection. You dispatch an action, then trace through middleware, reducers, and effects to understand what actually happened. Intent gets buried under ceremony.
Global store sprawl. One massive store makes everything coupled. Features can't own their state independently, and refactoring becomes risky.
Framework lock-in. Your state management library only works with one framework. Switch frameworks, rewrite your state layer.

These aren't edge cases — they're the daily reality for teams building production applications. SDuX Vault was created to eliminate them.

What SDuX Vault Actually Is

SDuX Vault is a state management system built around a deterministic, reactive pipeline. Instead of dispatching actions into a reducer, you update state directly through explicit APIs — and that update flows through a structured pipeline of composable stages before being committed.

Think of it as a production line for state changes. Every update enters the pipeline, passes through filtering, reduction, observation, and persistence stages, and exits as a committed, immutable snapshot. Each stage is opt-in, composable, and side-effect-scoped.

Key takeaway: No hidden side effects. Every behavior that participates in the pipeline is declared explicitly. There are no implicit execution paths or magic middleware chains.

The core motivations behind SDuX Vault:

Remove boilerplate — state logic lives where it's used, with minimal ceremony.
Remove dispatch overhead — direct, explicit APIs (replaceState, mergeState) express intent without indirection.
Centralize ownership, not data — each FeatureCell owns exactly one slice of state with a clear lifecycle.
Treat state as a stream — state changes flow through a deterministic pipeline, not isolated mutations.

The Four Core Concepts

SDuX Vault is organized around four stable concepts. This is the entire vocabulary you need to get started:

Concept	What It Does
Vault	System-level configuration surface. Defines runtime defaults used by all FeatureCells (queue behavior, logging, etc.).
FeatureCell	A feature-scoped state container and the primary API surface. Owns one slice of state with explicit initialization, access, and update methods.
State	Immutable, feature-owned data managed by a FeatureCell. Updates are deterministic, ordered transformations — not ad-hoc mutation.
Snapshot	An immutable representation of state at a moment in time. This is what your components consume — always consistent, always up-to-date.

Key takeaway: That's it. Four concepts define the entire public contract surface. Everything else — behaviors, controllers, extensions — builds on top of these without changing them.

One Engine, Every Framework

SDuX Vault is built with standard TypeScript primitives. There are no code generators, no runtime patching, no framework lifecycle dependencies, and no hidden side effects. What you write is what runs.

This means SDuX Vault works consistently across any environment capable of running TypeScript or JavaScript:

Framework	Integration
Angular	Thin adapter — same core, Angular ergonomics
React	Thin adapter — same core, React ergonomics
Vue	Thin adapter — same core, Vue ergonomics
Svelte	Thin adapter — same core, Svelte ergonomics

The guarantees are identical everywhere:

Identical state semantics across all platforms
Explicit lifecycle control everywhere
No framework lock-in
Predictable behavior in any runtime
Frameworks add ergonomics, not rules

Key takeaway: Shared foundation. Rather than fragmenting solutions per framework, SDuX Vault provides a common core that frameworks build on together.

Try It Yourself

The fastest way to see SDuX Vault in action is to open a live demo — no install, no setup. The same pipeline logic runs across all four frameworks:

Open a StackBlitz demo →

Ready to dig deeper? Start with the Getting Started guide, or explore the Core Concepts page for a complete reference.