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.
Top comments (0)