مقدمه؛ Angular 22 چرا مهم است؟

Angular 22 از آن نسخه هایی نیست که فقط چند API جدید اضافه کرده باشد و تمام. این نسخه بیشتر شبیه یک پیام واضح از طرف تیم Angular است:

Angular دارد به سمت یک فریم ورک سریع تر، reactive تر، کم boilerplate تر و آماده تر برای پروژه های بزرگ و AI-assisted development حرکت می کند.

در چند نسخه اخیر، Angular آرام آرام از مدل قدیمی خودش فاصله گرفت:
کمتر وابسته به NgModule، کمتر وابسته به zone.js، بیشتر متکی به Signals، و نزدیک تر به یک معماری explicit و قابل پیش بینی.

Angular 22 این مسیر را جدی تر می کند.

در این مقاله تغییرات مهم Angular 22 را کامل بررسی می کنیم؛ از Signal Forms و resource گرفته تا @Service، injectAsync، تغییرات Router، تغییرات Template، پیش فرض شدن OnPush، بهبودهای SSR، ابزارهای AI و Breaking Changes مهمی که قبل از آپدیت باید بدانید.

خلاصه تغییرات Angular 22

اگر بخواهیم Angular 22 را در چند خط خلاصه کنیم، مهم ترین تغییرات این ها هستند:

Signal Forms حالا production-ready شده
Angular Aria پایدار شده
resource و httpResource آماده استفاده در production هستند
@Service() به عنوان جایگزین ساده تر برای @Injectable({ providedIn: 'root' }) معرفی شده
injectAsync برای lazy loading سرویس ها آمده
Router با Navigation API مرورگر بهتر هماهنگ شده
کنترل های جدیدی برای cleanup کردن route-level injectors اضافه شده
Templateها قابلیت هایی مثل comment داخل تگ، spread syntax، arrow function و @switch بهتر گرفته اند
OnPush برای کامپوننت هایی که changeDetection ندارند، پیش فرض شده
ChangeDetectionStrategy.Default عملاً با نام جدید ChangeDetectionStrategy.Eager قابل استفاده است
Fetch backend به default جدید HTTP تبدیل شده
Incremental hydration حالا رفتار پیش فرض شده
چند API قدیمی مثل ComponentFactoryResolver حذف شده اند
پشتیبانی از TypeScript 6 اضافه شده
Angular وارد فاز جدی تری از AI tooling، MCP و WebMCP شده

اما بیایید یکی یکی و با مثال جلو برویم.

1. Signal Forms؛ فرم های جدید Angular آماده production شدند

یکی از مهم ترین تغییرات Angular 22، production-ready شدن Signal Forms است.

تا قبل از این، Angular دو مسیر اصلی برای فرم ها داشت:

Reactive Forms
Template-driven Forms

هر کدام هم مزایا و دردسرهای خودشان را داشتند.

Reactive Forms برای پروژه های بزرگ عالی بود، ولی boilerplate زیادی داشت.
Template-driven Forms ساده تر بود، ولی برای فرم های بزرگ و پیچیده خیلی قابل اتکا نبود.

Signal Forms آمده تا چیزی بین این دو دنیا بسازد:

reactive مثل Reactive Forms
declarative مثل Template-driven Forms
strongly typed
هماهنگ با Signals
مناسب فرم های بزرگ و enterprise

مثال ساده Signal Forms

import { Component, signal } from '@angular/core';
import { form, required, min } from '@angular/forms/signals';

@Component({
  selector: 'app-payment-form',
  templateUrl: './payment-form.html',
})
export class PaymentFormComponent {
  readonly paymentModel = signal({
    paymentType: '',
    amount: 0,
  });

  readonly paymentForm = form(this.paymentModel, schema => {
    required(schema.paymentType, {
      message: 'روش پرداخت الزامی است',
    });

    min(schema.amount, 1, {
      message: 'مبلغ باید بیشتر از صفر باشد',
    });
  });
}

Template:

<form>
  <label for="paymentType">روش پرداخت</label>

  <select id="paymentType" [formField]="paymentForm.paymentType">
    <option value="">انتخاب کنید</option>
    <option value="card">کارت بانکی</option>
    <option value="wallet">کیف پول</option>
  </select>

  @if (paymentForm.paymentType().invalid() && paymentForm.paymentType().touched()) {
    <p class="error">
      @for (error of paymentForm.paymentType().errors(); track error.kind) {
        <span>{{ error.message }}</span>
      }
    </p>
  }

  <label for="amount">مبلغ</label>
  <input id="amount" type="number" [formField]="paymentForm.amount" />

  <button type="submit" [disabled]="paymentForm().invalid()">
    پرداخت
  </button>
</form>

نکته مهم اینجاست که فرم به جای اینکه صرفاً یک object جدا مثل FormGroup باشد، مستقیماً با state سیگنالی شما کار می کند.

یعنی model شما این است:

readonly paymentModel = signal({
  paymentType: '',
  amount: 0,
});

و فرم هم روی همین model ساخته می شود.

چرا Signal Forms مهم است؟

در پروژه های واقعی، فرم ها معمولاً ساده نیستند. مخصوصاً در پنل های مدیریتی، داشبوردها، فرم های مالی، سیستم های منابع انسانی، CRM، ERP و پروژه های سازمانی.

معمولاً با این چیزها طرف هستیم:

validationهای پیچیده
async validation
conditional fields
dynamic fields
فرم های چندمرحله ای
وابستگی بین فیلدها
sync شدن فرم با state
نیاز به type safety

Signal Forms قرار است این مدل را ساده تر و predictableتر کند.

بهبودهای Signal Forms در Angular 22

در Angular 22 فقط اسم Signal Forms عوض نشده؛ چند بهبود مهم هم آمده:

APIهای Signal Forms public و production-ready شده اند
مستندات کامل تر شده
پشتیبانی بهتر از Angular Material
پشتیبانی بهتر از Angular Aria
async validation بهتر شده
debounce برای validationهای async اضافه شده
امکان trigger دستی validation با reloadValidation
بهبود performance با lazy instantiate شدن fieldها
بهبود interop با ControlValueAccessor
بهتر شدن reset و sync فرم با model

مثال ذهنی برای async validation

فرض کنید می خواهیم username را چک کنیم که تکراری نباشد. ایده کلی در Signal Forms این است که validation مستقیماً بخشی از schema فرم می شود، نه یک منطق پراکنده در چند جای component.

readonly registerModel = signal({
  username: '',
  email: '',
});

readonly registerForm = form(this.registerModel, schema => {
  required(schema.username, {
    message: 'نام کاربری الزامی است',
  });

  required(schema.email, {
    message: 'ایمیل الزامی است',
  });

  // در Angular 22 validationهای async بهتر و قابل کنترل تر شده اند.
  // برای مثال می توان validationهای async را debounce کرد
  // یا در زمان لازم دوباره اجرا کرد.
});

مزیت اصلی این مدل این است که فرم، validation و state همگی به مدل reactive نزدیک تر می شوند.

2. Angular Aria؛ ساخت کامپوننت های accessible بدون ساختن همه چیز از صفر

یکی دیگر از قابلیت هایی که در Angular 22 production-ready شده، Angular Aria است.

هدف Angular Aria این نیست که مثل Angular Material به شما component آماده با ظاهر مشخص بدهد.
هدفش این است که primitiveهای accessibility را بدهد تا بتوانید componentهای اختصاصی خودتان را بسازید.

یعنی شما UI و style را خودتان می سازید، ولی Angular Aria کمک می کند رفتارهای مهم accessibility درست پیاده شوند.

مثلاً برای patternهایی مثل:

Button
Menu
Dialog
Listbox
Combobox
Tabs
Tree
Tooltip
و چند الگوی رایج دیگر

چرا Angular Aria مهم است؟

در پروژه های واقعی، مخصوصاً design systemها، معمولاً تیم نمی خواهد UI آماده Material را دقیقاً همان طور استفاده کند.
تیم طراحی style خودش را دارد، component library خودش را دارد، اما accessibility همچنان باید درست باشد.

مشکل اینجاست که accessibility فقط aria-label زدن نیست.

برای مثال یک dropdown واقعی باید این ها را درست مدیریت کند:

keyboard navigation
focus management
screen reader behavior
active item
disabled item
escape behavior
tab behavior
aria roles
aria attributes

Angular Aria کمک می کند این منطق ها استانداردتر و قابل اعتمادتر شوند.

نمونه ذهنی استفاده

<button
  type="button"
  aria-haspopup="menu"
  [attr.aria-expanded]="isOpen()"
  (click)="toggleMenu()"
>
  گزینه ها
</button>

@if (isOpen()) {
  <div role="menu">
    <button role="menuitem">ویرایش</button>
    <button role="menuitem">حذف</button>
  </div>
}

در حالت عادی باید تمام keyboard behavior و focus management را خودمان درست کنیم. Angular Aria قرار است همین بخش های رفتاری را با primitiveهای آماده تر و قابل اتکاتر ساده کند.

3. resource و httpResource؛ async state به سبک Angular جدید

یکی از تغییرات مهم Angular در مسیر Signal-first، معرفی APIهایی برای async reactivity است.

تا قبل از این، برای گرفتن دیتا از API معمولاً این مدل را داشتیم:

users$ = this.http.get<User[]>('/api/users');

و در template:

@if (users$ | async; as users) {
  @for (user of users; track user.id) {
    <p>{{ user.name }}</p>
  }
}

این مدل همچنان کار می کند و RxJS هنوز در Angular مهم است.
اما برای خیلی از سناریوهای ساده، ما فقط یک state async می خواهیم:

loading
value
error
reload
dependency روی یک signal دیگر

اینجاست که resource و httpResource وارد می شوند.

مثال با resource

import { Component, computed, resource, signal } from '@angular/core';

type Weather = {
  temperature: number;
  condition: string;
};

async function fetchWeather(city: string): Promise<Weather> {
  const response = await fetch(`/api/weather?city=${city}`);
  return response.json();
}

@Component({
  selector: 'app-weather',
  templateUrl: './weather.html',
})
export class WeatherComponent {
  readonly selectedCity = signal('Tehran');

  readonly weatherResource = resource({
    params: () => ({
      city: this.selectedCity(),
    }),
    loader: ({ params }) => fetchWeather(params.city),
  });

  readonly temperatureText = computed(() => {
    if (this.weatherResource.hasValue()) {
      return `${this.weatherResource.value().temperature}°`;
    }

    return 'در حال دریافت اطلاعات هواشناسی...';
  });

  changeCity(city: string) {
    this.selectedCity.set(city);
  }
}

Template:

<select
  [value]="selectedCity()"
  (change)="changeCity($any($event.target).value)"
>
  <option value="Tehran">Tehran</option>
  <option value="Paris">Paris</option>
  <option value="Berlin">Berlin</option>
</select>

<p>{{ temperatureText() }}</p>

نکته مهم اینجاست:

وقتی selectedCity تغییر کند، resource دوباره اجرا می شود، چون dependency آن به صورت reactive مشخص شده.

مثال با httpResource

برای HTTP، Angular یک API ساده تر هم دارد: httpResource.

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

type User = {
  id: number;
  name: string;
  email: string;
};

@Component({
  selector: 'app-user-details',
  templateUrl: './user-details.html',
})
export class UserDetailsComponent {
  readonly userId = signal(1);

  readonly user = httpResource<User>(() => {
    return `/api/users/${this.userId()}`;
  });

  nextUser() {
    this.userId.update(id => id + 1);
  }
}

Template:

@if (user.isLoading()) {
  <p>در حال دریافت کاربر...</p>
} @else if (user.error()) {
  <p>خطا در دریافت اطلاعات کاربر</p>
} @else if (user.hasValue()) {
  <article>
    <h2>{{ user.value().name }}</h2>
    <p>{{ user.value().email }}</p>
  </article>
}

<button (click)="nextUser()">کاربر بعدی</button>

آیا resource جای RxJS را می گیرد؟

نه کامل.

برای streamهای پیچیده، eventهای چندمرحله ای، cancellationهای خاص، compositionهای advanced و اپلیکیشن هایی که شدیداً RxJS محور هستند، RxJS هنوز مهم است.

اما برای خیلی از UI stateهای ساده، resource و httpResource خواناتر و مستقیم تر هستند.

به زبان ساده:

برای async data ساده و وابسته به signal، resource عالی است
برای HTTP ساده، httpResource خیلی تمیز است
برای streamهای پیچیده، RxJS هنوز انتخاب قدرتمندی است

4. @Service؛ سرویس ها تمیزتر می شوند

تا امروز برای ساختن یک singleton service معمولاً این را می نوشتیم:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class UserStore {
  private users: string[] = [];

  add(user: string) {
    this.users.push(user);
  }

  getAll() {
    return [...this.users];
  }
}

در Angular 22، decorator جدید @Service() معرفی شده:

import { Service } from '@angular/core';

@Service()
export class UserStore {
  private users: string[] = [];

  add(user: string) {
    this.users.push(user);
  }

  getAll() {
    return [...this.users];
  }
}

این تغییر شاید در نگاه اول کوچک باشد، ولی در پروژه های بزرگ مهم می شود.

وقتی یک پروژه ۲۰۰ یا ۳۰۰ سرویس دارد، حذف boilerplateهای تکراری باعث می شود کد تمیزتر و خواناتر شود.

پس @Injectable حذف شده؟

نه.

@Injectable هنوز وجود دارد و برای سناریوهای خاص تر همچنان کاربرد دارد.

مثلاً وقتی provider configuration خاص می خواهید، یا factory، یا useClass/useExisting/useFactory و موارد پیشرفته تر دارید، احتمالاً هنوز با @Injectable یا provider config کار می کنید.

اما برای اکثر singleton serviceهای ساده، @Service() خواناتر است.

5. injectAsync؛ lazy loading برای سرویس ها

Angular همیشه lazy loading برای route و component را خوب پشتیبانی می کرد.
اما سرویس ها معمولاً وقتی import می شدند، وارد bundle می شدند.

Angular 22 با injectAsync این مسیر را بهتر کرده.

ایده ساده است:

بعضی dependencyها را فقط وقتی واقعاً لازم شدند load کن.

مثال injectAsync

فرض کنید یک سرویس export سنگین داریم:

// report-exporter.ts
import { Service } from '@angular/core';

@Service()
export class ReportExporter {
  export() {
    console.log('Exporting report...');
  }
}

حالا در component:

import { Component, injectAsync } from '@angular/core';

@Component({
  selector: 'app-report',
  template: `
    <button (click)="exportReport()">
      Export
    </button>
  `,
})
export class ReportComponent {
  private readonly exporter = injectAsync(() => import('./report-exporter'));

  async exportReport() {
    const exporter = await this.exporter();
    exporter.export();
  }
}

در این مدل، ReportExporter تا زمانی که واقعاً نیاز نشده، load نمی شود.

prefetch با onIdle

حتی می توانید به Angular بگویید dependency را وقتی مرورگر idle شد، از قبل آماده کند:

import { Component, injectAsync, onIdle } from '@angular/core';

@Component({
  selector: 'app-report',
  template: `
    <button (click)="exportReport()">
      Export
    </button>
  `,
})
export class ReportComponent {
  private readonly exporter = injectAsync(() => import('./report-exporter'), {
    prefetch: onIdle,
  });

  async exportReport() {
    const exporter = await this.exporter();
    exporter.export();
  }
}

این برای dependencyهای سنگین خیلی مهم است؛ مثلاً:

export به Excel/PDF
charting library
editor سنگین
map library
report builder
image processing
featureهای کم استفاده ولی سنگین

6. Router در Angular 22 هوشمندتر شده

Router در Angular 22 چند تغییر مهم گرفته که بیشتر به performance، memory management و هماهنگی با browser platform مربوط است.

هماهنگی با Navigation API مرورگر

Angular Router حالا می تواند با Navigation API مرورگر بهتر هماهنگ شود.

برای فعال سازی:

import { ApplicationConfig } from '@angular/core';
import {
  provideRouter,
  withExperimentalPlatformNavigation,
} from '@angular/router';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withExperimentalPlatformNavigation(),
    ),
  ],
};

این قابلیت کمک می کند Router بهتر با navigation lifecycle مرورگر هماهنگ شود.

نتیجه اش می تواند این ها باشد:

رفتار بهتر هنگام back/forward
scroll behavior طبیعی تر
کنترل بهتر روی navigationهای داخلی
امکان ساده تر برای global loading indicator
هماهنگی بهتر با accessibility announcementها هنگام تغییر صفحه

cleanup خودکار route-level injectors

در Angularهای جدید، ما زیاد از route-level providers استفاده می کنیم:

export const routes = [
  {
    path: 'dashboard',
    providers: [DashboardStore],
    loadComponent: () =>
      import('./dashboard/dashboard.component')
        .then(m => m.DashboardComponent),
  },
];

این عالی است، چون provider فقط برای همان route ساخته می شود.

اما سؤال مهم:

وقتی کاربر از route خارج شد، تکلیف injectorهای route چه می شود؟

Angular 22 یک option جدید برای cleanup خودکار injectors معرفی کرده:

import { ApplicationConfig } from '@angular/core';
import {
  provideRouter,
  withExperimentalAutoCleanupInjectors,
} from '@angular/router';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withExperimentalAutoCleanupInjectors(),
    ),
  ],
};

این قابلیت کمک می کند resourceهایی که دیگر active نیستند، بهتر آزاد شوند.

برای پروژه های بزرگ، مخصوصاً dashboardها و admin panelها، این موضوع می تواند جلوی memory leakهای ریز ولی آزاردهنده را بگیرد.

destroyDetachedRouteHandle برای RouteReuseStrategy

اگر تا حالا با RouteReuseStrategy سفارشی کار کرده باشید، می دانید cleanup کردن routeهای cache شده همیشه خیلی تمیز نبود.

در Angular 22، API عمومی تری برای destroy کردن detached route handle اضافه شده:

import {
  DetachedRouteHandle,
  destroyDetachedRouteHandle,
} from '@angular/router';

export class RouteCacheService {
  private readonly handles = new Map<string, DetachedRouteHandle>();

  store(key: string, handle: DetachedRouteHandle) {
    this.handles.set(key, handle);
  }

  clear(key: string) {
    const handle = this.handles.get(key);

    if (handle) {
      destroyDetachedRouteHandle(handle);
      this.handles.delete(key);
    }
  }

  clearAll() {
    for (const handle of this.handles.values()) {
      destroyDetachedRouteHandle(handle);
    }

    this.handles.clear();
  }
}

این برای پروژه هایی که tab-like navigation دارند یا route caching انجام می دهند خیلی کاربردی است.

تغییرات دیگر Router

چند تغییر دیگر هم در Router مهم اند.

paramsInheritanceStrategy حالا پیش فرضش always است

قبلاً مقدار پیش فرض paramsInheritanceStrategy برابر emptyOnly بود.
در Angular 22 مقدار پیش فرض به always تغییر کرده.

یعنی routeهای child به شکل پیش فرض params والدها را inherit می کنند.

اگر رفتار قبلی را می خواهید:

provideRouter(routes, {
  paramsInheritanceStrategy: 'emptyOnly',
});

provideRoutes حذف شده

اگر جایی هنوز از provideRoutes() استفاده کرده اید، باید به provideRouter() یا ROUTES multi token مهاجرت کنید.

قبل:

provideRoutes(routes);

بعد:

provideRouter(routes);

CanMatchFn حالا currentSnapshot را لازم دارد

اگر guard شما از CanMatchFn یا interface کلاسیک CanMatch استفاده می کند، باید signature جدید را بررسی کنید.

نمونه functional:

import { inject } from '@angular/core';
import { CanMatchFn, Router } from '@angular/router';

export const authCanMatch: CanMatchFn = (
  route,
  segments,
  currentSnapshot,
) => {
  const router = inject(Router);
  const isLoggedIn = Boolean(localStorage.getItem('token'));

  return isLoggedIn || router.parseUrl('/login');
};

7. تغییرات Template؛ Angular templateها مدرن تر شده اند

Angular 22 چند تغییر جذاب در template syntax دارد. این تغییرات کوچک به نظر می رسند، ولی در نوشتن UIهای واقعی خیلی به readability کمک می کنند.

کامنت داخل HTML element

قبلاً اگر می خواستید درباره یک binding توضیح بدهید، خیلی دستتان باز نبود.
در Angular 22 می توانید داخل خود opening tag کامنت بگذارید:

<button
  // وقتی فرم invalid است، دکمه غیرفعال می شود
  [disabled]="paymentForm().invalid()"

  /*
    این کلاس فقط برای حالت loading است
    تا کاربر چند بار submit نکند
  */
  [class.is-loading]="isSubmitting()"
>
  ثبت اطلاعات
</button>

این قابلیت برای componentهای بزرگ، مخصوصاً وقتی binding زیاد دارند، خیلی به خوانایی کمک می کند.

Spread syntax در template

Angular 22 از spread و rest syntax در templateها پشتیبانی می کند.

مثلاً در object literal:

<div
  [class]="{
    ...baseCardClasses(),
    active: isActive(),
    disabled: isDisabled()
  }"
>
  کارت
</div>

در array literal:

<app-task-list
  [items]="[
    ...pinnedTasks(),
    ...normalTasks()
  ]"
/>

در function call:

<p>
  مجموع:
  {{ calculateTotal(...prices(), tax(), discount()) }}
</p>

این باعث می شود templateها به JavaScript/TypeScript طبیعی تر نزدیک شوند.

البته مثل همیشه، نباید template را تبدیل به محل logic سنگین کنیم.
اگر expression پیچیده شد، بهتر است آن را در component یا computed signal بنویسیم.

@switch بهتر شده

در Angular 22، @switch چند قابلیت خوب گرفته.

چند case برای یک خروجی

قبلاً اگر چند case خروجی یکسان داشتند، معمولاً مجبور بودید تکرار کنید. حالا می توانید چند @case را پشت سر هم بیاورید:

@switch (task.status) {
  @case ('todo')
  @case ('in-progress') {
    <span class="badge badge-blue">
      در حال انجام
    </span>
  }

  @case ('done') {
    <span class="badge badge-green">
      انجام شده
    </span>
  }

  @case ('canceled') {
    <span class="badge badge-gray">
      لغو شده
    </span>
  }

  @default {
    <span class="badge">
      نامشخص
    </span>
  }
}

exhaustive check با @default never

اگر مقدار شما union type باشد، می توانید از @default never برای کنترل کامل caseها استفاده کنید.

type TaskStatus = 'todo' | 'in-progress' | 'done' | 'canceled';

Template:

@switch (task.status) {
  @case ('todo')
  @case ('in-progress') {
    <span>در حال انجام</span>
  }

  @case ('done') {
    <span>انجام شده</span>
  }

  @case ('canceled') {
    <span>لغو شده</span>
  }

  @default never;
}

حالا اگر بعداً یک status جدید اضافه کنید:

type TaskStatus =
  | 'todo'
  | 'in-progress'
  | 'done'
  | 'canceled'
  | 'blocked';

ولی در template آن را handle نکنید، Angular می تواند در compile time به شما خطا بدهد.

این برای پروژه های بزرگ فوق العاده است، چون جلوی UIهای ناقص و حالت های فراموش شده را می گیرد.

Arrow function داخل template

Angular 22 اجازه می دهد arrow functionهای کوتاه داخل template بنویسید.

مثلاً:

<button
  (click)="tasks.update(list => list.filter(task => task.id !== selectedTaskId()))"
>
  حذف تسک
</button>

یا:

<button
  (click)="counter.update(value => value + 1)"
>
  افزایش
</button>

این قابلیت جذاب است، ولی باید با احتیاط استفاده شود.

خوب:

<button (click)="count.update(v => v + 1)">
  +
</button>

بد:

<button
  (click)="items.update(items => items
    .filter(item => expensiveCondition(item))
    .map(item => heavyTransform(item))
    .sort(complexSort)
  )"
>
  پردازش سنگین
</button>

قانون ساده:

اگر function کوتاه و obvious است، داخل template قابل قبول است.
اگر نیاز به فکر کردن دارد، ببریدش داخل component.

Host Directive de-duplication

Angular 22 حالا host directiveهایی را که چند بار روی یک element match می شوند، de-duplicate می کند.

فرض کنید یک directive هم مستقیم روی template آمده، هم از طریق host directive یک component اعمال شده. در چنین حالتی Angular بهتر conflictها را مدیریت می کند.

نکته مهم:

اگر یک directive هم در template match شود و هم به عنوان host directive، match مستقیم template برنده می شود.

همچنین اگر input/output با چند نام مختلف expose شود و ambiguity ایجاد کند، Angular خطا می دهد.

این تغییر بیشتر برای کسانی مهم است که design system، component library یا directiveهای قابل ترکیب می سازند.

Optional chaining و strict templateها جدی تر شده اند

در Angular 22، template type checking جدی تر شده.

دو diagnostic مهم که ممکن است بعد از آپدیت ببینید:

nullishCoalescingNotNullable
optionalChainNotNullable

یعنی اگر چیزی nullable نیست ولی شما با ?. یا ?? طوری با آن رفتار کنید که انگار nullable است، Angular می تواند هشدار یا خطا بدهد.

مثلاً:

user = signal({
  name: 'Ali',
});

Template:

<!-- احتمالاً دیگر بی معنی است، چون user همیشه مقدار دارد -->
<p>{{ user()?.name ?? 'بدون نام' }}</p>

بهتر:

<p>{{ user().name }}</p>

اما اگر واقعاً nullable است:

user = signal<{ name: string } | null>(null);

Template:

<p>{{ user()?.name ?? 'بدون نام' }}</p>

این سخت گیری ها شاید اول کار کمی آزاردهنده باشند، ولی در پروژه های بزرگ جلوی bugهای زیادی را می گیرند.

8. Change Detection؛ OnPush پیش فرض جدید است

یکی از تغییرات مهم Angular 22 این است که کامپوننت هایی که changeDetection مشخص نکرده اند، حالا به صورت پیش فرض OnPush هستند.

قبلاً اگر چیزی نمی نوشتید، Angular از رفتار default قدیمی استفاده می کرد:

@Component({
  selector: 'app-profile',
  templateUrl: './profile.html',
})
export class ProfileComponent {}

در Angular 22، این component عملاً با ذهنیت OnPush رفتار می کند.

یعنی این کد دیگر نیاز ندارد explicit بنویسد:

@Component({
  selector: 'app-profile',
  templateUrl: './profile.html',
  // دیگر برای حالت معمول لازم نیست:
  // changeDetection: ChangeDetectionStrategy.OnPush
})
export class ProfileComponent {}

اگر رفتار قدیمی را بخواهیم چه؟

رفتار قدیمی با نام جدید ChangeDetectionStrategy.Eager مشخص می شود.

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
  selector: 'app-legacy-widget',
  templateUrl: './legacy-widget.html',
  changeDetection: ChangeDetectionStrategy.Eager,
})
export class LegacyWidgetComponent {}

نام Eager از Default واضح تر است، چون دقیق تر می گوید چه اتفاقی می افتد:
Angular مشتاقانه تر و گسترده تر change detection را اجرا می کند.

چرا این تغییر مهم است؟

چون Angular دارد به سمت performance by default می رود.

در معماری جدید:

state با Signals explicitتر می شود
componentها کمتر بی دلیل re-render می شوند
dependencyها دقیق تر track می شوند
zoneless change detection معنی دارتر می شود
UI قابل پیش بینی تر می شود

این تغییر برای پروژه های جدید عالی است.
اما برای پروژه های قدیمی ممکن است نیاز به تست دقیق داشته باشد.

9. Zoneless؛ مسیر جدید Angular برای performance

Zoneless دقیقاً فقط مخصوص Angular 22 نیست، ولی Angular 22 آن را خیلی جدی تر در مسیر اصلی فریم ورک قرار می دهد.

در Angular قدیمی، zone.js خیلی از async eventها را intercept می کرد:

click
timeout
promise
HTTP
event listener
و موارد دیگر

بعد Angular تصمیم می گرفت change detection را اجرا کند.

این مدل ساده بود، ولی هزینه داشت. چون گاهی Angular بیش از حد لازم بررسی انجام می داد.

در مدل جدید، Angular بیشتر به Signals و explicit updates تکیه می کند.

نمونه setup zoneless:

import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(),
  ],
};

در این مدل بهتر است state را با Signals مدیریت کنید:

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <p>Count: {{ count() }}</p>
    <button (click)="increase()">+</button>
  `,
})
export class CounterComponent {
  readonly count = signal(0);

  increase() {
    this.count.update(value => value + 1);
  }
}

اینجا Angular دقیقاً می داند چه چیزی تغییر کرده و چه چیزی باید update شود.

10. HTTP؛ Fetch backend پیش فرض شده

در Angular 22، FetchBackend به default جدید HTTP تبدیل شده.

قبلاً خیلی وقت ها می نوشتیم:

provideHttpClient(withFetch());

اما در Angular 22، چون Fetch backend پیش فرض شده، withFetch() deprecated شده و می توانید آن را حذف کنید.

قبل:

import { provideHttpClient, withFetch } from '@angular/common/http';

export const appConfig = {
  providers: [
    provideHttpClient(withFetch()),
  ],
};

بعد:

import { provideHttpClient } from '@angular/common/http';

export const appConfig = {
  providers: [
    provideHttpClient(),
  ],
};

اگر upload progress می خواهید

Fetch برای بعضی سناریوها، مخصوصاً upload progress، محدودیت دارد.
اگر به XHR نیاز دارید، می توانید صریحاً withXhr() را فعال کنید:

import {
  provideHttpClient,
  withXhr,
} from '@angular/common/http';

export const appConfig = {
  providers: [
    provideHttpClient(withXhr()),
  ],
};

و به جای reportProgress قدیمی تر، از گزینه های دقیق تر استفاده کنید:

this.http.post('/api/upload', formData, {
  observe: 'events',
  reportUploadProgress: true,
});

برای download:

this.http.get('/api/file', {
  observe: 'events',
  reportDownloadProgress: true,
});

platform-server و XHR

در Angular 22 مسیر کلی این است که در SSR هم به سمت APIهای استانداردتر مثل fetch برویم.
XHR support در @angular/platform-server deprecated شده است.

پس اگر در پروژه SSR دارید، بهتر است وابستگی های قدیمی به XHR را بررسی کنید.

11. SSR و Hydration؛ Incremental Hydration پیش فرض تر شده

Angular در چند نسخه اخیر روی SSR و hydration خیلی کار کرده و Angular 22 این مسیر را ادامه می دهد.

یکی از تغییرات مهم این است که incremental hydration رفتار پیش فرض شده.

ایده incremental hydration ساده است:

لازم نیست کل صفحه یک دفعه hydrate شود. بخش های لازم تر و قابل مشاهده می توانند زودتر interactive شوند.

این برای سایت هایی مثل این ها مهم است:

فروشگاه اینترنتی
landing pageهای سنگین
سایت های محتوایی
داشبوردهای بزرگ
صفحه هایی با componentهای سنگین پایین صفحه

ترکیب SSR با @defer

@defer از قبل وارد Angular شده بود، اما در Angular 22 بهتر با مسیر performance و hydration هماهنگ می شود.

مثال:

<section>
  <h2>داشبورد فروش</h2>

  <app-sales-summary />

  @defer (on viewport) {
    <app-heavy-chart />
  } @placeholder {
    <p>نمودار بعد از اسکرول لود می شود...</p>
  } @loading {
    <p>در حال بارگذاری نمودار...</p>
  } @error {
    <p>خطا در بارگذاری نمودار</p>
  }
</section>

در این مدل، chart سنگین تا وقتی لازم نشده، وارد مسیر loading نمی شود.

timeout برای idle defer

در Angular 22، idle behavior در @defer قابل کنترل تر شده.

مثلاً می توانید بگویید deferred block در زمان idle اجرا شود، ولی اگر مرورگر خیلی دیر idle شد، حداکثر تا یک timeout مشخص اجرا شود:

@defer (on idle({ timeout: 2000 })) {
  <app-recommendations />
} @placeholder {
  <p>پیشنهادها به زودی نمایش داده می شوند...</p>
}

این برای componentهایی خوب است که مهم هستند، ولی نه آن قدر مهم که initial load را سنگین کنند.

12. @boundary؛ Error Boundary در template

یکی از قابلیت های جذابی که معرفی شده ولی هنوز developer preview است، @boundary است.

این قابلیت قرار است در templateها نقش Error Boundary را بازی کند.

فرض کنید یک widget تبلیغاتی یا component بیرونی دارید که ممکن است خطا بدهد.
نمی خواهید کل صفحه checkout یا dashboard به خاطر آن خراب شود.

با @boundary می توانید یک محدوده امن بسازید:

<section>
  @boundary {
    <app-promotional-widget />
  } @error (let error) {
    <app-default-promo-widget />
  }

  <app-cart-summary />
  <app-checkout-flow />
</section>

اگر app-promotional-widget خطا بدهد، کل صفحه نمی ریزد.
به جایش fallback نمایش داده می شود.

این قابلیت مخصوصاً برای این سناریوها مهم است:

widgetهای third-party
micro frontendها
componentهای dynamic
checkout
dashboardهای حساس
صفحات high-value مثل payment یا booking

نکته مهم: @boundary در زمان معرفی Angular 22 هنوز production-ready نیست و قرار است در قالب developer preview در ادامه سال ۲۰۲۶ در دسترس قرار بگیرد.

13. ابزارهای AI؛ Angular خودش را برای دوران agentها آماده می کند

Angular 22 فقط درباره runtime و template نیست.
بخش بزرگی از این نسخه درباره AI-assisted development است.

تیم Angular روی چند محور کار کرده:

MCP tools
Agent Skills
WebMCP
integration با Google AI Studio و Gemini Canvas

Angular MCP tools

Angular MCP ابزارهایی برای coding agentها فراهم می کند تا بهتر با پروژه Angular کار کنند.

مثلاً ابزارهایی مثل:

devserver.start
devserver.stop
devserver.wait_for_build

این یعنی agent می تواند dev server را اجرا کند، منتظر build بماند، خروجی build را بخواند و بر اساس خطاها خودش اصلاح انجام دهد.

در پروژه های واقعی، این خیلی مهم است.
چون مشکل اصلی AI coding assistantها این نیست که کد نمی نویسند؛ مشکل این است که context و feedback loop درست ندارند.

MCP کمک می کند agent فقط حدس نزند، بلکه از خود پروژه feedback بگیرد.

Angular Agent Skills

Angular Agent Skills یک راه استاندارد برای دادن context مدرن Angular به AI agentهاست.

دو skill مهم برای developerها معرفی شده:

angular-developer

این skill به agent می گوید Angular مدرن چطور نوشته می شود.

مثلاً:

Signals
Signal Forms
Angular Aria
best practices جدید
الگوهای جدید component نویسی
migration از روش های قدیمی

angular-new-app

این skill برای ساخت پروژه جدید Angular در محیط agentic کاربرد دارد.

یعنی اگر یک AI assistant بخواهد پروژه Angular بسازد، با context درست تری شروع می کند.

WebMCP؛ ابزار دادن به agent داخل خود browser

WebMCP یک ایده جدید و experimental است.

ایده اش این است که خود اپلیکیشن بتواند ابزارهای ساختاریافته ای به agent بدهد تا agent مجبور نباشد فقط DOM را حدس بزند.

مثلاً اپلیکیشن می تواند بگوید:

این routeها وجود دارند
این فرم چنین schemaای دارد
این actionها قابل انجام هستند
این service چنین capabilityهایی دارد

برای مثال در آینده ممکن است یک فرم Signal Forms بتواند به صورت خودکار ابزارهایی برای AI agent expose کند.

این هنوز experimental است، اما جهت گیری مهمی را نشان می دهد:

Angular می خواهد اپلیکیشن ها فقط برای انسان ها قابل استفاده نباشند؛ برای agentها هم قابل فهم و قابل تعامل باشند.

14. TypeScript 6 و Node.js 26

Angular 22 با TypeScript 6 سازگار شده و پشتیبانی از TypeScriptهای قدیمی تر از 6 را کنار گذاشته است.

این یعنی اگر پروژه شما هنوز روی TypeScript 5.x است، قبل از آپدیت باید وضعیت dependencyها را بررسی کنید.

نمونه upgrade:

ng update @angular/core@22 @angular/cli@22

بعد از آپدیت، versionها را چک کنید:

ng version

و حتماً build بگیرید:

ng build

برای پروژه های بزرگ، بهتر است آپدیت را در یک branch جدا انجام دهید و migrationهای خود Angular CLI را دقیق review کنید.

15. Language Service بهتر شده

Angular Language Service هم در Angular 22 بهتر شده.

چند بهبود مهم:

template inlay hints
Document Symbols برای templateها
پشتیبانی بهتر از @Input با transform
typecheck بهتر برای templateهای پیچیده تر

این تغییرات شاید در release note خیلی بزرگ به نظر نرسند، ولی در تجربه روزمره توسعه مهم اند.

وقتی template بزرگ دارید، اینکه IDE بهتر بفهمد چه خبر است یعنی:

refactor راحت تر
navigation بهتر
خطایابی سریع تر
autocomplete دقیق تر
تجربه بهتر برای تیم های بزرگ

16. تغییرات مهم و Breaking Changes

حالا برسیم به قسمت مهم برای پروژه های واقعی: چیزهایی که ممکن است بعد از آپدیت بشکنند.

TypeScript قدیمی دیگر پشتیبانی نمی شود

Angular 22 از TypeScript نسخه های قدیمی تر از 6 پشتیبانی نمی کند.

پس اگر dependency یا tooling شما هنوز TypeScript 5.x می خواهد، باید قبل از آپدیت بررسی شود.

ComponentFactoryResolver حذف شده

APIهای قدیمی مثل ComponentFactoryResolver و ComponentFactory دیگر در API surface نیستند.

قبل:

const factory = this.componentFactoryResolver.resolveComponentFactory(UserCardComponent);
this.viewContainerRef.createComponent(factory);

بعد:

this.viewContainerRef.createComponent(UserCardComponent);

یا اگر خارج از ViewContainerRef component می سازید، از APIهای جدیدتر مثل createComponent استفاده کنید.

createNgModuleRef حذف شده

اگر جایی هنوز از createNgModuleRef استفاده دارید، باید به createNgModule مهاجرت کنید.

قبل:

const moduleRef = createNgModuleRef(SomeModule, injector);

بعد:

const moduleRef = createNgModule(SomeModule, injector);

ChangeDetectorRef.checkNoChanges حذف شده

اگر در تست ها از checkNoChanges استفاده کرده اید، باید به جای آن از fixture.detectChanges() استفاده کنید.

قبل:

fixture.componentRef.changeDetectorRef.checkNoChanges();

بعد:

fixture.detectChanges();

min و max در forms دیگر string نمی پذیرند

در Angular 22، validation ruleهای min و max دیگر string value را قبول نمی کنند.

قبل:

min(schema.age, '18');

بعد:

min(schema.age, 18);

اگر مقدار ممکن است خالی باشد:

min(schema.age, 18);

و مقدار field باید number | null باشد، نه string.

data-* attributeها دیگر input/output را bind نمی کنند

در Angular 22، attributeهایی با prefix data- دیگر به عنوان input/output binding در نظر گرفته نمی شوند.

پس data-* را برای metadata واقعی HTML نگه دارید، نه API کامپوننت.

خوب:

<app-user-card
  [userId]="user.id"
  data-testid="user-card"
/>

بد:

<!-- data-user-id نباید API اصلی component باشد -->
<app-user-card
  [data-user-id]="user.id"
/>

چند selector match شده، compile-time error می دهد

اگر یک element با چند component/directive selector ناسازگار match شود، Angular 22 سخت گیرتر شده و در compile time خطا می دهد.

این برای جلوگیری از رفتارهای مبهم است.

مثلاً اگر دو directive طوری طراحی شده باشند که ناخواسته روی یک element match شوند، باید selectorها را شفاف تر کنید.

duplicate input/output خطا می دهد

اگر input یا output با چند نام expose شود و conflict ایجاد کند، Angular خطا می دهد.

مثلاً چنین طراحی هایی باید اصلاح شوند:

@Directive({
  selector: '[appExample]',
})
export class ExampleDirective {
  // اگر aliasها باعث ambiguity شوند، Angular سخت گیرتر برخورد می کند.
}

هدف این تغییر این است که API کامپوننت ها و directiveها ambiguous نباشد.

متغیر in در template expression دیگر قابل قبول نیست

Angular 22 روی template expressionها سخت گیرتر شده و استفاده نامعتبر از in را خطا می دهد.

به جای انتخاب نام های مبهم، از نام واضح استفاده کنید:

بد:

@for (item of items; track item.id; let in = $index) {
  <p>{{ in }}</p>
}

خوب:

@for (item of items; track item.id; let index = $index) {
  <p>{{ index }}</p>
}

Hammer.js integration حذف شده

اگر پروژه شما هنوز به Hammer.js integration داخلی Angular وابسته است، باید implementation خودتان را جایگزین کنید.

این معمولاً روی gestureهایی مثل swipe، pan و pinch اثر می گذارد.

provideRoutes حذف شده

اگر هنوز از provideRoutes استفاده می کنید:

provideRoutes(routes);

به این مدل مهاجرت کنید:

provideRouter(routes);

یا در سناریوهای خاص از ROUTES multi provider استفاده کنید.

withFetch deprecated شده

چون Fetch backend پیش فرض شده، withFetch() دیگر لازم نیست.

قبل:

provideHttpClient(withFetch());

بعد:

provideHttpClient();

reportProgress deprecated شده

به جای:

this.http.post('/api/upload', body, {
  observe: 'events',
  reportProgress: true,
});

از گزینه های دقیق تر استفاده کنید:

this.http.post('/api/upload', body, {
  observe: 'events',
  reportUploadProgress: true,
});

یا:

this.http.get('/api/file', {
  observe: 'events',
  reportDownloadProgress: true,
});

17. Webpack و build pipelineهای قدیمی

در Angular 22، پشتیبانی از مسیرهای قدیمی Webpack-based deprecated شده است.

مواردی مثل:

@ngtools/webpack
build pipelineهای قدیمی مبتنی بر Webpack
builderهای قدیمی تر

در مسیر deprecation قرار گرفته اند.

Angular دارد تمرکز را به سمت application builder جدیدتر و TSGo support می برد.

برای پروژه های معمولی که با Angular CLI و builderهای جدیدتر ساخته شده اند، شاید کار خاصی لازم نباشد.
اما اگر پروژه شما custom webpack config، builder اختصاصی، یا ابزارهای قدیمی build دارد، این بخش را جدی بگیرید.

18. Standalone، Functional Guards و @defer؛ جدید نیستند، ولی در Angular 22 مهم تر شده اند

در بعضی مقاله ها درباره Angular 22، مواردی مثل Standalone Components، Functional Guards و @defer به عنوان بخشی از «Angular جدید» معرفی می شوند.

این درست است، ولی باید دقیق باشیم:

این ها لزوماً همگی در Angular 22 متولد نشده اند، اما Angular 22 آن ها را در مسیر اصلی فریم ورک جدی تر می کند.

Standalone Component

import { Component } from '@angular/core';

@Component({
  selector: 'app-home',
  imports: [],
  template: `
    <h2>Home</h2>
  `,
})
export class HomeComponent {}

در Angular مدرن، دیگر لازم نیست برای هر feature ساده یک NgModule بسازید.

Functional Guard

import { inject } from '@angular/core';
import { CanActivateFn, Router } from '@angular/router';

export const authGuard: CanActivateFn = () => {
  const router = inject(Router);
  const token = localStorage.getItem('token');

  return Boolean(token) || router.parseUrl('/login');
};

این مدل معمولاً از guard کلاسیک کوتاه تر، تست پذیرتر و خواناتر است.

@defer

@defer (on viewport) {
  <app-heavy-widget />
} @placeholder {
  <p>در حال آماده سازی...</p>
}

@defer برای کم کردن initial bundle و بهتر کردن تجربه load اولیه خیلی مهم است.

19. Angular 22 برای چه پروژه هایی مهم تر است؟

Angular 22 برای همه مهم است، ولی برای بعضی پروژه ها اثرش بیشتر دیده می شود.

پروژه های enterprise

مثل:

admin panel
ERP
CRM
سیستم های مالی
سیستم های منابع انسانی
داشبوردهای عملیاتی
پروژه های multi-tenant

چون این پروژه ها معمولاً با این مشکلات درگیرند:

فرم های بزرگ
state پیچیده
routeهای زیاد
componentهای سنگین
نیاز به performance پایدار
نیاز به maintainability بالا

پروژه های SSR و content-heavy

مثل:

سایت های محتوایی
فروشگاه ها
landing pageها
پلتفرم های آموزشی

به خاطر:

incremental hydration
fetch backend
defer
بهبودهای SSR
loading بهتر بخش های صفحه

تیم هایی که از AI coding assistant استفاده می کنند

به خاطر:

MCP tools
Agent Skills
WebMCP
context بهتر برای ابزارهای AI

20. آیا باید سریع به Angular 22 آپدیت کنیم؟

جواب کوتاه: برای پروژه جدید، بله؛ برای پروژه قدیمی، با برنامه.

اگر پروژه جدید شروع می کنید، Angular 22 انتخاب خوبی است چون:

OnPush mindset پیش فرض است
Signal-first development جدی تر شده
Forms مسیر مدرن تری دارند
Router بهتر شده
SSR بهتر شده
Tooling آینده نگرتر شده

اما اگر پروژه موجود دارید، مخصوصاً پروژه بزرگ، مستقیم آپدیت نکنید.

چک لیست پیشنهادی قبل از آپدیت

1. نسخه ها را بررسی کنید

ng version

2. branch جدا بسازید

git checkout -b upgrade/angular-22

3. آپدیت را اجرا کنید

ng update @angular/core@22 @angular/cli@22

4. build بگیرید

ng build

5. تست ها را اجرا کنید

ng test

6. SSR را جدا بررسی کنید

اگر SSR دارید:

ng build
npm run serve:ssr

7. این موارد را دستی review کنید

changeDetection
استفاده از ComponentFactoryResolver
استفاده از createNgModuleRef
custom webpack config
withFetch
upload/download progress
route params inheritance
route reuse strategy
فرم هایی که min و max با string دارند
پروژه هایی که Hammer.js استفاده می کنند
strict template diagnostics

21. جمع بندی؛ Angular 22 دقیقاً چه پیامی دارد؟

Angular 22 فقط یک release معمولی نیست.

این نسخه نشان می دهد Angular دارد از چند جهت هم زمان matureتر می شود:

از نظر reactivity با Signals
از نظر forms با Signal Forms
از نظر async state با resource و httpResource
از نظر DI با @Service و injectAsync
از نظر performance با OnPush، zoneless، defer و hydration
از نظر Router با cleanup بهتر و Navigation API
از نظر template syntax با spread، arrow function، comment و switch بهتر
از نظر AI tooling با MCP، Agent Skills و WebMCP

مهم ترین نکته این است:

Angular نمی خواهد شبیه React شود.
Angular دارد نسخه مدرن تر خودش را می سازد.

نسخه ای که هنوز برای پروژه های بزرگ و ساختارمند جدی است، اما دیگر آن حس سنگین و پر از boilerplate قدیمی را ندارد.

اگر هنوز Angular را با ذهنیت ۲۰۲۰ می نویسید، Angular 22 احتمالاً برایتان یک پیام روشن دارد:

وقت آن رسیده با Angular مدرن تر کار کنید؛
با Signals، فرم های جدید، route-level architecture، lazy dependencyها، templateهای تمیزتر و performance پیش فرض بهتر.

لینک ویدیو یوتوب انگولار:

بررسی Angular 22؛ تغییرات مهم و قابلیت‌های جدید

محمد پارسایی

نظرات