DEV Community: SDuX Vault

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.