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

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.