DEV Community: SDuX Vault

Chapter 8 — Observe Pipeline Failures Without Turning UI Feedback into Control

SDuX Vault — Mon, 05 Oct 2026 19:49:41 +0000

Chapter 8 is a lab, not a fresh application. Start with the completed Chapter 7 filters-and-reducers checkpoint, then deliberately make one pipeline filter fail. The exercise shows how a FeatureCell™ can expose a finalized feature error while the UI remains an observer rather than a second source of pipeline authority.

You will keep the Chapter 7 CRUD workflow, pure filter, and ordered reducers. The lab adds one intentional throwing filter, an errors() callback, and a global error response. The point is to watch the same service-owned boundary handle failure, then prove that clearing a message is not the same as removing the cause.

Key takeaway: Use the pipeline to own failure and finalization, use errors() to observe feature-specific output, and use application-level error state for shared visibility. A UI acknowledgement should not pretend that the underlying cause has been repaired.

What Chapter 7 Already Gives You

In Chapter 7, Resolve produces the incoming character collection, Filters removes the teaching record whose last name is unknown, and Reducers derive the display-ready collection. The service registers those rules, while the component consumes the committed State for selection, editing, and rendering.

That completed checkpoint matters because Chapter 8 does not replace the data flow. It places a controlled failure into the existing filter path. Every later create, update, or delete request still enters through the same service methods and reaches the same pipeline. When the teaching flag is enabled, the candidate fails before it can become committed State.

Existing checkpoint	What the lab adds
Service-owned FeatureCell	A controlled failure inside the registered filter path
Pure filter and ordered reducers	A filter that throws only while the teaching flag is armed
Component renders committed State	Component observes global and feature-specific error outputs
Normal CRUD requests	Reset action that disarms the cause without another request

⚠️ Warning: Do not copy the failure pattern into ordinary validation. The lab throws deliberately so the Error stage is visible. Expected invalid form or domain input should use the documented validation or rejection mechanism instead of unexpected exceptions.

Lab Step 1: Arm a Controlled Pipeline Failure

Begin in the Chapter 7 service. Keep the existing removeUnknownLastNameFilter, then add a second inline filter after it. Most of the time this filter returns the candidate unchanged. When the signal-backed teaching flag is enabled, it throws an intentional error.

The component does not construct a special failed request. The service arms the flag and submits a fresh replacement candidate with replaceState(). That fresh identity makes each demonstration attempt observable, while the enabled filter stops the candidate before State commitment.

This is the important lab boundary: the failure is part of the pipeline configuration, not a component-side branch around normal CRUD behavior. Once armed, later create, update, and delete calls continue to enter the same failing filter until you reset it.

Key takeaway: A global banner may tell the user that something failed, but the enabled throwing filter explains why the next candidate will fail too. Observe the cause, not just the symptom.

Lab Step 2: Register an Observational Error Callback

The Chapter 8 service registers an errors() callback alongside the existing filter and reducer registrations. The callback receives the finalized Vault error and the immutable FeatureCell snapshot after error handling has completed. It records those values for the tutorial output; it does not transform the error, replace State, or decide whether the pipeline should continue.

The documented method contract is deliberately small. Use it for observation such as diagnostics, monitoring, logging, or a compatibility bridge. Keep error authority in the pipeline and keep presentation decisions in the component.

employeeCell
  .errors([
    (error, state) => {
      console.error('Employee FeatureCell error:', error.message);
      console.info('Last known state:', state.value);
    }
  ])
  .initialize();

In the lab's Angular service, the equivalent callback stores the error and snapshot in a read-only teaching signal. The component serializes that signal into the Error Emission output so you can inspect what was finalized without giving the template permission to mutate it.

Lab Step 3: Compare Two Error Surfaces

The lab displays two related but separate results. First, VaultErrorService exposes application-level error state. The component subscribes to its global stream and uses it for the visible error banner. That singleton is independent of any one FeatureCell, which makes it suitable for shared application concerns such as monitoring, banners, and recovery guidance.

Second, the service-owned errors() callback emits the finalized error together with the FeatureCell snapshot. That output is specific to this feature and this lab. It is useful for understanding what the pipeline finalized, but it is not a replacement for the application-level error surface.

Surface	Consumer	Responsibility
Finalized FeatureCell error	`errors()` callback	Observe the error and immutable snapshot for feature-specific work
Global Vault error	`VaultErrorService`	Present application-level status or shared operational feedback
User-facing message	Component template	Show an actionable, non-sensitive summary and acknowledgement control

⚠️ Warning: Redact before telemetry. Raw exceptions and State snapshots can contain credentials, personal data, or domain secrets. Render a safe message for the user and define a separate redacted diagnostic payload for operators.

Lab Step 4: Prove That Clear Is Not Recovery

Click Throw Error and observe the global error banner and the serialized Error Emission output. Then try an add, edit, or delete action while the control reads Reset Error. The same pipeline failure should appear again because the filter is still armed.

Now click Clear. The banner disappears, but the cause remains enabled. Trigger another mutation and the failure returns. Clearing the singleton error acknowledges the current message; it does not disable the filter or retry the failed candidate.

Finally, click Reset Error. The service disarms the throwing filter and clears the global error without sending another pipeline request. Later CRUD actions now pass through the original Chapter 7 filter-and-reducer flow and can commit normally again.

Key takeaway: Throw Error, try a CRUD action, Clear, try another CRUD action, Reset Error, then try CRUD again. The sequence separates acknowledgement from recovery in a way a static error banner cannot.

The Chapter 8 Lab Takeaway

Chapter 8 builds directly on the completed Chapter 7 lab checkpoint: the same service-owned FeatureCell, the same character collection, the same filter and reducers, and the same CRUD requests. The new work is a focused experiment in failure observation. You deliberately arm one filter, watch the Error stage finalize the failure, compare feature-level and application-level outputs, and then remove the cause.

The resulting boundary is practical beyond the tutorial. Pipelines should own error authority and finalization. Services should register the feature's observational hooks. Components should present safe feedback and local acknowledgement state. Recovery should change the failing condition or explicitly retry according to a defined policy; dismissing a message alone should not pretend that the underlying operation succeeded.

Save this completed checkpoint before moving to Chapter 9: Async Input. The next lab carries the same error model into asynchronous inputs.

Deeper Dive

Continue with the errors() method reference, Global Error Handler, and the complete Chapter 8 lab.

Chapter 7 — Centralize Filtering and Display Derivation in the Pipeline

SDuX Vault — Tue, 29 Sep 2026 20:12:52 +0000

Filtering, sorting, and display labels often begin as small template decisions. In Chapter 7 of the SDuX Vault tutorial, those rules move into a service-owned pipeline so every consumer receives the same eligible, sorted, display-ready collection.

The component still owns presentation concerns such as selection and editor feedback. The service registers one pure filter and three ordered reducers, then exposes the committed FeatureCell State for the UI to render.

Key takeaway: If multiple views need the same data rule, apply it once in the pipeline instead of recreating it in each template.

Why Cross-View Data Rules Belong in the Pipeline

A template is a convenient place to write a quick condition or concatenate two fields. It is a poor place to establish a rule that several screens must share. Once one view filters incomplete records, another sorts them, and a third translates a boolean into a label, the application no longer has one presentation of its data. It has several local interpretations that can drift.

Chapter 7 draws a clean boundary. Resolve produces the incoming candidate collection. Merge combines the current committed State with the resolved candidate when the update requires it. Filters refine the candidate, and Reducers compute the finalized candidate State. Only the result of that pipeline becomes the value observed by the component.

This ordering makes the intent legible. The filter decides which records are eligible for this feature view. The reducers decide how eligible records are ordered and which display-only fields should be available to every consumer. The template reads the result instead of becoming another data-transformation layer.

Refining Candidates with a Pure Filter

The tutorial uses a deliberately small teaching predicate: remove a character whose last name is exactly unknown. The point is not that every incomplete record should disappear in a production system. The point is that eligibility is explicit, named, and reusable.

The filter receives a candidate collection and returns a new collection. It does not edit the input array, write storage, fetch data, or decide how the component should render the result. Those constraints make the rule easy to test and keep it safe to place in the Filters stage.

// example.filter.ts
import { FilterFunction } from '@sdux-vault/shared';
import type { StarWarsCharacter } from './star-wars-character.shape';

/**
 * Removes characters whose last name is exactly `"unknown"` without mutating the candidate collection.
 * @param characters - Candidate character collection entering the Filter stage.
 * @returns A new collection containing every character with a known last name.
 */
export const removeUnknownLastNameFilter: FilterFunction<
  readonly StarWarsCharacter[]
> = (characters) => characters.filter(({ lastName }) => lastName !== 'unknown');

⚠️ Warning: A teaching predicate is not automatically a domain policy. In a real feature, a filter might encode authorization, active status, or validated eligibility. Preserve the raw data elsewhere when the application must correct or audit incomplete records.

Composing Ordered Reducers Without Mutation

After filtering, Chapter 7 applies three reducers in a deliberate order. The first derives a force-sensitive display label. The second clones and sorts the collection by last name. The third derives a reusable full name. Each reducer owns one rule, and each receives the result of the previous reducer.

The order matters even though the operations are individually simple. A reducer should operate on the already refined candidate, not repeat filtering logic. The sorting reducer should return a reordered copy, not mutate the collection that entered the stage. The full-name reducer can then rely on the stable name fields and add the display value that every view needs.

Stage	Operation	Result
Filters	Remove ineligible candidates	Four retained characters
Reducer 1	Derive force-sensitive display	Each record has a Yes or No label
Reducer 2	Clone and sort by last name	Obi-Wan, Leia, Luke, Darth
Reducer 3	Derive the full name	Every record is display-ready

This composition also gives each transformation a narrow test surface. You can verify that a helper returns a new array, that sorting does not change its input, and that derived fields match the raw values without mounting the Angular component.

Deriving Display Fields Before Rendering

The raw character shape contains name, lastName, and isForceSensitive. The committed tutorial State also contains fullName and forceSensitiveDisplay, both derived by reducers. That distinction keeps domain data and display-ready values visible without forcing every consumer to repeat the same string composition or boolean translation.

Trace the seed collection through the stages. Chewbacca enters with a last name of unknown and is removed by the filter. Leia remains eligible, receives a force-sensitive display value, participates in the last-name sort, and receives Leia Organa as her full name. The final four-record collection is the value committed for the component to display.

What changed in the template? It now reads reducer-derived fields directly. It no longer decides whether a record is eligible, concatenates names, translates booleans, or sorts the collection during rendering.

Keeping the Component Focused on Presentation

Moving transformation rules into the pipeline does not mean the component becomes passive. It still owns presentation state such as the selected identity, editor mode, form values, confirmation state, and feedback. Those values describe what the current view is doing, not what the shared feature collection means.

The service remains the authority for pipeline registration and committed State. The component consumes the service's reactive State and renders it. That ownership boundary prevents a second copy of filtering or sorting logic from appearing in a different view, and it lets a future consumer use the same display-ready fields without knowing how they were derived.

The same principle makes the next tutorial step easier to reason about. Chapter 8 can turn a filter into a controlled failure source while the component continues to observe the resulting State and error information. The pipeline rule remains explicit instead of being hidden inside a template expression.

Verifying the Committed Collection

Run the completed example and verify the result at the boundary the user sees. Chewbacca should be absent. The remaining records should be sorted by last name. Every visible record should contain both derived display fields, while the source views make the filter and reducer functions inspectable.

Then verify the transformation contract independently: filters and reducers return new collections, their inputs remain unchanged, and the registration order matches the intended data flow. Those checks are more valuable than a screenshot because they protect the rule when another view or future update reuses the same FeatureCell.

⚠️ Warning: Do not infer pipeline behavior from an empty view. If a record is missing, inspect the candidate and the registered transformation that could have removed or changed it. Keep the eligibility rule and display derivation named and testable.

Deeper Dive

Work through the Angular Chapter 7 tutorial, then compare the Filters and Reducers documentation. The complete pipeline specification explains how these stages fit into the broader processing flow.

Chapter 6 — Make Feature Lifecycle Intentional with Null, Reset, and Destroy

SDuX Vault — Thu, 24 Sep 2026 14:37:15 +0000

An empty feature is not necessarily an ended feature. In Chapter 6, the Angular tutorial separates intentional null persistence, reusable reset(), and terminal destroy() so your UI can respond to the lifecycle outcome instead of guessing from an empty collection.

The boundary stays consistent with the earlier chapters: the service owns the FeatureCell and every lifecycle API, while the component owns temporary form, selection, confirmation, and feedback state. That separation makes sign-out, account switching, reusable screens, and teardown explicit design decisions.

Key takeaway: Clearing data and ending a feature are different operations. Choose replaceState(null), reset(), or destroy() by the outcome your application needs.

Empty Data Is Not the Same as an Ended Feature

A sign-out flow may clear the current user's data. An account switch may need a clean runtime before loading another account. A screen that is being permanently torn down may need to stop accepting requests altogether. All three can look like an empty screen, but they have different lifecycle meanings.

Inferring lifecycle from an empty array or a missing record makes the UI responsible for a decision that belongs to the feature owner. It also makes later behavior ambiguous: should the next request be accepted, should the feature return to its neutral runtime state, or should the instance be recreated first?

Chapter 6 makes that decision visible with three operations. A committed null is an intentional value. reset() clears the runtime snapshot while leaving the FeatureCell reusable. And destroy() finalizes the active instance.

Persisting Null vs Resetting the Runtime Snapshot

The first two operations both clear what a user sees, but they do not make the same statement about state. The tutorial service sends null through the normal replacement path. That makes the value intentional: the feature is alive, and the application has explicitly committed an empty value.

reset() has a different contract. It does not store a replacement value supplied by the caller. It returns the current runtime snapshot to its neutral state and leaves the FeatureCell available for later work. This is the useful choice when a reusable feature should start over without being destroyed.

Operation	Meaning	Can the instance accept later work?
`replaceState(null)`	Commit an intentional null value	Yes
`reset()`	Return to a neutral runtime snapshot	Yes
`destroy()`	Finalize the active FeatureCell instance	Only after recreation

⚠️ Warning: Do not describe every clear operation as "resetting state." That wording hides whether the application committed a meaningful null, returned to a neutral runtime, or ended the feature entirely.

Keep Lifecycle APIs in the Service Boundary

The Chapter 6 component does not reach through the service to call the FeatureCell directly. Instead, the service exposes named operations that describe the application's intent. That keeps ownership in one place and gives the component a stable domain-facing API.

destroyFeatureCell(): void {
  this.#vault.destroy();
}

resetState(): void {
  this.#vault.reset();
}

persistNullValue(): void {
  this.#vault.replaceState({ value: null });
}

The names are not cosmetic. They prevent callers from having to know which low-level method represents the intended lifecycle outcome. They also make the service spec readable: one test can verify an intentional null write, another can verify a reusable reset, and another can verify terminal destruction.

This is the same ownership rule used for create, update, and delete. The service owns committed Feature State and lifecycle authority; the component owns presentation state that can be cleared or disabled in response.

Finalizing a Feature with destroy()

destroy() is the operation that changes the UI's available future. It does not clear a value for reuse. It permanently finalizes the active FeatureCell instance, so later requests from that instance are invalid.

That distinction matters for a screen that is leaving the runtime, a feature whose ownership is complete, or a workflow that must not accept accidental writes after teardown. The component should make the final state visible instead of leaving controls that appear to work but target a destroyed instance.

Key takeaway: If the feature will be used again, choose a clear or reset operation. If the active instance is finished, destroy it and require a documented recreation path before offering new requests.

Disable the UI After Teardown

Lifecycle authority still belongs to the service, but the component must respond to the result. Chapter 6 clears the editor form after a lifecycle action. After destruction, it also tracks a destroyed state, disables later interaction, and renders an explicit message telling the learner that the instance must be recreated.

This is more than a visual detail. Local form values, selected identities, pending confirmations, and feedback messages are all temporary UI state. Leaving them active after destruction would suggest that the feature is still usable. Clearing them preserves the architectural boundary in the user experience as well as in the code.

The recovery rule is equally important: after testing destroy(), reload or replace the project with a fresh Chapter 6 checkpoint before continuing to Chapter 7. A future application runtime may recreate a feature, but it should do so through the lifecycle contract documented for that application, including any persistence cleanup it requires.

Deeper Dive

Work through the Angular Chapter 6 lifecycle tutorial, then compare the API details for replaceState(), reset(), and destroy(). The next lifecycle decision becomes much easier once your code names the intended outcome instead of treating every empty view as the same state.

Chapter 5 — Route Destructive Delete Through the Same Service-Owned Boundary

SDuX Vault — Tue, 22 Sep 2026 23:06:33 +0000

Delete is the mutation most likely to tempt a developer into a one-off array splice inside a component. Chapter 5 shows that a destructive write does not need a different architecture than create or update: switch the Merge stage to identifier-based semantics, submit the target identity through the same service-owned FeatureCell method, and keep confirmation state local to the view.

A remove button is easy to wire up badly. It is one click away from filtering an array in the component and calling it done. That approach quietly moves collection mutation policy into the UI layer, exactly the coupling the create and update chapters worked to avoid. Chapter 5 keeps the same boundary in place for the operation that removes data instead of adding it.

Key takeaway: Deletion is still a merge. Register identifier-based merge semantics once, then submit the target identity through the service's existing write path with a delete flag. The component never touches the committed collection.

Why Delete Tempts Developers to Bypass the Pipeline

Create and update both produce a record the pipeline can merge back into the collection. Delete produces nothing — its whole purpose is to make a record disappear. That asymmetry is exactly why delete is the operation most often implemented as a manual .filter() against local component state: there is no obvious "new value" to hand to a write API, so the shortcut of rebuilding the array by hand feels natural.

The shortcut has a cost. A component that filters its own copy of a collection is now responsible for knowing the identity field, keeping that copy in sync with every other write path, and re-implementing removal semantics that the Merge stage already provides. Chapter 5 avoids all of that by treating delete as a merge request with a flag, not a different kind of state management.

Warning: A component-level .filter() against a local array copy is not synchronized with the FeatureCell's committed collection. Any other consumer of that Feature State will not see the removal, and the next unrelated write can silently reintroduce the deleted record.

Switching to Identifier-Based Merge Semantics

Before a service can update or remove a specific record, the registered FeatureCell needs to compare incoming records by identifier rather than simply appending them. Chapter 5 registers withArrayByIdMergeBehavior for the Merge stage — the same stage used by the create and update paths from earlier chapters, now configured to also honor a delete flag.

export const characterCell = FeatureCell<StarWarsCharacter[]>(
  {
    key: 'star-wars-character',
    initialState: STAR_WARS_CHARACTERS
  },
  [withArrayByIdMergeBehavior]
);

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

With this behavior active, the Merge stage applies one consistent rule for every write: a matching identifier is updated, an unseen identifier is appended, and a merge request marked for deletion removes the matching record instead. The service does not need a separate removal algorithm — it needs a differently configured request to the same write path.

Adding a Service-Owned removeCharacter Method

The delete method looks almost identical to create and update: it still calls mergeState on the service-owned FeatureCell. The difference is the shape of the input and a second argument that marks the request as destructive.

function removeCharacter(id: number): void {
  characterCell.mergeState(
    {
      value: [{ id } as StarWarsCharacter]
    },
    { isDelete: true }
  );
}

The incoming value only needs to carry the identifier the merge behavior matches on — it does not need the rest of the record. The second argument, { isDelete: true }, tells the active Array By ID Merge behavior to remove the matching record from the collection rather than update or append it.

Operation	mergeState value	Merge behavior result
Create	New record, unseen identifier	Appended to the collection
Update	Full record, known identifier	Matching record replaced
Delete	Identifier only, plus `isDelete: true`	Matching record removed

Design rule: Every write — create, update, or delete — is still a mergeState call on the service-owned FeatureCell. The service never needs a parallel, hand-built removal algorithm.

Staging a Cancelable Delete Confirmation Locally

Removing a record is harder to undo than editing one, so Chapter 5 adds a confirmation step before the service is called at all. That confirmation state — which record is pending removal, whether the user has confirmed it — belongs to the component, not the shared collection. Nothing about "is this delete currently being confirmed" is meaningful to any other consumer of the Feature State. The same pattern applies with local component state in any framework (useState, a ref, or a writable store).

protected readonly deleteCandidate = signal<StarWarsCharacter | null>(null);

protected requestDelete(): void {
  const character = this.selectedCharacter();

  if (character) {
    this.deleteCandidate.set(character);
    this.feedback.set(null);
  }
}

A cancel handler clears deleteCandidate without calling the service at all — cancellation is purely a local state reset, the same principle the create and update chapters established for aborted edits. Only a confirm action calls removeCharacter, and only after the user has explicitly acknowledged the pending record.

Ownership test: If canceling the action should leave the committed collection untouched, the state describing that in-progress action belongs in the component. Only a confirmed, committed intent should reach the FeatureCell.

Handling Unknown or Stale IDs Safely

A confirmation panel reduces accidental deletes, but it does not guarantee the identity is still valid by the time the user confirms — another write could have already removed or replaced that record. Array By ID Merge handles this without extra service logic: when the submitted identifier has no match, the merge behavior leaves the visible collection state equivalent, rather than throwing or silently corrupting unrelated records.

Current collection	Submitted identity	Result
`[{ id: 1 }, { id: 2 }]`	`{ id: 1 }`	Record 1 removed; record 2 preserved
`[{ id: 1 }, { id: 2 }]`	`{ id: 99 }`	No match — collection remains unchanged

Because the removal rule is identity-based, one matching record is removed while every other record in the collection is preserved exactly as committed. The service does not need to special-case a missing identity — the configured merge behavior already defines what happens.

Verifying Delete Without Breaking the Boundary

A short set of questions confirms the boundary held. Does the service still own the only call that mutates committed Feature State? Is the pending-delete confirmation local to the component? Does canceling leave the collection untouched? Does confirming submit an identity through the same mergeState path used by create and update, just with isDelete: true?

Tests can confirm the service behavior directly by acting on the FeatureCell, settling the pipeline, and asserting on the resulting State — the same act, settle, assert pattern used throughout the tutorial series.

it('should remove the matching character from the current collection', async () => {
  const service = await configureService();

  service.removeCharacter(10);

  await vaultSettled(key);

  expect(service.state.value()).toEqual([initialCharacters[1]!]);
});

it('should safely remove against an empty collection when no value exists', async () => {
  const service = await configureService(null);

  service.removeCharacter(10);

  await vaultSettled(key);

  expect(service.state.value()).toBeUndefined();
});

StackBlitz placeholder

The Chapter 5 source contains a StackBlitz placeholder, but no verified project URL is present yet. Add the verified project link here when the demo is published.

Review the boundary: If a component needs to know how identifiers are matched, which records survive a removal, or how a stale identity is handled, that knowledge belongs in the feature service and its configured merge behavior — not in the delete button's click handler.

Deeper Dive

Continue with the Chapter 5 delete tutorial, then compare it with the Chapter 4 add and edit boundary. Together they show that create, update, and delete are the same service-owned write path, configured with different merge semantics rather than three separate architectures.

Tutorial Chapter 3 — Keep Selection Local With Shared Feature State

SDuX Vault — Tue, 15 Sep 2026 23:33:39 +0000

A master-detail view needs a current selection, but that does not mean the selection belongs in shared State. Chapter 3 of the SDuX Vault tutorial adds an interactive read path while keeping the committed character collection behind its service boundary.

This distinction applies to pickers, record browsers, settings panels, and search-result views. The collection may be useful to multiple consumers, while the item currently being inspected is usually meaningful only to the view doing the inspecting.

Key takeaway: Keep committed Feature State in the feature service. Keep the current selection local to the view, then derive the selected record from both values.

From a Fixed Read View to a User-Selected Read Path

The previous chapter establishes a complete read path: a typed character collection is registered as Feature State, a service exposes access to it, and the component renders a character. The initial screen can use a fixed record to make the ownership boundary visible.

Chapter 3 changes the presentation path, not the ownership model. The view receives the same managed collection and adds a selection control. Selecting an item does not copy the collection into the component, create a second store, or ask the feature service to remember which row a reader opened. It records only the local choice and derives the detail record from the existing collection.

Concern	Owner	Reason
Character collection	Feature service	Committed feature data that other consumers may read
Selected character ID	Displaying view	Temporary navigation in one presentation context
Selected character	Derived read path	Recalculated whenever the collection or selection changes

The result is interaction without duplication. The view becomes more useful while the State contract remains understandable to every other consumer.

Shared Collection State vs Local Selection State

The key question is not whether a value changes. Both a collection and a selection can change. The question is whether it belongs to the feature’s committed domain State or is merely a temporary decision made by one view.

A character collection may be read by a list, detail panel, search result, and separate summary. It belongs behind the feature service because it is the shared source of truth. A selected ID in one master-detail screen does not automatically have meaning for those other consumers. Storing it centrally would couple them to a navigation choice they did not make.

Ownership test: If two independent consumers need the same committed value, it is a candidate for shared Feature State. If a value only tells one view what it is currently displaying, keep it local until a real shared requirement appears.

Local state still has a precise job: it is the input to the read path, not a replacement for the managed collection. A second detail panel can choose its own item without overwriting the first panel’s choice.

Deriving the Selected Record Reactively

Chapter 3 exposes the collection as a reactive value and keeps a nullable selected ID in the component. The selected record is a projection: find the record whose identifier matches the local choice, or return no record when there is no match.

The Angular implementation is:

protected readonly selectedCharacterId = signal<number | null>(null);

protected readonly selectedCharacter = computed(() => {
  const selectedId = this.selectedCharacterId();
  return this.characters().find(({ id }) => id === selectedId) ?? null;
});

Angular Signals provide the mechanics; the ownership rule is not Angular-specific. The implementation is presented as an example, not as a claim that every framework should use Signals. React, Vue, or Svelte would use that framework’s reactive primitive while preserving the same inputs and derived result.

The computed value does not fetch a second copy of the character, mutate the shared collection, or write the selected record back into Feature State. It joins a local presentation input with shared committed data and produces the value required by the detail panel.

If the service-owned collection changes, the lookup runs again. If the local selection changes, it runs again. The detail panel reflects the latest valid combination instead of a stale object copied during an event handler.

Handling Empty and Unknown Selections

An interactive view has more states than “the record is visible.” The collection may still be empty while the feature initializes. A user may not have selected anything. A stale link, malformed control value, or collection refresh may refer to an identifier that is no longer present.

Chapter 3 treats these as normal read-path outcomes. The selected record is nullable, and the template displays an empty state when the lookup returns no match. The selection handler ignores an unknown value instead of placing invalid data into local state.

Condition	Derived result	View response
No records loaded	No selected record	Disable or leave the picker empty and explain the next step
No selection yet	`null`	Show “No character selected” rather than inventing a default
Unknown identifier	No selected record	Ignore the invalid choice and preserve a safe empty state
Valid identifier	Matching committed record	Render detail fields from the derived value

⚠️ Warning: Do not use a default record to hide an invalid state. A default can be a deliberate product decision, but silently displaying the first record makes an empty or stale selection look valid and makes the interaction harder to reason about.

Testing Interaction Without Moving State Ownership

The ownership boundary gives the tests a straightforward shape. The feature-service test verifies that the managed collection is available through its committed State path. The view test verifies that selection changes the derived detail record, that the empty state appears before a valid choice, and that an unknown identifier does not produce a fabricated detail view.

Test focus	Useful assertion
Initial view	Detail panel shows the empty state and the picker is safe to use
Valid selection	Detail fields match the selected record in the shared collection
Unknown selection	No invalid record is rendered and the view remains predictable
Collection refresh	Derived value reflects the newest collection for the local ID

These are separate assertions because they protect separate responsibilities. A view test should not inspect feature-service internals, and a service test should not render a detail panel merely to prove the collection exists.

The same tests apply in any UI framework. Subscription, memoization, and rendering syntax may change, but the behavior contract remains: shared data remains shared, temporary navigation remains local, and the detail view is derived from a valid pair of inputs.

A Boundary That Scales Beyond the Tutorial

Chapter 3 demonstrates how to add interaction without broadening State ownership. The service keeps the feature’s committed collection available to every consumer, while each view decides what it is currently reading.

If a later requirement says multiple screens must share the same selection, that is a new domain decision. Move it deliberately into shared Feature State only when the requirement is real and the selection has meaning beyond one view. Until then, local state is the smaller and clearer boundary.

The complete tutorial shows the interactive read path in context. Regardless of framework, the separation between committed Feature State and local presentation state remains constant.

Continue Learning

Remember: Share the collection because it is feature data. Keep the selection local because it is a view decision. Derive the detail record instead of duplicating it.

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.