A final State value tells you what the user sees. It does not always tell you why that value appeared. Chapter 12 shows how to inspect one transition through the FeatureCell™ boundary without letting diagnostic code become a second state manager.
You will compare the current immutable StateSnapshot, the state$ stream, candidate values before and after taps, the finalized State emission, and an application-owned baseline. The result is a useful diagnostic trail with a clear rule: observation can explain a transition, but it does not control one.
Key takeaway: Begin with the completed Chapter 7 project and use one mutation throughout the lab. The same attempt is easier to understand when every observation surface can be compared side by side.
Why a Final State Value Is Not Enough to Explain a Transition
Debugging a state transition from the rendered screen alone is like debugging a compiler from its output binary. You can see the result, but you cannot tell which input was accepted, which transformation changed it, or whether the value was still loading when a consumer observed it. The missing context is often the difference between a real pipeline problem and a display problem.
Chapter 12 adds observation at the boundaries that matter. The service exposes the FeatureCell's reactive state surface and stream, then registers tap callbacks and State-emission observation. The component renders those readings for the lab. The component does not decide which candidate wins, replace a candidate from a callback, or infer lifecycle from a textarea.
| Surface | When it is observed | Question it answers |
|---|---|---|
state |
Latest reactive read | What is the FeatureCell reporting now? |
state$ |
Each committed State event | Which snapshots arrived, and what event produced them? |
beforeTaps() |
After filtering, before reducers | What candidate is about to be transformed? |
afterTaps() |
After reducers, before emission | What derived candidate is about to be committed? |
emitStates() |
After final State emission | What did this attempt emit? |
Read the Current Immutable StateSnapshot
The first observation surface is the simplest: the service exposes state from its private Vault reference. In the Angular tutorial, the component then reads the current isLoading, value, error, and hasValue values through the service boundary. This is a read of the latest committed snapshot, not a request to run the pipeline again.
// Expose the current reactive StateSnapshot
readonly state = this.#vault.state;
The core example exposes state directly from the FeatureCell reference. The current immutable snapshot contains the isLoading, value, error, and hasValue values. This is a read of the latest committed snapshot, not a request to run the pipeline again.
// Read the current committed snapshot
const snapshot = featureCell.state;
That distinction matters when the UI is showing a pending or empty state. hasValue answers whether a value is present; isLoading answers whether work is in progress; error reports the current error condition. A diagnostic view can display all four without subscribing to a second source or moving state ownership into the component.
⚠️ Warning: Read-only means read-only: treat every snapshot as immutable. Serializing a snapshot for a teaching view is an observation; mutating it and expecting the FeatureCell to adopt the change would bypass the State boundary.
Follow Committed Snapshots Through state$
Use state$ when the question is temporal: which snapshots arrived, and what event produced each one? The stream carries the full immutable snapshot together with event context. That makes it a better diagnostic surface than repeatedly polling the latest value, because the latest value can no longer show the earlier boundary that produced it.
// Observe committed State snapshots
readonly state$ = this.#vault.state$;
// Observe committed State snapshots
const state$ = featureCell.state$;
The Chapter 12 component subscribes through the Angular lifecycle, reads the snapshot from each event, and renders a serialized view. The subscription is not a control channel. It does not feed a new candidate back into the FeatureCell, and it does not change the event that has already been committed.
The core example subscribes to the FeatureCell's state$ stream and reads each committed snapshot for diagnostics. The subscription is not a control channel: it does not feed a new candidate back into the FeatureCell or change an event that has already been committed.
This is the right place to record a bounded event trail for a test or diagnostic screen. Keep the record useful: include the event context needed to explain the transition, redact sensitive fields, and avoid retaining every high-frequency emission forever.
Compare Candidates Before and After Taps
A committed snapshot still leaves a transformation question: did the candidate change between filtering and reduction? The relevant observation order is Filters, Before Tap, Reducers, After Tap, then State and State Emission. The tap surfaces let you inspect that progression without replacing the candidate.
// Capture candidates before and after reducers
this.#vault.beforeTaps([this.#captureBeforeTapInput]);
this.#vault.afterTaps([this.#captureAfterTapInput]);
// Capture candidates before and after reducers
featureCell.beforeTaps([captureBeforeTapInput]);
featureCell.afterTaps([captureAfterTapInput]);
beforeTaps() shows the filtered candidate immediately before reducers run. afterTaps() shows the derived candidate after reducers have finished and before State emission. In the lab, each callback writes an observation into a private writable Signal and exposes only a read-only view to the component.
In a core TypeScript diagnostic, each callback can record its observation in an application-owned diagnostic value without changing the candidate.
Key takeaway: Diagnostic boundary: a tap callback records what it sees. It does not return a replacement candidate, and the component does not use the recorded value as an alternative write path. That keeps the observation trustworthy.
Observe Final State Emission Without Taking Control
The last observation surface answers a different question from the taps: what finalized StateSnapshot did this attempt emit? Register emitStates() to capture the finalized snapshot after the pipeline has completed its transformation and State emission work.
// Capture the finalized State emission
this.#vault.emitStates([this.#captureEmittedState]);
// Capture the finalized State emission
featureCell.emitStates([captureEmittedState]);
Comparing the after-tap value with the emitted StateSnapshot gives you a precise checkpoint. If the two differ, the question is no longer “what did the reducer do?” but “which later boundary explains the finalized result?” If they match, the observation has ruled out one class of transformation without changing the application.
This also makes tests easier to explain. A test can perform one mutation, settle the application through its normal test harness, and assert the observations at the boundaries it cares about. The callbacks remain instrumentation, not a replacement for the FeatureCell's update API.
Capture a Baseline Safely for Diagnostics and Tests
Chapter 12 also needs a known collection to restore after each experiment. It captures the first state$ snapshot with hasValue, clones the value, and keeps that clone as an application-owned teaching baseline. The clone matters: the baseline is a reference point, not a live alias that later mutations can silently change.
Restoring that captured collection through replaceState() is different from calling reset(). The first restores the lab's captured collection. The second invokes the FeatureCell lifecycle reset behavior. Keeping those actions separate prevents a diagnostic label such as “Initial State” from hiding a different lifecycle operation.
| Action | Meaning in the lab |
|---|---|
| Captured baseline | One cloned value from the first State stream snapshot with a value |
replaceState() |
Restore that known collection through the normal State API |
reset() |
Run the separate FeatureCell lifecycle reset operation |
⚠️ Warning: Production telemetry needs limits: the tutorial serializes complete values so the boundary is visible. A shipped diagnostic surface should redact sensitive fields, sample noisy emissions, cap payload size, and avoid retaining snapshots longer than necessary.
A Practical Diagnostic Workflow
Start with the smallest surface that can answer the question. If the question is simply “what is committed now?”, read state. If the question is “what happened over time?”, inspect state$. If the final value is surprising, compare the filtered candidate before reducers with the derived candidate after reducers. Only then move to the finalized State emission and its event context.
This order keeps the diagnostic trail causal. You are not collecting every possible value because more logs are always better; you are placing a small number of observations where the pipeline changes meaning. A before-tap value can show that filtering removed a record. An after-tap value can show that a reducer derived or reordered a collection. A State emission can show what was finally exposed to consumers. The committed snapshot can then confirm what the UI reads after the attempt settles.
Keep the component's job equally narrow. It can render the captured values, label the observation moment, and provide a teaching action that submits one normal mutation. It should not inspect a diagnostic value and then decide to call replaceState() as an invisible correction. If the application needs a recovery action, make that action explicit in the service API and give it a separate explanation from the instrumentation that reported the problem.
The same discipline helps when a diagnostic view becomes telemetry. A teaching textarea can show a complete collection because the goal is to make the boundary concrete. An operational view should expose only the fields needed for the question it answers. That might mean counts, identifiers, status flags, or a redacted error category instead of the full State value. The observation API stays the same; the retention and presentation policy becomes more careful.
Finally, remove observations that no longer answer a useful question. A callback that remains forever because it was once helpful can turn into noise, memory pressure, or an accidental record of sensitive data. Bounded diagnostic code is easier to trust because its purpose, lifetime, and data shape are all visible next to the feature that owns it.
One mutation, several read-only views: the lab is most useful when every surface observes the same attempt. That makes differences visible without introducing a second path that can change the result.
Deeper Dive
Work through Chapter 12: State Introspection in the Angular tutorial, then run the same mutation through each observation surface. The FeatureCell reference explains the public state boundary, while the tutorial makes the boundary visible in a working diagnostic lab.
Top comments (1)
Keeping the diagnostic path observational is the key design choice. I would make the trace schema versioned and test that replaying a captured sequence cannot call reducers or emit a new state; otherwise a debugging tool can slowly become an undocumented control surface.