You have seen an unopinionated library (React), a progressive framework adopted in layers (Vue) and, before both of them, your own plain-JavaScript application where every decision was yours. Angular sits at the other end of the axis that 10-01 called "library versus framework": it is a complete platform, with a router, an HTTP client, a forms system, dependency injection, a testing environment, a code generator and server rendering included and maintained by the same team. And with TypeScript not as an option but as a de facto requirement. That makes it the most expensive of the three to learn and, at the same time, the most predictable: two Angular projects from different companies look far more alike than two React projects. In this lesson you will see what "opinionated" means when taken all the way; the minimum TypeScript needed to read the code —types, interfaces and decorators—, deferring to 11-07 to learn it properly; the CLI and a project's structure; standalone components with their imports, which today are the recommended form; the four kinds of data binding and the current control-flow syntax (@if, @for with its mandatory track —the same old data-id—, @switch and @defer); signals (signal, computed, effect, and signal-based inputs and outputs) as Angular's current reactivity model, compared with Vue's ref and computed, with a mention of Zone.js and the zoneless trend; dependency injection, which is the piece that most distinguishes Angular and which you already practiced without knowing it in 08-04; HttpClient and just enough RxJS —what a stream is, subscribe, pipe, the template's async and why you have to unsubscribe— applied to your listTasks from 07-02; the router with lazy loading, picking up 09-05; reactive forms with validators that reuse your rules R1–R10; testing with TestBed and a note about SSR. And at the end, the same task list with its filter, for the fourth time.

1. Angular as a complete platform
2. What "opinionated" means when taken all the way
3. TypeScript: the minimum needed to read this lesson
4. Decorators: what they are and why Angular uses them
5. The CLI and a project's structure
6. Standalone components
7. Template and styles: the three ways of writing them
8. Data binding in its four forms
9. The current control-flow syntax
10. @for and its mandatory track
11. @defer: declarative lazy loading
12. Signals: signal, computed and effect
13. Signal-based inputs and outputs
14. Zone.js, change detection and the zoneless trend
15. Angular's signals versus Vue's ref
16. Dependency injection: services and inject()
17. Why dependency injection sets Angular apart
18. The resemblance to what you did in 08-04
19. HttpClient and RxJS: just enough
20. The template's async and why you have to unsubscribe
21. When signals and when observables
22. The router with lazy loading
23. Reactive forms versus template-driven forms
24. Validators with rules R1–R10
25. Testing with TestBed
26. A note about SSR
27. Nómada Tasks in Angular: the complete list
28. Comparison with the three previous versions
29. Common Mistakes and Tips
30. Exercises
31. Conclusion

The difference starts with the inventory. This comes included, it is official and it is updated in step:

That last ng update row deserves attention because it is a rarely discussed consequence of having everything under one roof: when Angular changes an API, it publishes automatic migrations that rewrite your code. Updating a large Angular project is usually a matter of running a command and reviewing the result. In a React project with twenty third-party dependencies, each one updates at its own pace and the incompatibilities are yours. It is a real advantage of vertical integration, and it is the direct counterpart to 10-01's cost 5, ecosystem churn.

In practice, "opinionated" means five concrete things:

1. You do not choose tools, you choose Angular. There is no decision to make about the router, the HTTP client or the forms system. That removes decision fatigue and it also removes the possibility of using something better suited to your case.
2. The project structure is given. ng generate component task-card creates four files with predictable names, locations and content. Every project looks alike.
3. There is one correct way to do each thing, documented, and the rest of the community follows it.
4. The verbosity is deliberate. Angular prefers explicit and long over concise and magical. You will see more lines to do the same thing, and those lines say exactly what happens.
5. The curve is steeper at the start and flatter afterwards. There are more concepts to learn before being productive (dependency injection, decorators, observables), and fewer surprises once they are learned.

The profile where Angular shines is recognizable: large, long-lived applications, with sizable teams and staff turnover, typically internal or corporate. And the profile where it gets in the way is recognizable too: a prototype, a widget, a small website, one person in a hurry.

Angular is written in TypeScript and its documentation, its examples and its tooling take it for granted. It can be used with JavaScript, but nobody does and the ecosystem does not support it. So you need the minimum to read the code. This is not a TypeScript course: in 11-07 you will see what it is, why it has won and how to learn it properly. Here are four ideas.

TypeScript is JavaScript with type annotations. All valid JavaScript is valid TypeScript. The annotations are checked at compile time and disappear from the result: what runs in the browser is ordinary JavaScript.

Interfaces describe the shape of an object. They are documentation that the compiler checks:

Notice Priority. It is a literal union type, and it does something no comment achieves: if you write priority: 'urgent', the compiler rejects it before anything runs. The rules R1–R10 you have spent the whole course checking by hand become, to a large extent, things the compiler stops you from even expressing.

Generics are types with parameters. Task[] is an array of tasks; Signal<number> is a signal containing a number; Observable<Task[]> is a stream that emits arrays of tasks. They read as "X of Y".

Access modifiers are TypeScript's version of 05-03's encapsulation:

With one nuance worth knowing: TypeScript's private disappears at compile time and only protects during development, whereas JavaScript's #fields from 05-03 are genuinely private at runtime. Angular mostly uses private.

Decorators are the @ syntax you will see everywhere:

A decorator is a function that receives the class and attaches metadata to it. @Component({...}) does not change the class's behavior: it attaches information —what its template is, which selector it uses, which other components it imports— that Angular reads at compile time and at runtime.

The reason Angular uses them is consistent with its philosophy: configuration lives next to what it configures, declaratively and readably. In React that information is spread across the file name, the imports and the JSX; in Angular it is in an explicit object above the class.

To read this lesson it is enough to understand them as "metadata declared above a class". You do not need to write one.

Angular's CLI does much more than create projects:

ng generate component creates four files and registers them where appropriate:

That fourth file says a lot about Angular's opinions: the test is generated with the component, it is not added later if somebody feels like it. It is the same idea 08-03 argued for, turned into the tool's default behavior.

And the overall structure:

Compare with your js/model/, js/data/, js/view/, js/util/. The separation is the same one you chose; the difference is that here it is given and everybody uses it the same way.

For years, Angular organized everything into NgModules: a component did not exist until it was declared in a module, and modules imported other modules. It was a layer of indirection that was hard to explain and that was often unnecessary.

Today the recommended form is standalone components, which declare directly what they need:

The decorator's elements:

• selector is the HTML tag it is used with: <app-assignee-filter>. The app- prefix is the convention for avoiding collisions with native elements.
• template (or templateUrl) is the template.
• styles (or styleUrls) are the styles, scoped by default, like Vue's scoped in 10-04 but without having to ask for it.
• imports —not needed here because no external component or directive is used— lists what the template requires.

Standalone components are now the CLI's default. You will see a lot of older code with NgModule; it still works and there are automatic migrations, but for new code it is not the recommended form.

This is a real difference from Vue, and it cuts both ways. Angular by default uses three files for a component (logic, template, styles), which pushes the parts apart; but style scoping comes enabled without asking and the editor's tooling navigates between the three with no friction. For small components, the inline form gives you something very close to a .vue file.

Style scoping is implemented with unique attributes added by the compiler, just as in Vue. It can be switched to real Shadow DOM with encapsulation: ViewEncapsulation.ShadowDom, or disabled — which is almost never a good idea.

Angular has a very explicit syntax for distinguishing the direction of the data, and once learned it reads very well:

The official mnemonic is useful: the square brackets point inward (the data goes into the element), the parentheses point outward (the event comes out of the element), and [()] —"banana in a box"— does both.

And [(ngModel)] is, like Vue's v-model, pure sugar:

A property coming down and an event going up. Once again the unidirectional flow with a shortcut on top. A practical warning: ngModel belongs to FormsModule and has to be imported in the component; and for forms of any substance, Angular recommends the reactive forms of section 23, not ngModel.

For classes and styles there are specific forms:

For years Angular used structural directives with an asterisk (*ngIf, *ngFor, ngSwitch). Today there is a block syntax built into the compiler, which is the recommended one for new code:

Four advantages over the old directives, all of them practical:

1. Nothing needs importing. *ngIf required importing CommonModule or NgIf; forgetting it produced a silent failure where the content simply did not appear.
2. There is a real @else. With *ngIf you had to use <ng-template> and references, which was considerably more awkward.
3. @empty covers the empty state without an extra @if. It is exactly the case 06-06 forced you to handle separately.
4. The compiler understands it better and generates more efficient code, as well as better error messages.

Compare the three syntaxes for the same thing:

For the fourth time in the module, the same concept. And Angular is where it is best resolved, because track is not optional:

If you write @for without track, the code does not compile. It is not a console warning as in React or an ESLint rule as in Vue: it is a compilation error that prevents the project from building.

That decision sums up Angular's philosophy. Stable identity in lists is so important —you have known it since 06-06, when reconcile without data-id would have cost you the focus, the transitions and the internal state— that the framework does not let you forget it. It is "opinionated" in its most useful form: the opinion forces you to do the right thing.

The same three rules, with the same trap: track $index is allowed and is correct only if the list is never reordered or filtered. With an id available, use the id.

Angular also offers contextual variables inside the block:

Available: $index, $first, $last, $even, $odd, $count.

This block deserves attention of its own because it connects directly with 09-05 and because it has no equally integrated equivalent in the other frameworks:

What it does: the app-workload-report component and all of its dependencies are split into a separate chunk at build time, and they are only downloaded when the condition is met. The available triggers are on viewport, on interaction, on hover, on idle, on timer(…), on immediate, and when <expression>, plus prefetch on … to preload without rendering.

Compare with what you wrote in 09-05:

And with the IntersectionObserver with rootMargin that you also wrote. @defer does all of that —the code split, the trigger, the indicator with its minimum delay to avoid flicker, the reserved space that avoids CLS, and the failure handling— declaratively and checked by the compiler. It is exactly 10-01's argument: it is not that you did not know how to do it; it is that here you write it in eight lines of template and you cannot forget the error state.

Signals are Angular's current reactivity model, and their resemblance to Vue's refs is no coincidence: they are the same family 2 from 10-01.

The syntactic difference from Vue: where Vue uses .value (a property), Angular uses () (a call). The reason is the same as in 10-04's section 12 —JavaScript does not allow reading a variable to be intercepted—, solved with a different tool: a function instead of a getter.

computed declares a derived value, with a cache and automatic dependencies:

Semantically identical to Vue's computed: lazy, cached, composable, with dependencies discovered on read. And therefore also identical to your version cache from 09-02, with automatic invalidation.

effect runs side effects when its dependencies change:

With the same warning as useEffect and watch: effect is not for deriving values. Writing to a signal from inside an effect in order to compute something is the same antipattern you have already seen twice, and Angular explicitly discourages it (to the point that writing signals inside an effect requires a special option).

There is a relevant detail about immutability. A signal detects change by comparing with Object.is, like React and unlike Vue: there is no proxy intercepting the write to a nested property.

That is: in Angular with signals, 04-07's immutability is mandatory again, just as in React. It is a good example of the three families from 10-01 crossing over: Angular has fine-grained reactivity with an immutability requirement; Vue has fine grain with mutation allowed; React has a virtual DOM with mandatory immutability.

Communication between components uses input() and output(), which replace the @Input() and @Output() decorators of earlier Angular:

Important points:

• input.required<Task>() declares a required, typed input. If the parent does not pass it, it fails at compile time. Compare it with React's props, where only TypeScript catches it, or with Vue's defineProps, which validates at runtime in development.
• An input is a signal. It is read with task() and can be used directly as a dependency of a computed. That means overdue recomputes itself when the parent passes another task, with nothing resembling a dependency array.
• output<number>() declares a typed event. The parent listens with (advance)="…".
• LABEL is exposed as a property because Angular templates only see class members, not the module's imports. It is a real difference from JSX (where the file's whole scope is available) and from Vue (where <script setup> exposes everything automatically): in Angular it has to be made explicit.

To understand the Angular you will see in real projects you need to know where its reactivity comes from.

For almost all of its history, Angular did not know what had changed: it checked everything. The mechanism was Zone.js, a library that patches the browser's asynchronous APIs —setTimeout, addEventListener, fetch, Promise— to notify Angular every time something happens. On receiving the notification, Angular walks the component tree evaluating every expression in every template and comparing the results with the previous ones.

It works, and it is the reason Angular "just updates" when you mutate a property. But it has three costs: it checks far more than necessary; Zone.js has weight and patches global APIs, which complicates debugging and interoperability; and it gives no fine-grained information, so you have to optimize by hand with ChangeDetectionStrategy.OnPush.

Signals change that. Since a signal knows exactly which expressions read it, Angular can update only what depends on what changed. That is the foundation of the zoneless trend: applications where all reactivity goes through signals and Zone.js is no longer needed, so it disappears from the bundle and change detection becomes data-driven instead of poll-driven.

In practice, to write modern Angular the rule is: use signals for all state. If you do, the mental model is the same as Vue's and you do not need to think about Zone.js. But when reading existing code you will find ordinary class properties updating themselves: that is Zone.js at work, and now you know why.

Two rows deserve comment.

The immutability row is the most visible practical difference, and it comes with a compensation: since there is no proxy, Angular's signals are cheaper and more predictable; you never have to wonder whether an object is wrapped or whether a Map is reactive. In exchange, you write 04-07's immutable map on every update.

The destructuring row is a clear advantage of signals: since the value is obtained by calling a function, passing the signal elsewhere never breaks anything. The whole of 10-04's section 15 —Vue's four limits of reactivity— simply does not apply here. It is a case where the more awkward syntax (() on every read) buys a valuable property.

Here is what really sets Angular apart. The other two frameworks have nothing equivalent.

A service is a class with logic that does not belong to any component: data access, shared state, business rules, event logging.

And its use from a component:

Three things to understand about this code:

@Injectable({ providedIn: 'root' }) registers the service in the root injector. Angular creates a single instance and gives it to everybody who asks. It is a singleton, but managed by the framework instead of by a module exporting an object.

inject(TasksService) asks for the instance. There is no new, there is no import of a specific instance: you ask for the type and the injector decides what to give. That indirection is the key to everything that follows.

The state is in the service, not in the component. The pattern of a private writable _tasks plus a public read-only tasks (asReadonly()) is 05-03's encapsulation applied to state: the service is the only one that can change it, and components only read. It is exactly the discipline your Board class imposed with #tasks and the getter that returned a copy.

The reasonable question is: what does asking for inject(TasksService) add over importing an instance?

It means that whoever decides which instance is handed over is not whoever uses it. And from that come four capabilities:

1 · Substitution in tests. When testing the component, it is given a fake service without touching the component:

2 · Changing the implementation per environment. The same component uses a service against the real API in production and against local data in development, decided in the configuration.

3 · Different scopes. A service can be unique for the whole application (providedIn: 'root'), or one instance can be created per component if it is declared in its providers. That allows, for example, one state service for each open panel.

4 · Interceptors. HttpClient can be wrapped with interceptors that add authentication headers, retry (your withRetries from 07-03), log or handle errors, without any service or component finding out.

The cost, plainly stated: it is one more concept to learn, and one that does not exist in React or Vue. For a small application it is ceremony; for a large one with many layers and thorough testing, it is the piece that keeps the code decoupled.

And here is the connection that makes all of this feel familiar. In 08-04 you wrote this so you could test your repository:

That is dependency injection. Angular did not invent it: it is a design pattern that is decades old, and you applied it for the right reason —to be able to test without depending on localStorage. What Angular does is two further things:

1. Turn it into the norm, not something you do when somebody remembers.
2. Automate the wiring: in your version, whoever constructs LocalRepository has to know which store to pass it, and that knowledge propagates upward. With an injector, you declare once which implementation corresponds to each type and the framework resolves it across the whole tree.

If the pattern seemed useful to you in 08-04 —and it was, because without it those tests would have needed a real browser—, Angular gives it to you across the whole application with no additional effort.

HttpClient is the included HTTP client, and it returns observables instead of promises:

The minimum RxJS needed to read this, and no more:

An observable is a stream of values over time. A promise produces one value (or a failure) and finishes; an observable can produce zero, one or many, and it may never finish. A mouse click is a stream. A WebSocket —your BoardChannel from 07-04— is a stream. An HTTP request is a stream that emits one value and finishes, and that is why it looks like a promise with odd syntax.

subscribe starts the stream. An observable is lazy: until somebody subscribes, nothing happens. This is trap number one for anyone coming from promises: calling listTasks() without subscribe makes no request at all. A promise, by contrast, starts running as soon as it is created.

pipe chains operators. An operator transforms the stream and returns another stream. The ones that come up constantly:

switchMap deserves an example, because it elegantly solves 10-02's race condition:

That switchMap is the canonical answer to the problem you solved in React by aborting by hand and in Vue with onCleanup. When a new value arrives, the previous subscription is cancelled —and with it the HTTP request— and the new one is subscribed to. The race is impossible by construction.

And toSignal/toObservable are the bridges between the two worlds: they turn an observable into a signal and vice versa. They are the tool that lets you write the application with signals and use RxJS only where it contributes.

In the template, the async pipe subscribes and unsubscribes automatically:

It is the recommended form when working with observables in templates, precisely because it removes the unsubscribing problem.

And that problem is real. An observable that does not finish —a WebSocket, a stream of events, a timer— keeps its subscription alive even if the component disappears. It is literally 09-03's memory leak: the handler stays in memory, keeps processing, and keeps the component and its whole subtree alive.

takeUntilDestroyed is your destroy(), once again, with the call guaranteed by the framework. The three correct ways of handling unsubscription, in order of preference: the async pipe in the template, takeUntilDestroyed, and —if there is no other way— storing the subscription and calling unsubscribe() in ngOnDestroy.

Angular now has two reactive systems coexisting, which is disconcerting. The current criterion is reasonably clear:

In practice, modern Angular tends towards: signals for almost all the application's state, RxJS for the data layer and complex interactions, and toSignal at the boundary. It is a model with more pieces than Vue or React, and that is a legitimate criticism of Angular's learning curve — with the counterpart that RxJS solves asynchronous coordination problems that in the other frameworks are solved by hand or with libraries.

That loadComponent with a dynamic import() is exactly 09-05's code splitting, integrated into the router: each route is compiled into its own chunk and is only downloaded when you navigate to it. It is the "Angular ships code splitting in the router" line that 09-05 announced.

And there is a piece your router.js did not have: guards. canActivate runs a function before activating the route and can block the navigation or redirect:

In the template, navigation is done with directives:

routerLink generates a real <a href> —important for accessibility and SEO— and intercepts the click to navigate without reloading, which is exactly what your router did with the History API in 07-06.

Angular includes two systems, and this is the comparison that decides which to use:

Reactive forms in action:

A validator is a pure function that receives the control and returns null if it is valid or an error object if it is not. That is: exactly the shape of your validation functions from 03-03, with a different signature.

Three observations:

• They are pure functions and are tested with Jest without Angular. notOnlyWhitespace({value: ' '} as AbstractControl) returns {onlyWhitespace: true}. It is the same ease of testing your validators from 03-03 and your reducers from 10-03 had.
• weeklyLimit is a validator factory —a function that returns a function, from 03-06— because it needs external data. And it is a group validator, because R7 depends on two fields at once.
• The error object carries data, not just true. That allows specific messages: "Iván would reach 45 h out of the 40 allowed" instead of "error". It is the same idea as your ValidationError with .field from js/model/errors.js.

Angular brings its own environment, which sets up a mini-injector for the test:

The line that matters is providers: [{ provide: TasksService, useValue: fakeService }]. That is what dependency injection buys. The component asks for TasksService; in production it gets the real one, in the test it gets the double, and the component neither changes nor finds out. It is exactly what you did by hand in 08-04 by passing InMemoryStore to LocalRepository's constructor, with the wiring automated.

Angular includes Karma and Jasmine by default, but Jest or Vitest can be used, and Testing Library has an Angular version, with the same queries by role you have been using since 08-05. The philosophy of testing what the user sees does not change with the framework.

Angular includes server rendering with no external libraries:

That adds a server that renders the HTML before sending it, with hydration on the client so that the page remains interactive, and support for incremental hydration combined with @defer, which lets you decide which parts are hydrated and when.

We do not develop it here: client, server, static and hybrid rendering is the topic of the next lesson, where you will see why that decision usually matters more than the framework decision.

The fourth and last version of the same screen. The domain, in TypeScript but conceptually identical:

The service, which is where the state lives:

The card is the one from section 13. The list:

And the root component:

The canonical numbers, checked: with no filter, "6 of 6 tasks · 45 h open". With "Iván", "3 of 6 · 25 h". With "Lucía", "1 of 6 · 14 h". With "Marta", "2 of 6 · 6 h".

And the metrics for the same screen, with all four versions:

What Angular wins, with no embellishment: total cohesion. Everything fits because the same team built it. Typing comes as standard and catches errors before anything runs. The mandatory track prevents a real bug. Injected services give you shared state and testability with nothing installed. Automatic migrations make ten-year update horizons viable. And two different projects look alike, which reduces the cost of onboarding somebody.

What it loses, with the same frankness: it is the most expensive to learn, by a wide margin. TypeScript, decorators, dependency injection, signals, RxJS and two forms systems are a lot to take on before the first screen. It is the most verbose: 180 lines against 120 for the same thing. It is the heaviest at startup. And it is the one that fits worst in small projects, where all that infrastructure has nothing to hold up.

Forgetting the parentheses when reading a signal. task.title instead of task().title compares or accesses on the function, not on the value. In the template, {{ tasks }} displays the function's code. TypeScript catches many of these cases, but not all.

Mutating a signal's value. tasks()[0].status = 'done' triggers nothing: signals compare with Object.is. You have to use update with an immutable map, as in React.

Forgetting imports in a standalone component. If the template uses <app-task-card> or [formGroup] and it is not in imports, the compilation error is clear but disconcerting at first. It is the price of every component declaring what it needs.

Using class properties instead of signals. It works because of Zone.js, but it is the old model: you lose the fine grain, you rule out the zoneless strategy and you mix two reactivity systems. For new code, signals.

Calling a method in the template instead of a computed. {{ computeHours() }} runs on every change-detection cycle, which with Zone.js can be an enormous number of times per second. computed is cached. It is the classic cause of an Angular application being slow for no apparent reason.

Not subscribing to an observable. Observables are lazy: without subscribe, nothing happens. It is trap number one for anyone coming from promises, which run as soon as they are created.

Not unsubscribing. It is 09-03's memory leak under another name. Use the async pipe in the template or takeUntilDestroyed; never leave a subscription to an infinite stream unmanaged.

Putting business logic in the components. In Angular it is especially avoidable because services exist precisely for that, with injection and testing included. 10-01's discipline applies just the same: the domain is pure TypeScript, the component paints.

Using ngModel for complex forms. Angular recommends reactive forms for anything non-trivial: typing, asynchronous validation, dynamic fields and testing without rendering.

Tip: learn TypeScript before Angular. Trying to learn both at once multiplies the confusion, because you will not know whether an error is the language's or the framework's. Lesson 11-07 is the starting point.

Tip: start with signals and leave RxJS for the data layer. Modern Angular lets you write almost the whole application with signals and use observables only where they contribute —HTTP, WebSocket, sequences with cancellation. toSignal is the bridge.

Tip: always use ng generate. It generates the correct structure, the test file and the necessary registrations. Writing components by hand is a source of silly errors that the CLI avoids.

Translate this React component (from 10-02) into a standalone Angular component with signals. Keep the same behavior and respect rules R6 and R10.

Indicate in comments what corresponds to useState, to the props and to the derived computation.

Write a BoardApiService service that:

1. Exposes tasks, loading and error as read-only signals.
2. Has a filterBy(assignee: string | null) method that updates an internal signal.
3. Loads the tasks from the server every time the assignee changes, with debounceTime(300) and cancelling the previous request.
4. Retries three times with half a second of waiting on a network failure.
5. On a definitive error, leaves the list empty and fills in error without breaking the stream.

Use toObservable, switchMap, retry, catchError and toSignal. Explain which operator solves 10-02's race condition and why.

Write three pure functions, with no Angular dependencies in their logic, and their tests:

1. An hoursInRange validator for R3 (greater than 0, maximum 40) that returns an error with data useful for the message.
2. A canAdvance(currentStatus, target) function that implements R6 using NEXT, and explain why it is not a form validator.
3. A dateConsistentWithStatus group validator that applies R10 the other way round: if the status is 'done', a past due date must not flag an error; if it is not 'done' and the date has already passed, it must return a warning (not a blocking error).

Then answer: why is it a good idea for these functions to live in domain/ and not in the component?

Solution 1

Notable differences from the original:

• The rows are transformed into an array of objects with name inside, instead of [key, value] pairs. In Angular's template, @for's destructuring is more limited than in JSX, and an object reads better.
• track row.name is mandatory: without it, the project does not compile. In the React version, key was a warning you could ignore.
• The grouping logic could —and probably should— live in domain/workload.ts as a pure function, leaving the component with the presentation only. With the canonical backlog it returns: Iván 3 / 25 h, Lucía 1 / 14 h, Marta 1 / 6 h.

Solution 2

Which operator solves the race condition: switchMap. Its semantics are "switch to the new stream and cancel the subscription to the previous one". When Marta goes from "Iván" to "Lucía", Iván's request is cancelled the moment Lucía's value arrives. When the subscription is cancelled, HttpClient aborts the underlying HTTP request —internally it uses the same mechanism as your AbortController from 07-03—, so its response never reaches the tap or the toSignal. The race is impossible by construction, not because of a check somebody wrote.

Compare the three solutions to the same problem:

Two details of the code: catchError returns of([]) instead of rethrowing, because if the error propagates, the stream ends and filterBy stops working forever — it is the classic RxJS mistake. And retry goes inside the switchMap, applied to the specific request; if it were outside, it would retry the whole outer stream, debounceTime included.

Solution 3

The tests, with Jest and without Angular:

Why canAdvance is not a form validator. A validator checks whether an entered value is acceptable. R6 is not about values but about transitions: it depends on the previous status, which is not in the form. It is a model rule, and its natural place is the service —where advance() already applies it— and the button, which is disabled when NEXT[status] is null. Putting transition rules in the forms layer is a placement error that ends up duplicating the logic.

Why the domain goes in domain/. Four reasons, and you have seen all four already in this module:

1. It is tested without a framework. The tests above run in milliseconds, with no TestBed, no jsdom and nothing rendered.
2. It is reused across all the layers. The component, the service, the router and —if the server shares code— the API all use the same functions.
3. It outlives the framework. It is exactly 10-01's discipline: domain/rules.js has been the same file in all four versions of this screen. Changing framework means rewriting the view, not the application.
4. It is where the business is read. Somebody who wants to know which rules govern Nómada Tasks opens one folder, they do not rummage through the components.

You have seen the module's fourth and last approach, and the most different of them all.

You know what Angular as a complete platform is: a router, an HTTP client, two forms systems, dependency injection, RxJS, code generation, a testing environment, internationalization, SSR and automatic migrations, all official and updated in step. You understand what "opinionated" means when taken all the way —you do not choose tools, the structure is given, there is one correct way to do each thing, the verbosity is deliberate, and the curve is steep at the start and flat afterwards— and which project profile it pays off in: large, long-lived applications with sizable teams and staff turnover.

You have the minimum TypeScript needed to read the code —annotations that disappear at compile time, interfaces that describe an object's shape, literal union types that turn rules R1–R10 into things the compiler will not let you express, generics that read as "X of Y", and access modifiers with the nuance that private is not #private—, with the pointer to 11-07 for learning it properly. And you know what decorators are: metadata declared above a class, consistent with the philosophy that configuration lives next to what it configures.

You know the CLI and what it says about Angular's opinions —that ng generate component creates a test file by default is not a small detail—, and standalone components with their imports, which today replace NgModules. You are fluent in the four kinds of data binding with the mnemonic of square brackets pointing inward and parentheses pointing outward, and [(ngModel)] demystified like Vue's v-model: a property coming down and an event going up. And you handle the current control-flow syntax —@if/@else, @for with @empty, @switch— with its four advantages over the old directives, and @defer with its triggers, its @placeholder, its @loading and its @error, which declaratively does everything you wrote by hand in 09-05.

You know that @for's track is mandatory and that without it the project does not compile: the same stable key as your reconcile from 06-06, raised from a warning to an error, which is "opinionated" in its most useful form. You are fluent in signals —signal with set and update, a cached and lazy computed, effect with its cleanup— and you know that, unlike Vue, they compare with Object.is and therefore 04-07's immutability is mandatory again, with the counterpart that a signal is never lost on destructuring. You know Zone.js and why it existed —checking everything because there was no knowing what had changed— and the zoneless trend that signals make possible.

You understand dependency injection: services with @Injectable({providedIn: 'root'}), inject() asking for a type instead of importing an instance, the pattern of a private writable signal plus a public read-only signal which is 05-03's encapsulation applied to state, and the four capabilities it buys —substituting in tests, changing per environment, controlling the scope, and intercepting. And you know that you already practiced it in 08-04, when you passed InMemoryStore to LocalRepository's constructor so you could test without localStorage: Angular makes that pattern the norm and automates the wiring.

You have just enough RxJS: an observable is a stream of values over time, it is lazy and nothing happens without subscribe —trap number one for anyone coming from promises—, pipe chains operators, and the seven that always come up all have an equivalent in something you already wrote: map, filter, retry (your withRetries), catchError, debounceTime (your debounce from 09-02), switchMap (your AbortController) and takeUntilDestroyed (your destroy()). You know why you have to unsubscribe —it is 09-03's leak under another name— and the three correct ways of doing it, and you have the criterion for choosing between signals and observables, with toSignal and toObservable as the bridges.

You know the router with lazy loading via loadComponent, which is 09-05's dynamic import() integrated, with guards your router.js did not have; reactive forms versus template-driven ones with the table that decides; and validators that are pure functions implementing R2, R4, R7 and R9, with errors that carry data so as to produce useful messages, in the same vein as your ValidationError with .field. And you know how to test with TestBed, where the line providers: [{provide: TasksService, useValue: fake}] is the practical demonstration of what dependency injection buys.

You have written the fourth version of the same screen —~180 lines, with the domain in TypeScript but conceptually identical to the three previous ones— and you have the complete comparison table: Angular wins on cohesion, typing as standard, mandatory track, injected services, automatic migrations and predictability across projects; and it loses on learning curve, verbosity, weight and fit in small projects.

You have now seen all four approaches with the same screen written four times. What remains is the question that gives the whole module its point, and that has no single answer: how you choose. In the last lesson you are going to put the four versions side by side with their metrics, rank the criteria that really matter —product, team, market, longevity, performance, SEO, accessibility, cost—, and discover that there is one decision that usually weighs more than the framework one: where the rendering happens. And you will close by connecting with the final project, which is built in plain JavaScript and which from now on will be an informed decision: Choosing the Right Framework.