DEV Community: SDuX Vault

Angular Tutorial Chapter 2 — Display Character State

SDuX Vault — Thu, 10 Sep 2026 22:42:07 +0000

The second chapter of the SDuX Angular tutorial turns a blank application into a focused character detail view. You define typed Feature State, place the FeatureCell™ behind an Angular service, and let the component render a reactive value without owning the state-management setup.

That boundary is the real lesson. A detail screen may begin with one value, but it will often grow to include selection, editing, loading, validation, and recovery. Chapter 2 gives those future requirements a clear home before they become component responsibilities by accident.

Key takeaway: Angular owns the application and dependency-injection structure; the feature service owns committed Feature State access; and the component stays focused on deriving and displaying the value its template needs.

What the SDuX Angular Tutorial Builds

The tutorial follows one feature as it grows instead of presenting isolated API samples. It starts with a standalone Angular project, establishes the application runtime, defines a character contract, registers the feature, connects it to a service, and finishes the first read path in the UI.

Chapter 2 is the first complete checkpoint in that progression. The example uses a Star Wars character collection, but the architecture applies equally well to a profile, product, selected record, or other detail view. The domain changes; the ownership boundary does not.

Part	Responsibility
State contract	Defines the typed fields a character feature owns.
Application setup	Creates the Angular application and registers the runtime.
Feature registration	Associates the service, key, and initial collection.
Service boundary	Exposes reactive State without exposing setup mechanics to the view.
Component and template	Derives one character and renders display-ready values.

Each part is small enough to understand on its own, but the useful result comes from seeing how they connect. The tutorial teaches a repeatable feature shape rather than a screen-specific trick.

Chapter 2's First Read Path

The chapter begins by defining the character data as a TypeScript contract. The raw shape includes an identifier, first name, last name, faction, and Force-sensitive status. The completed StarWarsCharacter type can also include display fields such as a full name and a translated Force-sensitive label.

This distinction matters: an interface defines the expected State shape, but it does not create or load a State value. The contract gives the FeatureCell and its consumers the same vocabulary, while the application configuration supplies the initial character collection.

// Defines the raw pre-reducer State contract for a Star Wars character.
export interface RawStarWarsCharacter {
  /** Unique identifier for the character. */
  id: number;

  /** First name of the character. */
  name: string;

  /** Last name of the character. */
  lastName: string;

  /** Faction associated with the character. */
  faction: string;

  /** Indicates whether the character is force-sensitive. */
  isForceSensitive: boolean;
}

Once the contract exists, the rest of the chapter can refer to a known feature shape. TypeScript can identify missing properties and incompatible values during development, before the UI has to discover the problem at runtime.

Why the Angular Service Owns the FeatureCell

Chapter 2 creates the Angular service before connecting it to SDuX Vault. That ordering makes the feature boundary explicit: the service is the home for the character use case, and the integration details are added to that boundary instead of scattered through the component.

Angular's @Injectable continues to do its normal job. The tutorial does not replace Angular service injection. It adds a FeatureCell association, typed access through injectVault, and initialization in the service constructor. The component injects the service, not the FeatureCell configuration.

Ownership rule: Keep committed Feature State and FeatureCell calls in the service. Keep selection, form controls, confirmation prompts, and display-only feedback in the component unless a later requirement makes that data shared Feature State.

Warning: Do not move the feature's collection into the component simply because the component is where the collection is displayed. Display location and State ownership are different responsibilities.

How Angular Dependency Injection and Signals Keep the Component Focused

The Angular advantage in this chapter is not a special replacement for Angular. It is the way the existing Angular application model gives each responsibility a natural location. Application providers configure the runtime, dependency injection supplies the service, and the component receives a small reactive surface to render.

The service exposes the FeatureCell's Signal-based State access. The component then uses a computed Signal to project the first character from the service-owned collection. The template reads that computed value declaratively through Angular bindings; it does not configure the FeatureCell or initialize the runtime.

Angular location	Chapter 2 responsibility
Application configuration	Provides the application-scoped runtime and registers the feature.
Feature service	Owns FeatureCell access, initialization, and the State surface.
Component	Injects the service and derives the character needed by the view.
Template	Renders character fields without calling FeatureCell APIs directly.

This is why the pattern scales beyond the first screen. When the feature later gains editing or selection, the component can own the local interaction while the service remains the boundary for shared domain State.

From Registered State to a Displayed Character

By the end of Chapter 2, the application has a typed character collection, an application-registered FeatureCell, an initialized Angular service, and a component that can display one character. The template renders the full name, first name, last name, identifier, faction, and Force-sensitive value from the service's reactive State.

The result is intentionally modest: there are no selection or edit controls yet. That restraint is useful. You can see the first read path clearly before later chapters add local selection, collection updates, lifecycle behavior, transformations, and optional labs.

Try the checkpoint: Open the Chapter 2 tutorial, compare the service and component boundaries, and confirm that the template reads display-ready character data without configuring the FeatureCell itself.

Deeper Dive

Continue with the Chapter 2 tutorial and use the completed source as a checkpoint for your own Angular feature. Then follow the remaining tutorial chapters as your requirements grow. The goal is not to add every capability at once; it is to keep each responsibility in a boundary you can explain.

SDuX Vault gives the feature a typed, service-owned State source while Angular keeps doing what Angular does well: dependency injection, standalone application composition, Signal-based reactivity, and declarative templates.

Read the complete Angular tutorial to build the feature step by step, or explore the StackBlitz examples to inspect the checkpoint in a live project.

A New Angular Tutorial for Building a Complete Feature with SDuX

SDuX Vault — Wed, 09 Sep 2026 19:25:30 +0000

The new Angular tutorial for SDuX Vault™ is built around a complete feature, not a pile of disconnected API samples. You start with an empty Angular project and finish with a typed FeatureCell™, a service-owned feature boundary, and a character workflow that can read, create, update, delete, filter, sort, and derive display-ready State.

That shape matters because state management becomes difficult at the boundaries between UI code, domain ownership, asynchronous inputs, and operational policy. The tutorial makes those boundaries visible while you build. Each chapter leaves you with a working checkpoint, a live StackBlitz project, and a clear reason to adopt—or skip—the next capability.

Key takeaway: The tutorial teaches a repeatable feature structure. Angular UI events call a feature service; the service owns its FeatureCell; the pipeline resolves and shapes a candidate; and the component reads the committed StateSnapshot.

Why This Tutorial Was Released

A typical quick-start example can show a successful state update in a few lines. It cannot show where the feature should live once the application needs selection, editing, validation, loading, error handling, persistence, or testing. Developers then fill in the missing architecture from memory, and the state boundary slowly moves into whichever component was edited last.

This Angular tutorial takes the opposite route. It keeps one feature in view while the requirements grow. The application is a Star Wars character registry, but the teaching target is the boundary: the service owns Feature State and FeatureCell access, while the component owns local presentation concerns and user interaction.

You do not need previous SDuX experience. The opening chapter explains the setup, the mental model, the expected environment, and the recommended path through the material. It also makes an important distinction early: the complete example demonstrates many capabilities, but a production feature should adopt the smallest set that matches its actual requirements.

From Project Setup to a Working Feature

The core path starts with the application boundary and ends with a useful read-and-write workflow. You define the Feature State, register the FeatureCell, connect it to an Angular service, and keep the component focused on rendering and interaction. The character workflow then grows in deliberate steps:

Chapter focus	What you learn
Display a character	Establish a service-owned FeatureCell and expose committed State to the UI.
Display characters	Add selection without moving the collection or its ownership into the component.
Add/Edit characters	Use `withArrayAppendMergeBehavior` to append a new character or update an existing character while keeping collection updates inside the service-owned boundary.
Delete characters	Use `withArrayByIdMergeBehavior` to remove (add and edit) a character by identifier inside the service-owned boundary.
Lifecycle	Distinguish a persisted null value, a reusable reset, and permanent FeatureCell destruction.
Filters and reducers	Centralize filtering, sorting, labels, and display derivation before the UI renders State.

The result is more useful than a finished screen. You can see why each responsibility belongs where it does, and you can carry that structure into a different feature instead of copying a component that happens to work for one demo.

The Feature Service Is the Teaching Boundary

The tutorial repeatedly returns to one rule: the component should not become the owner of Feature State just because it is the place where State is displayed. The service exposes the component-facing reactive State, while the service also owns the FeatureCell configuration and update methods.

The welcome chapter summarizes the flow like this: Angular UI action, feature service method, FeatureCell request, FeatureCell pipeline execution, committed StateSnapshot, component Signal or Observable, and finally the template. That sequence gives every later chapter a stable place to add behavior without changing the basic ownership model.

import {
  ApplicationConfig,
  provideBrowserGlobalErrorListeners,
  provideZonelessChangeDetection
} from '@angular/core';
import { provideVault } from '@sdux-vault/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideZonelessChangeDetection(),
    provideVault()
  ]
};

This is the tutorial's initial application configuration. Later checkpoints add the FeatureCell provider and the service-owned feature contract without changing the application runtime setup. The code is small; the important lesson is where the setup lives and how it prepares the application boundary for the feature.

Warning: Do not treat every value the UI needs as Feature State. The tutorial keeps selection, form mode, confirmation, and feedback local when they are presentation concerns. Shared domain State stays with the feature service.

Core Chapters First, Optional Labs Second

Chapters 1–7 form the main read, write, lifecycle, transformation, and error-management path. Chapters 8–15 then act as focused labs for requirements that will not belong in every application. That organization helps you learn the complete feature without turning every available capability into a mandatory checklist.

Lab	Use it to explore
Errors	Failure observation and error handling at the feature boundary.
Async input	Promise, Observable, and Angular HTTP Resource inputs through the same feature boundary.
Delay	Timing policy for delayed state transitions when that requirement fits the application.
Encrypt and Persist	Encrypted, tab-scoped session persistence when that requirement fits the application.
State introspection	Observation points for explaining a transition without giving diagnostics authority over State.
Tab Sync	Same-origin coordination across browser tabs.
Distinct Until Changed	Deliberate suppression of semantically redundant candidates.
Stepwise	Explicit human or policy decisions at a pipeline boundary, treated as a comparison lab rather than a default.

Each lab explains its boundary and its trade-offs. For example, Tab Sync coordinates finalized Feature State across same-origin browser tabs; it does not turn every form interaction into shared collaboration. Encrypted persistence protects values at the persistence boundary, but the tutorial still asks you to consider whether the data and threat model justify storing it locally.

Checkpoints Make the Tutorial Recoverable

Long tutorials fail when one missed import or one divergent file leaves the reader guessing what changed. This tutorial addresses that problem with chapter checkpoints. You can continue in one Angular project, or start a later chapter from the completed source of the preceding chapter.

Each chapter also provides a live StackBlitz project and a downloadable archive. Use the complete-file tabs to compare your checkpoint, inspect the action list to see what is new, and run the finished example when your local project has drifted. The result is a practical feedback loop: build, compare, understand, and then continue.

Key takeaway: Choose your route. Start at the beginning if you want the ownership model built from first principles. Start from a checkpoint when you already understand the core path and need to investigate one optional capability.

Deeper Dive

Open the Angular tutorial to build the feature step by step. Use the chapter labs to test a specific requirement, but keep the central boundary in view: the component renders and interacts, the feature service owns State, and the FeatureCell pipeline keeps the transition path explicit.

If you are evaluating SDuX Vault for an existing Angular application, the tutorial is also a useful architecture review. Compare its service boundary with your current feature, identify which concerns are mixed into the UI, and adopt only the chapters that address a real need.

Watch It

Pipeline Overview: https://www.youtube.com/watch?v=m7ClyWSh754

SDUX vs Redux O(n) Comparison: https://www.youtube.com/watch?v=aFTiIvR0H4M

Array State Updates Without Manual Find-and-Replace Logic

SDuX Vault — Tue, 18 Aug 2026 13:40:28 +0000

Entity arrays invite the same repeated work in every feature: find the existing
record, replace it if its identifier matches, append it if it does not, and
write a separate deletion path. The code is familiar, but its meaning can drift
as each feature grows its own version of those rules.

Array By ID Merge, added in the @sdux-vault/addons 1.1.0 release, makes those
rules explicit for a SDuX™ FeatureCell™. It is a
Merge Behavior that combines array state by an identifier property during the
Merge Stage. An incoming matching identifier updates an entity in place, a new
identifier appends an entity, and a delete update removes matching entities.

The array remains ordinary application state. You choose the identifier once;
the behavior applies the same rule to every merge-style update.

Key takeaway: Array By ID Merge gives a FeatureCell one clear policy for
entity-array updates instead of requiring every caller to reproduce lookup,
replacement, append, and deletion logic.

The Cost of Repeating Collection Rules

Most collection updates start simple. A product feature receives an employee,
looks for an id, maps over the existing array if one is found, and appends
otherwise. A later delete path filters by the same identifier.

That approach makes the update rule an implementation detail of each caller.
One caller can accidentally append a duplicate. Another can handle replacement
but omit deletion. The feature still has an array, but it no longer has one
shared definition of how that array changes.

Array By ID Merge puts that definition in the Merge Behavior registered with a
FeatureCell. The Merge Stage combines the current state with the incoming,
resolved value, returning the merged value to the remaining pipeline stages.

Configure the Identifier Once

Register the behavior, then set the property that identifies each entity before
the FeatureCell is initialized. The Angular and core examples below use id.

Angular Example

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideVault({ logLevel: 'off' }),

    provideFeatureCell(
      EmployeeService,
      {
        key: 'employees',
        initialState: []
      },
      [
        // Explicitly attach the Array By ID merge behavior
        withArrayByIdMergeBehavior
      ]
    )
  ]
};

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

  constructor() {
    this.vault.withArrayMergeId({ idKey: 'id' }).initialize();
  }
}

Core Example

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

employeeCell.withArrayMergeId({ idKey: 'id' }).initialize();

The idKey is required. Only one Merge Behavior is active for a FeatureCell at
a time, so adding Array By ID Merge establishes the collection rule for that
cell.

Update Existing Entities and Append New Ones

Once configured, you make a normal merge-style update. When an incoming entity
has an identifier that already appears in the current array, it replaces that
entity while preserving its position. When the identifier is new, it is
appended.

Angular Example

this.vault.mergeState({
  value: { id: 1, name: 'Grace Hopper' }
});

Core Example

employeeCell.mergeState({
  value: [
    { id: 1, name: 'Grace Hopper' },
    { id: 3, name: 'Katherine Johnson' }
  ]
});

The same update can contain one entity that replaces an existing value and one
that appends. There is no separate branch in the caller for each outcome.

Incoming value	Result
Entity with an existing identifier	Updates the matching entity in its current position.
Entity with a new identifier	Appends the incoming entity.
Array of entities	Applies the same identifier rule to each incoming entity.

Delete by Identifier

Deletion uses the same identifier configuration. Supply an entity containing
the identifier to remove and pass isDelete: true with the merge-style update.
You do not need to supply the complete entity value.

Angular Example

this.vault.mergeState({ value: { id: 2 } }, { isDelete: true });

Core Example

employeeCell.mergeState(
  {
    value: [{ id: 1 }, { id: 2 }]
  },
  { isDelete: true }
);

The first example removes the entity whose id is 2. The second removes each
matching entity named in the incoming array. The update still describes the
state change directly; the behavior supplies the collection mechanics.

Make Undefined Updates Deliberate

An incoming undefined value has a separate decision: preserve the current
state or clear it. The clearUndefined merge configuration controls that
choice for an individual merge-style update. It does not change the configured
identifier property.

This distinction matters because an absent value is not automatically a delete.
Deletion is explicit through isDelete, while clearUndefined controls the
meaning of an undefined incoming value.

Deeper Dive

Read the Array By ID Merge documentation
for the complete configuration and examples. The ArrayByIdMergeOptions reference
documents the required idKey option.

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.