June 12, 2026 · 6 min read
Angular v22 templates: @boundary, smarter @switch, and inline arrow functions
A practical look at Angular v22 template improvements: multi-case @switch, exhaustive @default never checks, inline arrow functions, and the upcoming @boundary error boundary primitive.
Angular v22 is not only about bigger platform APIs. One of the most useful parts of the release is the steady cleanup happening inside templates.
The template layer has been getting more expressive for several releases: built-in control flow, @let, @defer, stronger type checking, and now better switch ergonomics.
Here is the practical version: what you can use now, what should change how you write templates, and what is coming next with @boundary.
1. @boundary is the feature to watch, not the feature to ship today
@boundary is Angular's upcoming template-level error boundary primitive. The idea is simple: wrap an unreliable subtree, catch failures from that subtree, and render fallback UI without taking down the rest of the page.
This matters for dashboards, checkout flows, third-party widgets, promotional blocks, live feeds, and any UI where one broken island should not turn the whole route into a blank screen.
The important production detail is timing. @boundary was announced with Angular v22, but the Angular team says it is expected as developer preview in Q3 2026. Treat it as a design direction today, not a stable production dependency yet.
Upcoming @boundary syntax · html
@boundary {
<app-promotional-widget />
} @error (let err) {
<app-default-promo-widget />
}- Use the pattern mentally now when designing risky UI zones.
- Keep unpredictable widgets isolated behind small rendering boundaries.
- Wait for the developer preview before committing production code to this syntax.
2. Multi-case @switch removes template duplication
The immediate improvement in v22 is that consecutive @case entries can share the same block. That sounds small until you look at real product states.
Most apps have multiple statuses that render the same UI: pending and queued, failed and rejected, paused and blocked, draft and scheduled. Previously you either duplicated markup or introduced a helper just to group cases.
Now the template can express that grouping directly.
Multiple cases sharing one branch · html
@switch (status) {
@case ('pending')
@case ('queued') {
<status-badge type="waiting" />
}
@case ('active') {
<status-badge type="running" />
}
@default {
<status-badge type="unknown" />
}
}- Less duplicated markup.
- Less pressure to create component methods only for display grouping.
- A template shape that is closer to the state model you already have in TypeScript.
3. @default never turns missing UI branches into compile errors
The more valuable switch improvement is exhaustive checking. If the switch value is a TypeScript union, @default never tells Angular that every valid member should already be handled above.
When the union grows and the template is not updated, Angular can report the missing case during template type checking instead of letting the UI silently fall into a generic default.
Angular v22 also improves this for nested discriminants. When the discriminant is a property such as data.type, pass the object to never so the checker can narrow the union correctly.
Exhaustive switch for nested discriminants · html
@let data = chartData();
@switch (data.type) {
@case ('line-chart') {
<line-chart [data]="data" />
}
@case ('bar-chart') {
<bar-chart [data]="data" />
}
@default never(data);
}- Use @default never for role, status, mode, variant, and entity-type unions.
- Use @default never(data) when the discriminant is a nested property.
- Avoid a generic default when missing a case would hide a real product bug.
4. Inline arrow functions are useful, but keep them boring
Angular v22 also relaxes a long-running template limitation: simple inline arrow functions are now valid in templates.
This does not mean templates should become a second component class. It means small callback-style expressions no longer need to be extracted into a method just to satisfy the framework syntax.
The rule I would use is straightforward: if the arrow function is a tiny callback and the surrounding expression remains readable, inline it. If it starts doing transformation work, branching, async behavior, or repeated heavy computation, move it to computed(), a signal, or a component method.
Small inline arrow function in a template statement · html
<p>Stock: {{ item().stock }}</p>
<button (click)="item.update((product) => ({
...product,
stock: product.stock - 1
}))">
Decrease stock
</button>- Good fit: small update callbacks and short predicates.
- Bad fit: complex filtering, mapping, sorting, and business rules.
- If reviewing the template takes more than a few seconds, extract it.
5. The bigger shift is templates becoming safer
The common thread is not syntax. It is resilience.
Multi-case switch reduces duplication. Exhaustive switch checking catches missing states before users do. Inline arrow functions remove minor ceremony. @boundary points toward UIs where one failed subtree does not destroy the page.
That is the template layer Angular has been moving toward: more local, more type-aware, and less dependent on defensive boilerplate in the component class.
- Use the new @switch features immediately for state-heavy UI.
- Be disciplined with inline arrows so templates stay readable.
- Track @boundary closely if your app renders third-party, dynamic, or high-risk UI regions.
Final take
Angular v22 is a reminder that framework ergonomics are not only about new APIs. Sometimes the biggest productivity gains come from making the code you already write shorter, safer, and harder to break.