DEV Community: SDuX Vault

Chapter 11 — Encrypt and Persist Feature State Without Polluting Application Code

SDuX Vault — Thu, 22 Oct 2026 16:01:02 +0000

Browser persistence should not force your application code to handle ciphertext, storage envelopes, or reload restoration. Chapter 11 shows how AES-256-GCM encrypts finalized Feature State at the persistence boundary while the FeatureCell continues to work with plain in-memory values.

This is also a security boundary lesson. Encryption and persistence are Pro capabilities: development evaluation can use the documented licensing bypass, but production use requires a valid Pro license and must not rely on that bypass. The chapter also makes clear what browser-side encryption does not provide: authorization, XSS protection, secret confidentiality, or cross-device recovery.

Key takeaway: This tutorial starts with the completed Chapter 7 project and adds the Pro Encrypt and Persist behaviors, a stable teaching salt, and tab-scoped Session Storage persistence.

Why Persistence Needs a Deliberate Threat Model

Keeping a local workspace across a reload is useful. It can preserve non-sensitive preferences, a draft, or a short-lived session view without making the user rebuild the same context every time. But persistence gives data a longer life than the current page, so the storage lifetime and the value of the data have to justify each other.

Chapter 11 places encryption at the boundary between finalized application State and the persistence mechanism. The application continues to read and write ordinary values through its FeatureCell boundary. The persisted envelope is encrypted before it reaches Session Storage, and the value is decrypted before it returns to the application.

That boundary protects the confidentiality and integrity of the persisted envelope when an attacker obtains storage alone but does not have the key-derived secret. It does not turn browser JavaScript into a confidential key store. A successful same-origin script, XSS, malicious extension, or compromised browser runtime can still read plain in-memory State and any secret available to the client.

Warning: Encryption and Persistence behaviors require a valid Pro license for production use. The tutorial uses devMode: true with bypassLicensing: true only for local development evaluation. Do not carry that bypass into production, and do not paste production secrets or sensitive user data into the teaching example.

Register Encrypt and Persist at the Pipeline Boundary

The application configuration registers the two Pro behaviors beside the existing collection behavior. The tutorial's behavior list is intentionally visible, but declaration order does not redefine the behaviors' fixed pipeline stages. Encryption transforms the finalized outbound value before Persist writes its envelope.

For the framework-agnostic core API, the FeatureCell is configured with both behaviors:

import { FeatureCell } from '@sdux-vault/core';
import {
  withAes256EncryptBehavior,
  withArrayByIdMergeBehavior,
  withSessionStoragePersistBehavior
} from '@sdux-vault/addons';

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

The bypass is an evaluation convenience, not a licensing model for shipped software. In production, the Pro behaviors need a valid license. That distinction belongs in the setup instructions because developers should know whether they are exploring a capability or configuring a production application.

Keep Plain State Inside the FeatureCell

Encryption is useful here because it stays out of the feature's domain logic. The service still configures its filters, reducers, collection identity, and initialization. It also supplies the secret configuration before initialization. Nothing in the component has to serialize a character, assemble an envelope, or decrypt a reload result.

The core configuration uses the same FeatureCell created above:

const EXAMPLE_AES256_SALT = new Uint8Array([
  0x53, 0x44, 0x75, 0x58, 0x2d, 0x56, 0x61, 0x75, 0x6c, 0x74, 0x2d, 0x54, 0x75,
  0x74, 0x6f, 0x72
]);

characterCell
  .setAes256Secret({
    aes256Secret: 'sdux-vault-tutorial-only-secret',
    salt: EXAMPLE_AES256_SALT,
    iterations: 250_000
  })
  .initialize();

The call to setAes256Secret() belongs before initialize(). The stable 16-byte salt in the tutorial makes the exercise repeatable, but it is not a password or a confidential key. A stable salt supports key derivation for ciphertext that must be read later; it does not solve production key management.

Warning: In production, supply the salt dynamically from a secure, durable source that your application controls. The stable salt shown here exists to make the lesson repeatable and the reload behavior easy to see; it is not a production secret-management strategy. Keep the salt stable for data that must be decrypted later, protect the secret that derives the encryption key, and choose storage and key-management policies that match your threat model.

Plain in memory, protected at rest: Trusted application code continues to receive plain Feature State. The encryption behavior protects the value at the persistence boundary rather than forcing every consumer to understand the storage format.

Stable Salt, Reload Restoration, and Initial State Priority

A stable salt matters because the persisted ciphertext must be decryptable after the page reloads. The tutorial also uses a stable storage key so the same FeatureCell can find its Session Storage envelope again. The AES-GCM initialization vector is generated for encryption and stored in the envelope; it is not a replacement for the stable salt.

On startup, persisted State takes priority over initialState. That is the behavior users expect from restoration: the initial characters seed a feature that has never been persisted, but they should not overwrite a valid session snapshot on every reload. The FeatureCell still presents the restored value as ordinary State after decryption.

Concern	Owner	Responsibility
Feature State	FeatureCell	Expose plain values to trusted application code.
Encryption	AES-256 Encrypt behavior	Protect the finalized value before persistence.
Storage lifetime	Session Storage Persist behavior	Restore the encrypted envelope across reloads in the current tab.
Threat model	Application team	Choose data, secrets, retention, authorization, and recovery policies.

Session Storage Is Tab-Scoped, Not Cross-Device Recovery

Session Storage gives this tutorial a clear and limited persistence story. Reload the page in the current browser tab and the encrypted envelope can be restored. Open another tab and it does not become a shared source of truth. Close the tab and the session normally ends, although browser crash recovery and session-restoration features can affect that lifetime.

That scope is often a good fit for temporary local work, but it is not a substitute for a server, an account-backed data model, or a cross-device recovery plan. Encryption also does not provide authorization, server security, data minimization, or a retention policy. Those are separate application decisions.

Warning: A secret bundled into browser JavaScript is available to the browser runtime. Use the tutorial secret and salt to learn the boundary, not as a production secret-management strategy.

What Client-Side Encryption Does Not Protect

The most valuable part of Chapter 11 is its list of non-goals. The encrypted envelope is not the same thing as an encrypted application runtime. If hostile code executes successfully in the same origin, it can observe plain State before encryption or use any client-available secret. If the feature needs authorization, the server and identity boundary must provide it.

The chapter's recovery path is similarly intentional. Malformed storage data should not become partial application State. A failed decryption should be normalized and the relevant storage key cleared, followed by a fresh authoritative load. Recovery is a new decision, not a reason to silently trust corrupted or unauthenticated data.

Encryption does not prevent XSS or malicious extensions.
Encryption does not hide plain State from trusted application code.
Encryption does not create authorization or server security.
Session Storage does not provide cross-tab or cross-device recovery.
A tutorial secret and salt are not production key management.

Deeper Dive

Chapter 11 is a practical lesson in keeping persistence concerns at the boundary. Read the Encrypt and Persist tutorial chapter for the complete Angular walkthrough, source tabs, and StackBlitz project. Before using the Pro behaviors in production, replace the tutorial licensing bypass with a valid Pro license and make the secret, storage lifetime, authorization, retention, and recovery decisions appropriate for your data.

Chapter 10 — Delay State Transitions Without Changing State Meaning

SDuX Vault — Thu, 08 Oct 2026 13:51:24 +0000

A delayed State transition should still mean the same thing when it finally continues. Chapter 10 introduces the Delay Controller as a timing boundary: every pipeline attempt pauses for a configured interval, then continues with the same candidate State. The service owns withDelay() configuration, while the component exposes the elapsed teaching experience without taking ownership of the pipeline through the FeatureCell boundary.

A pause can look like a debounce, a throttle, or a hidden mutation rule when the only visible evidence is that a button feels slower. The Chapter 10 lab makes the boundary explicit: the Delay Controller changes when an accepted update proceeds, not which update is processed or what its value means.

Key takeaway: Begin with the completed Chapter 7 project. Chapter 10 adds a fixed three-second interval and a display-only elapsed timer to the existing character workflow.

Delay Changes Time, Not Meaning

A FeatureCell update still starts with a candidate value. The service submits that candidate through the same service-owned boundary, and the configured pipeline still determines whether it can become committed State. The new behavior is the pause before the pipeline attempt proceeds through its configured timing policy.

That makes Delay useful when timing is part of the user experience but not part of the data rule. You might want a visible animation to settle before a panel changes, a demo to represent realistic latency, or an external handoff to receive a predictable interval. In each case, the candidate remains the candidate. Delay does not rewrite the object, select a different record, or turn a state update into a new kind of update.

The service decides that this FeatureCell uses a fixed delay, the controller applies that timing policy, and the component renders the result. The component does not create a second timer to decide when State is allowed to change.

Registering the Delay Controller

The Delay Controller must be registered before the service can configure it. In the Angular tutorial, that registration belongs beside the FeatureCell provider in app.config.ts. The application supplies the controller as infrastructure; the service supplies the interval as feature policy.

The source example registers the controller alongside the existing array merge behavior:

import { withArrayByIdMergeBehavior, withDelayController } from '@sdux-vault/addons';

provideFeatureCell(
  ExampleService,
  {
    key: 'star-wars-character',
    initialState: STAR_WARS_CHARACTERS
  },
  [withArrayByIdMergeBehavior],
  [withDelayController]
);

Registration makes the controller available at the FeatureCell boundary. It does not tell the feature how long to wait. That decision comes next, in the service that already owns the character State and its update methods.

Configure a Fixed Interval in the Service

Chapter 10 keeps timing configuration next to the other FeatureCell pipeline configuration. The service declares the interval as a named constant and calls withDelay() before initialization. This keeps the policy discoverable and prevents individual component actions from inventing their own timing rules.

/** Fixed Policy-stage hold applied to every tutorial pipeline attempt. */
export const EXAMPLE_DELAY_MILLISECONDS = 3_000;

constructor() {
  this.#vault.withDelay?.({
    millisecondDelay: EXAMPLE_DELAY_MILLISECONDS
  });

  this.#vault.initialize();
}

The fixed interval is not a component setting. A create, edit, or delete method submitted through this service encounters the same configured timing policy. The feature does not become fast for one button and delayed for another because each handler implemented its own waiting logic.

⚠️ Warning: Register the controller at the provider boundary and configure withDelay() before calling initialize(). The service should be the one place where this FeatureCell's pipeline policy is assembled.

Make the Pause Observable Without Moving Pipeline Authority

A three-second pause is difficult to understand if the screen only appears unresponsive. The tutorial therefore adds a small elapsed timer to the component. It starts when the service reports that an update is loading and stops when that update reaches its normal completion, finalization, or error presentation path.

The timer explains what the learner is seeing; it does not control the update. It does not call setTimeout() around a service method, decide whether a second click should be ignored, or delay a component-local copy of State. The FeatureCell remains the source of loading and State information, and the service remains the owner of the update boundary.

The configured interval can be rendered beside the live elapsed value, so the learner can observe that the pause is deliberate. Removing the display helper removes the lesson's stopwatch, but it does not remove the Delay policy from the service.

Concern	Owner	Responsibility
Timing policy	Service and Delay Controller	Configure and apply the fixed interval for the FeatureCell pipeline.
Candidate State	FeatureCell pipeline	Continue the submitted candidate without changing its meaning.
Elapsed display	Component	Show the teaching experience without deciding when State may commit.

Every Attempt Gets the Configured Interval

Delay is easiest to reason about when its unit is an attempt. A user action submits a candidate, and that attempt observes the configured interval before it continues. The rule is not “wait until the user stops clicking” and it is not “run at most once per window.” It is simply a fixed pause associated with each pipeline attempt.

If two actions are initiated close together, each one has its own timing experience. Delay does not secretly collapse them into one update or claim that the latest action is automatically the only meaningful one. The rest of the configured FeatureCell pipeline still determines how those candidates are processed and committed.

The Chapter 10 screen makes this visible with repeated updates. Watch the loading and elapsed values, then compare the committed character State. The delay changes when you see the result; it does not add a second business rule about which character update should win.

Why Delay Is Not Debounce or Throttle

Debounce and throttle answer questions about the relationship among multiple incoming events. Debounce waits for quiet and typically keeps the latest event. Throttle limits how often work is allowed to start within a window. Those are event-admission rules.

Delay answers a different question: once this pipeline attempt is accepted, how long should it pause before continuing? It does not change the candidate, suppress a candidate because another event arrived, or redefine the update as “latest wins.” Calling every visible pause a debounce makes the timing policy sound more powerful than it is and encourages ownership in the wrong layer.

Key takeaway: Use Delay for a fixed execution interval. Choose debounce or throttle only when the requirement is explicitly about admitting, grouping, or limiting a sequence of events. Keep the candidate State and the timing rule conceptually separate.

The Chapter 10 Boundary

The completed lab has three clear owners. The application registers withDelayController. The service configures withDelay() and keeps the FeatureCell update methods together. The component renders loading, elapsed time, and committed State as a teaching surface.

That arrangement gives timing a place without letting timing become a second state architecture. You can change three seconds to a different fixed interval, remove the elapsed display, or use the same policy with another feature while preserving the underlying meaning of the State transition.

The next time an update needs to wait, ask whether the requirement is about when an accepted attempt proceeds or which events should be admitted. If it is the former, Delay can express that intent directly. Keep configuration with the service, registration with FeatureCell infrastructure, and explanation with the component.

Try the complete Chapter 10 example in StackBlitz, then compare its setup with the Delay Controller reference and the FeatureCell API.

Chapter 9 — Route Async Inputs Through One Service-Owned Pipeline

SDuX Vault — Tue, 06 Oct 2026 15:12:17 +0000

What changes when the same feature receives its data four different ways: during hydration, from a Promise, through an Observable, and from an Angular HTTP Resource? The source contracts look different enough to invite separate loading, error, and state-management paths. This chapter follows each one to the same service-owned FeatureCell™ boundary, where the more important question is revealed: who still owns the result when the source succeeds, stalls, or fails?

The component supplies teaching controls and presentation state. The service registers the source and chooses the appropriate state API. The pipeline resolves the input, applies the existing filters and reducers, tracks loading and errors, and commits the resulting State. The source changes; the ownership boundary does not.

Key takeaway: Begin with the completed Chapter 7 project. Chapter 9 extends the same Chapter 7 character workflow and service-owned pipeline rather than replacing it with a new asynchronous architecture.

Continue the Chapter 7 Pipeline Through an Async Lab

Chapter 7 established the successful data path: a candidate enters the service-owned pipeline, the pure filter removes the teaching record whose last name is unknown, and ordered reducers derive display fields and sort the retained collection. Chapter 8 kept that path intact while making failure observable through a controlled filter error.

Chapter 9 keeps both lessons and changes the input timing. The completed Chapter 8 project becomes the starting point for a lab with four source contracts. Hydration controls initialization. Promise and Observable examples submit later updates through mergeState(). HTTP Resource submits a validated replacement through replaceState().

Input	Boundary	Lab result
Hydration Promise	`initialize()`	Supplies the authoritative initial collection before the first committed State.
Promise	`mergeState()`	Resolves once, removes Grogu through the existing filter, and appends Ahsoka and Din.
Observable	`mergeState()`	Uses the first emitted collection, removes R2-D2, and appends Ezra and Hera.
HTTP Resource (Angular only)	`replaceState()`	Parses the selected remote characters, removes Yoda, and replaces the prior collection with Lando and Han.

⚠️ Warning: The controlled Promise and Observable helpers expose a pending interval so you can see loading and failure. Settle the current source before starting another; do not infer a general policy for cancellation, repeated emissions, or overlapping requests from this lab.

Hydrate Authoritative Initial State

Hydration is different from a later fetch because it controls the first initialization request. The service registers a deferred hydrate() factory before it calls initialize(). The factory does not run when it is registered; initialization waits for it to resolve or reject.

Resolve the teaching Promise and the hydrated collection continues through the same Resolve, Filter, Reducer, and Emit stages already used by the feature. Reject it and initialization enters Error State. The configured initialState is not silently used as a fallback, and persistence does not replace the authoritative hydration result.

This is why the lab keeps the Resolve and Reject buttons separate from the service. The component decides when to settle the teaching helper, but the FeatureCell owns initialization, loading, error handling, and the eventual State snapshot.

Key takeaway: Reload the example and leave hydration pending. The loading indicator remains active until you choose Resolve or Reject. That interval belongs to the FeatureCell lifecycle, not to a second loading flag invented by the component.

Resolve Promise and Observable Inputs Through `mergeState()`

After initialization, a Promise and an Observable represent two different ways to deliver a later candidate. Both can be submitted through mergeState(), but the source contracts are different: a Promise resolves once, while the Observable Resolve behavior subscribes and extracts a single emitted value for downstream processing. The component starts the request and exposes the teaching control; it does not await the Promise or subscribe to the Observable.

Promise: await one deferred result

The Promise helper holds one pending Promise. When you click Resolve, Ahsoka, Din, and Grogu become the resolved collection. The existing filter removes Grogu, the reducers derive the display fields, and array-append merge keeps the existing collection while adding the retained characters. When you click Reject, the previously committed collection remains visible and the error lifecycle completes.

const deferredPromise = examplePromise.getPromise();

characterCell.mergeState({
  value: () => deferredPromise
});

The request shape is intentionally small. The service passes the deferred source to the FeatureCell; the pipeline owns waiting, transformation, error handling, and commitment. A rejected Promise does not erase the last committed collection.

Observable: resolve one emitted value

The Observable helper uses a controlled ReplaySubject. Click Add by Observable to start the request, then Emit or Error to settle it. The Observable Resolve behavior owns the subscription and extracts one emitted collection for downstream processing. This is a single state update, not a continuous stream subscription owned by the component.

import { of } from 'rxjs';

const characters$ = of([
  { id: 201 },
  { id: 202 },
  { id: 203 }
]);

characterCell.mergeState(characters$);

The Observable source is submitted to the FeatureCell just like the Promise source, but Resolve handles the Observable subscription and forwards its single emitted value. The existing filter, reducers, and array-append merge then process that value. In the lab, Emit appends Ezra and Hera after R2-D2 is filtered out; Error preserves the previously committed collection while the pipeline error lifecycle completes.

⚠️ Warning: Do not move the subscription into the component. Doing so would create a second lifecycle for loading, errors, and cleanup. Submit the Observable to the service-owned boundary and let the Resolve behavior handle the single emitted value.

Replace State from a Validated HTTP Resource (Angular Only)

The HTTP Resource example uses a different write promise. The service creates a resource through the teaching adapter and passes it to replaceState(). The component starts the request but never reads the resource directly.

The adapter calls the public SWAPI people endpoint, selects the characters needed by the tutorial, derives numeric identities from canonical resource URLs, and rejects incomplete data before it reaches State. The response is untrusted at this boundary, so parsing and validation stay with the transport adapter.

On success, the selected collection continues through the existing Filter and Reducer stages before it replaces the previous collection. Yoda is removed because its last name is unknown, leaving Lando and Han in last-name order. On transport, parsing, validation, or HTTP failure, the previous collection remains committed and the normalized error is visible.

this.#vault.replaceState(
  exampleHttpResource.getResource(this.#injector)
);

⚠️ Warning: Connectivity, CORS policy, rate limits, and remote schema changes can make SWAPI unavailable. Treat a normalized failure with the old collection preserved as correct boundary behavior. Do not weaken response validation to force an external response to commit.

Compare Four Async Source Contracts

The four examples differ in when the source begins and whether the request merges or replaces State. They do not require four copies of the application's loading, error, filtering, and reduction logic.

Source	Successful path	Failure path
Hydration	Authoritative initial data is filtered and reduced before initialization commits.	Initialization enters Error State instead of falling back to configured initial State.
Promise	One resolved collection is filtered, reduced, and appended.	The existing collection remains visible while the rejection becomes Error State.
Observable	The first emitted collection is resolved, filtered, reduced, and appended.	The existing collection remains visible while the source error is normalized.
HTTP Resource (Angular only)	A parsed and validated collection is filtered, reduced, and committed as a replacement.	Transport or validation failure preserves the prior collection.

The execution guarantee is the same across these inputs: the pipeline computes the outcome before State commitment. Observers do not see a partially parsed response, an intermediate reducer result, or a collection that was changed before a later async failure was known. Each successful input produces one finalized snapshot, while a failed input leaves the previous committed collection intact when the request is a later merge or replacement.

Key takeaway: Choose the state API that matches the source contract, then keep resolution, transformation, loading, errors, and commitment inside the same FeatureCell pipeline.

Verify Loading, Errors, and Service-Owned Commitment

Run the lab as a sequence of observable contracts. First reload and resolve hydration. Confirm that the hydrated collection commits only after the deferred source settles, that BB-8 is removed, and that reducers add display fields and sort the result. Repeat with Reject and confirm that initialization ends in Error State without silently using the configured initial collection.

Next run the Promise and Observable paths. Watch state.isLoading() while each source is pending. Resolve or Emit and confirm the retained characters are appended. Reject or Error and confirm the committed collection is preserved. The component's buttons make the timing visible, but the service remains the only owner of the source-to-State transition.

Finally run the HTTP Resource path. Confirm that a valid response replaces the collection with Lando and Han after parsing, validation, filtering, and reduction. If the public endpoint fails, confirm that loading ends, the normalized error is visible, and the previous collection remains intact.

This lab is complete when you can explain the difference between initialization-time hydration and later asynchronous updates, and when all four sources show the same FeatureCell loading and error lifecycle without moving pipeline authority into the component.

Deeper Dive

Continue with the complete Chapter 9 lab, then review the HTTP Resource Resolve behavior, Promise Resolve behavior, Observable Resolve behavior, and the pipeline execution guarantees.

StackBlitz demo: Chapter 9 — Route Async Inputs Through One Service-Owned Pipeline.

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:

DEV Community: SDuX Vault

Chapter 11 — Encrypt and Persist Feature State Without Polluting Application Code

Why Persistence Needs a Deliberate Threat Model

Register Encrypt and Persist at the Pipeline Boundary

Keep Plain State Inside the FeatureCell

Stable Salt, Reload Restoration, and Initial State Priority

Session Storage Is Tab-Scoped, Not Cross-Device Recovery

What Client-Side Encryption Does Not Protect

Deeper Dive

Chapter 10 — Delay State Transitions Without Changing State Meaning

Delay Changes Time, Not Meaning

Registering the Delay Controller

Configure a Fixed Interval in the Service

Make the Pause Observable Without Moving Pipeline Authority

Every Attempt Gets the Configured Interval

Why Delay Is Not Debounce or Throttle

The Chapter 10 Boundary

Chapter 9 — Route Async Inputs Through One Service-Owned Pipeline

Continue the Chapter 7 Pipeline Through an Async Lab

Hydrate Authoritative Initial State

Resolve Promise and Observable Inputs Through mergeState()

Promise: await one deferred result

Observable: resolve one emitted value

Replace State from a Validated HTTP Resource (Angular Only)

Compare Four Async Source Contracts

Verify Loading, Errors, and Service-Owned Commitment

Deeper Dive

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

What Chapter 7 Already Gives You

Lab Step 1: Arm a Controlled Pipeline Failure

Lab Step 2: Register an Observational Error Callback

Lab Step 3: Compare Two Error Surfaces

Lab Step 4: Prove That Clear Is Not Recovery

The Chapter 8 Lab Takeaway

Deeper Dive

Chapter 7 — Centralize Filtering and Display Derivation in the Pipeline

Why Cross-View Data Rules Belong in the Pipeline

Refining Candidates with a Pure Filter

Composing Ordered Reducers Without Mutation

Deriving Display Fields Before Rendering

Keeping the Component Focused on Presentation

Verifying the Committed Collection

Deeper Dive

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

Empty Data Is Not the Same as an Ended Feature

Persisting Null vs Resetting the Runtime Snapshot

Keep Lifecycle APIs in the Service Boundary

Finalizing a Feature with destroy()

Disable the UI After Teardown

Deeper Dive

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

Why Delete Tempts Developers to Bypass the Pipeline

Switching to Identifier-Based Merge Semantics

Adding a Service-Owned removeCharacter Method

Staging a Cancelable Delete Confirmation Locally

Handling Unknown or Stale IDs Safely

Verifying Delete Without Breaking the Boundary

StackBlitz placeholder

Deeper Dive

Tutorial Chapter 3 — Keep Selection Local With Shared Feature State

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

Shared Collection State vs Local Selection State

Deriving the Selected Record Reactively

Handling Empty and Unknown Selections

Testing Interaction Without Moving State Ownership

A Boundary That Scales Beyond the Tutorial

Continue Learning

Angular Tutorial Chapter 2 — Display Character State

What the SDuX Angular Tutorial Builds

Chapter 2's First Read Path

Why the Angular Service Owns the FeatureCell

How Angular Dependency Injection and Signals Keep the Component Focused

From Registered State to a Displayed Character

Deeper Dive

A New Angular Tutorial for Building a Complete Feature with SDuX

Why This Tutorial Was Released

From Project Setup to a Working Feature

The Feature Service Is the Teaching Boundary

Core Chapters First, Optional Labs Second

Checkpoints Make the Tutorial Recoverable

Resolve Promise and Observable Inputs Through `mergeState()`