Angular ليس إطار العمل الأكثر رواجاً، لكنه يبقى من أمتن الخيارات لتطبيقات المؤسسات. بنية صارمة تقود الفرق نحو كود منظَّم، TypeScript منذ اليوم الأول، دعم رسمي من Google، نظام بيئي ناضج، ودعم طويل الأمد: حُجج لها وزنها في سياقات تتقدّم فيها قابلية التنبؤ والصيانة على حرية الاختيار. هذا الدليل يغطي Angular كما يُكتَب في 2026 (معلومات مُتحقَّق منها في أبريل 2026، عرضة للتطوّر)، مع signals، والمكوّنات standalone، والتغييرات الكبرى التي قرّبت تجربة المطوّر من React مع الإبقاء على البنية التي تصنع قوّة Angular.

الهدف ليس الدفاع عن Angular ضدّ React أو Vue. الهدف منح الفريق الذي اختار Angular (أو ورث تطبيق Angular) المفاتيح اللازمة للتسليم بكفاءة في 2026. لشركة فرنكوفونية صغيرة أو متوسطة تبدأ مشروعاً جديداً بدون قيود تاريخية، الاختيار بين Angular وReact وVue يتعلّق بصورة كبيرة بملف الفريق وسياق العمل.

ثمّة انطباع، مُبرَّر جزئياً، بأنّ Angular أكثر تعقيداً من منافسيه. هذا التعقيد ليس مجاناً: يجلب ضمانات بنية وانسجام لا توفّرها الأُطر الأكثر تسامحاً. الفريق الذي يبدأ Angular يدفع كلفة تعلّم أوّليّة أعلى من React، لكنّه يستفيد لاحقاً من إطار يوجّه القرارات ويقلّص الجدل الأسلوبي. للفرق التي ستبقى على المشروع سنوات عدّة، هذا الإطار رصيد. للفرق التي تغيّر التقنية كلّ سنة، هو عبء أكثر منه فائدة.

المحتويات

متى يكون Angular الخيار الصحيح
Angular في 2026: ما الذي تغيّر
الإعداد وبنية المشروع
المكوّنات standalone: الوضع الافتراضي الجديد
Signals: نموذج التفاعلية الحديث
RxJS: هل يبقى مهماً؟
الخدمات وحقن التبعيات
التوجيه والتنقّل
النماذج: Reactive مقابل Template
الأداء والتحسين
أسئلة شائعة

1. متى يكون Angular الخيار الصحيح

Angular يتألّق في سياقات محدّدة:

تطبيقات المؤسسات المعقّدة: لوحات إدارة غنية، تطبيقات أعمال داخلية ثقيلة، أنظمة ERP عبر الويب. البنية التي يفرضها Angular (الـ modules، الخدمات، حقن التبعيات) تُسهّل التعاون بين عدّة مطوّرين على مدى طويل. حيث يترك React للفريق ابتكار اصطلاحاته (مع ما يرافق ذلك من منافع وأكلاف)، يفرض Angular إطاراً موحّداً.

الفرق ذات الدوران المرتفع: مطوّر يعرف Angular يصبح منتجاً على مشروع Angular قائم خلال أيّام، لأنّ البنية موحّدة. مع React، كلّ مشروع يعيد ابتكار اصطلاحاته وعمليّة الإدماج (onboarding) أكثر تفاوتاً.

سياقات Microsoft / .NET: Angular منتشر جدّاً في النظام البيئي التقليدي للمؤسسات. الفرق التي تعمل بـ .NET في الخلفية و Angular في الواجهة تتشارك غالباً نفس الأنماط المعمارية.

التطبيقات الغنيّة بالنماذج: Reactive Forms في Angular من بين الأقوى في السوق. لتطبيق فيه عشرات النماذج المعقّدة (validation شرطي، تبعيّات بين الحقول)، Angular يرفع الإنتاجية بشكل لافت.

في المقابل، Angular أقلّ ملاءمة لـ: المواقع العامّة الخفيفة، النماذج الأوّليّة السريعة، الفرق الصغيرة جدّاً (الشكليّات تثقل)، المشاريع ذات القيد الصارم على حجم الحزمة.

2. Angular في 2026: ما الذي تغيّر

تطوّر Angular كثيراً بين 2020 و2026، إلى درجة أنّ مطوّراً توقّف عند AngularJS أو Angular 9 لن يتعرّف على الإطار الحالي.

المكوّنات standalone أصبحت الوضع الافتراضي. لم تعد ثمّة حاجة للتصريح بـ NgModule في كلّ مكان: المكوّن يُحدّد تبعيّاته مباشرة في الـ decorator. كود أبسط، lazy loading طبيعي، إدماج أسهل.

الـ signals توفّر نظام تفاعلية حديث، أبسط فهماً من RxJS لمعظم الحالات. أُعيد تصميم change detection حول الـ signals (نمط ZoneJS-less)، مع مكاسب أداء ملموسة.

التحكّم في التدفّق داخل القوالب: @if و@for و@switch تحلّ محلّ التوجيهات *ngIf و*ngFor و*ngSwitch. أداء أعلى وقراءة أوضح.

Server-Side Rendering تحسّن بشكل جدّيّ مع hydration و SSR streaming.

Vite وesbuild مُدمَجان في الـ CLI: عمليّات بناء أسرع بكثير من webpack.

Material 3 (Angular Material مع نظام تصميم Material 3) لواجهات منسجمة.

Angular DevTools: امتداد متصفّح يفحص المكوّنات، وchange detection، والأداء. صار لا غنى عنه في عمليّات التنقيح.

الاختبارات المعدّلة: استبدال تدريجي لـ Karma + Jasmine بـ Vitest وWeb Test Runner، أسرع وأكثر اندماجاً مع النظام البيئي الحديث لـ JavaScript.

لمطوّر يعود إلى Angular بعد سنوات، استثمار التحديث كبير لكنّه مربح: الإطار صار أكثر متعة في الاستخدام بكثير.

3. الإعداد وبنية المشروع

إقلاع مشروع Angular يتلخّص في أمرين اثنين: تثبيت الـ CLI على مستوى النظام، ثم توليد مشروع جاهز مع standalone والـ routing والـ SSR. الـ CLI يحلّ تلقائياً الإصدارات المتوافقة من Angular وTypeScript وRxJS — لا داعي لبناء ملف package.json يدوياً.

npm install -g @angular/cli
ng new mon-app --standalone --routing --style=scss
cd mon-app
ng serve

الـ flag --standalone (أصبح الافتراضي في Angular 17+) يُهيّئ المشروع بدون NgModule. --routing يضيف نظام التوجيه. --style=scss يستخدم SCSS بدلاً من CSS الصرف.

بنية نموذجيّة:

src/
├── app/
│   ├── core/                # خدمات singletons، guards، interceptors
│   ├── shared/              # مكوّنات/pipes/توجيهات قابلة لإعادة الاستخدام
│   ├── features/
│   │   ├── clients/
│   │   │   ├── clients.routes.ts
│   │   │   ├── clients-list.component.ts
│   │   │   └── client.service.ts
│   │   └── orders/
│   ├── app.component.ts
│   ├── app.config.ts
│   └── app.routes.ts
├── assets/
└── styles.scss

التنظيم حسب الـ feature بدلاً من النوع هو الممارسة المُوصى بها. كلّ feature تحوي مكوّناتها وخدماتها وroutesها.

الملف app.config.ts يضبط التطبيق على المستوى العام:

import { ApplicationConfig, provideZonelessChangeDetection } from "@angular/core";
import { provideRouter } from "@angular/router";
import { provideHttpClient, withFetch } from "@angular/common/http";
import { routes } from "./app.routes";

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

الدالّة provideZonelessChangeDetection تُفعّل النمط بدون Zone.js لأداء أفضل (Angular 18+). إن لم يَجهز فريقك للقفز إلى zoneless، يمكن الإبقاء على Zone.js لفترة انتقالية والهجرة تدريجياً.

4. المكوّنات standalone: الوضع الافتراضي الجديد

هذا ما يبدو عليه مكوّن Angular معاصر. الـ decorator @Component يستقبل standalone: true (ضمنيّ منذ Angular 19) ومصفوفة imports خاصّة به لما يحتاجه — انتهى زمن declarations وexports المُشتركة بين المكوّنات.

import { Component, signal } from "@angular/core";
import { CommonModule } from "@angular/common";
import { FormsModule } from "@angular/forms";

@Component({
  selector: "app-counter",
  standalone: true,
  imports: [CommonModule, FormsModule],
  template: `
    <div>
      <p>العدّاد: {{ count() }}</p>
      <button (click)="increment()">+1</button>
    </div>
  `,
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(c => c + 1);
  }
}

لا @NgModule بعد الآن. المكوّن يُصرّح بتبعيّاته مباشرة عبر imports. أبسط، lazy loading طبيعي لكلّ route، وإعادة هيكلة (refactoring) موضعيّة لا تنشر تأثيراتها في الـ NgModules البعيدة.

مزايا standalone

imports صريحة: نرى فوراً ما يستخدمه المكوّن
قدر أقلّ من boilerplate: لا SharedModule يحتاج صيانة
lazy loading طبيعي: كلّ مكوّن وحدة قابلة للتحميل باستقلال
tree shaking أفضل: الـ bundler يحذف الكود الميّت بفعّاليّة أعلى
هجرة تدريجيّة: NgModules الحاليّة تبقى تعمل أثناء الانتقال

الهجرة من NgModule

للتحوّل بمشروع قديم نحو نمط standalone، الـ CLI يوفّر schematic مخصّص يحوّل المكوّنات، ويزيل NgModule التي صارت بلا فائدة، ويحدّث الـ imports. الهجرة تكاد تكون آليّة، وتدريجيّة: يمكنك إيقافها واستئنافها ملفاً ملفاً.

ng generate @angular/core:standalone

الأداة الرسميّة تنقل المكوّنات تلقائيّاً إلى standalone خطوة بخطوة. مُوصى بها للمشاريع القائمة.

5. Signals: نموذج التفاعلية الحديث

الـ signals حاويات قيم تفاعليّة. تُبلّغ المستهلكين تلقائيّاً (القوالب، signals مشتقّة أخرى) حين تتغيّر القيمة. لا حاجة لـ BehaviorSubject ولا لـ async pipe.

import { Component, signal, computed, effect } from "@angular/core";

@Component({
  selector: "app-cart",
  standalone: true,
  template: `
    <p>العناصر: {{ items().length }}</p>
    <p>المجموع: {{ total() }} F CFA</p>
    <button (click)="ajouter()">+</button>
  `,
})
export class CartComponent {
  items = signal<CartItem[]>([]);

  total = computed(() =>
    this.items().reduce((sum, item) => sum + item.prix, 0)
  );

  constructor() {
    effect(() => {
      console.log(`تحديث العناصر: ${this.items().length}`);
    });
  }

  ajouter() {
    this.items.update(list => [...list, nouveauItem]);
  }
}

أربع لبنات أوّليّة تكفي: signal() ينشئ خليّة تفاعليّة، computed() يشتقّ تلقائيّاً، effect() يستجيب للتغيّرات، والوصول بالاستدعاء (count()) يُسجّل التبعيّة في رسم بياني داخلي. النتيجة نموذج تفاعليّ صريح ومرئيّ، عوض السحر الضمني الذي كان يفرضه Zone.js.

ثلاث لبنات مفتاحيّة

signal(initial): قيمة تفاعليّة قابلة للتعديل. القراءة: count(). الكتابة: count.set(5) أو count.update(c => c + 1).
computed(() => ...): قيمة مشتقّة من signals أخرى. تُحسَب من جديد تلقائيّاً عند تغيّر التبعيّات.
effect(() => ...): كود يُنفَّذ عند كلّ تغيّر للـ signals المُستخدَمة. مفيد للآثار الجانبيّة (logs، حفظ، مزامنة API).

Signals مقابل RxJS

الـ signals تغطّي ببساطة الحالات التي تكون فيها لدينا قيمة متزامنة تتغيّر. RxJS يبقى مهمّاً للتدفّقات غير المتزامنة (HTTP، الأحداث، websockets، retry/debounce/throttle). الاثنان يتعايشان: toSignal() يحوّل Observable إلى Signal، وtoObservable() يفعل العكس.

التفاصيل في Angular signals وRxJS عمليّاً.

6. RxJS: هل يبقى مهماً؟

مع وصول الـ signals، يفقد RxJS أرضاً في حالات كثيرة. لكنّه يبقى لا غنى عنه في:

طلبات HTTP: HttpClient يُرجع Observables
تدفّقات الأحداث المعقّدة: drag & drop، حركات الموبايل، websockets
التركيبات غير المتزامنة: merge وcombineLatest وswitchMap للتأليف
عمليّات أعمال متخصّصة: debounceTime وthrottleTime وretry مع backoff

يبقى RxJS التجريد المناسب حين تحتاج لتأليف الأحداث غير المتزامنة، أو debounce، أو إعادة محاولة، أو إلغاء. النمط أدناه يجمع switchMap وdebounceTime ليُلغي تلقائيّاً الطلب السابق حين يكتب المستخدم حرفاً جديداً في حقل البحث.

import { HttpClient } from "@angular/common/http";
import { inject } from "@angular/core";
import { switchMap, debounceTime, distinctUntilChanged } from "rxjs";

@Injectable({ providedIn: "root" })
export class SearchService {
  private http = inject(HttpClient);

  search$(query$: Observable<string>) {
    return query$.pipe(
      debounceTime(300),
      distinctUntilChanged(),
      switchMap(q => this.http.get(`/api/search?q=${q}`)),
    );
  }
}

نمط debounce + switchMap (يُلغي الطلبات المتقادمة حين يكتب المستخدم بسرعة) ساذج التحقيق في RxJS، أصعب بكثير بالاعتماد على signals وحدها.

استراتيجية 2026

Signals لحالات الواجهة المتزامنة. RxJS للأشياء غير المتزامنة والتدفّقات. الجسر بـ toSignal() لإفصاحها للقوالب التي تستهلك signals.

import { toSignal } from "@angular/core/rxjs-interop";

clients = toSignal(this.http.get<Client[]>("/api/clients"), { initialValue: [] });

الجسر بين العالمين تافه التحقيق: toSignal() يحوّل observable إلى signal مع إدارة unsubscribe تلقائياً عند تدمير المكوّن. toObservable() يفعل العكس لربط signal بعامل RxJS. لا مكتبة إضافيّة لتثبيتها، كلّ شيء يأتي من @angular/core/rxjs-interop.

7. الخدمات وحقن التبعيات

حقن التبعيات في Angular يبقى من نقاط قوّته المُؤسِّسة. مركزيّ، قابل للاختبار، و type-safe.

import { Injectable, inject } from "@angular/core";
import { HttpClient } from "@angular/common/http";

@Injectable({ providedIn: "root" })
export class ClientService {
  private http = inject(HttpClient);

  list() {
    return this.http.get<Client[]>("/api/clients");
  }

  create(client: NewClient) {
    return this.http.post<Client>("/api/clients", client);
  }

  byId(id: string) {
    return this.http.get<Client>(`/api/clients/${id}`);
  }
}

الـ providedIn: "root" يجعل الخدمة singleton على مستوى التطبيق. لخدمة بنطاق feature: providedIn: "platform" أو حقن على مستوى route معيّن.

inject() مقابل constructor

قبل Angular 14، كان حقن التبعيّات يمرّ عبر constructor. منذ ذلك الإصدار، الدالّة inject() تتيح استرجاع تبعيّة من أيّ موضع داخل سياق حقن (constructor، مُهيّئ خاصيّة، factory لـ provider). الكود يصبح أقصر، أسهل تأليفاً في دوال مساعدة، وأكثر طبيعيّة في الاختبار.

// قديم: الحقن عبر constructor
export class MyComponent {
  constructor(private clientService: ClientService) {}
}

// حديث: دالّة inject()
export class MyComponent {
  private clientService = inject(ClientService);
}

الدالّة inject() أعمليّ مع الـ classes المُجرَّدة، المكوّنات standalone، والـ hooks لـ routes. مُوصى به في 2026.

Tokens مخصّصة

لإتاحة قيم إعداد عبر الحقن:

import { InjectionToken } from "@angular/core";

export const API_URL = new InjectionToken<string>("API_URL");

// الإعداد
export const appConfig: ApplicationConfig = {
  providers: [
    { provide: API_URL, useValue: "https://api.example.com" },
  ],
};

// الاستعمال
@Injectable({ providedIn: "root" })
export class ClientService {
  private apiUrl = inject(API_URL);
  private http = inject(HttpClient);

  list() {
    return this.http.get<Client[]>(`${this.apiUrl}/clients`);
  }
}

عمليّ لإعدادات مختلفة بحسب البيئة (dev، staging، prod).

Interceptors HTTP

يُتيح Angular اعتراض كلّ الطلبات HTTP لإضافة سلوكيّات عابرة: إضافة token استيثاق، إدارة الأخطاء مركزياً، retry تلقائي، تسجيل (logging).

import { HttpInterceptorFn } from "@angular/common/http";
import { inject } from "@angular/core";

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const auth = inject(AuthService);
  const token = auth.token();
  if (token) {
    req = req.clone({
      setHeaders: { Authorization: `Bearer ${token}` },
    });
  }
  return next(req);
};

// الإعداد
provideHttpClient(withInterceptors([authInterceptor, errorInterceptor]));

الـ interceptors الوظيفيّة (في مقابل class-based) هي الشكل الحديث في 2026. أبسط، أسهل اختباراً، ومُدمجة طبيعيّاً مع inject(). هذا المنهج يُلغي قدراً كبيراً من الكود المتكرّر الذي كنّا نجده مبعثراً في كلّ خدمة HTTP.

الاختبار مع حقن التبعيات

أحد المنافع الدائمة لـ Angular هو سهولة الاختبار بفضل DI. mocking خدمة يعني تقديم تنفيذ زائف عبر TestBed.configureTestingModule. المكوّنات يمكن اختبارها بمعزل، دون الاعتماد على خدماتها الحقيقيّة. هذه القابليّة للاختبار بحكم البنية تميّز Angular عن أُطر أكثر تسامحاً تعتمد فيها قابليّة الاختبار كلّياً على انضباط الفريق.

8. التوجيه والتنقّل

التوجيه في Angular يُعلَن كمصفوفة routes: URL، مكوّن يُرَكَّب، خيارات. مع المكوّنات standalone، لا حاجة لـ RouterModule.forRoot() — يكفي تمرير المصفوفة في provideRouter() ضمن إعداد التطبيق.

// app.routes.ts
import { Routes } from "@angular/router";

export const routes: Routes = [
  { path: "", component: HomeComponent },
  {
    path: "clients",
    loadComponent: () => import("./features/clients/clients-list.component")
      .then(m => m.ClientsListComponent),
  },
  {
    path: "clients/:id",
    loadComponent: () => import("./features/clients/client-detail.component")
      .then(m => m.ClientDetailComponent),
  },
  {
    path: "admin",
    canActivate: [authGuard],
    loadChildren: () => import("./features/admin/admin.routes").then(m => m.adminRoutes),
  },
  { path: "**", redirectTo: "" },
];

الـ loadComponent يُحمّل مكوّناً واحداً عند الطلب. loadChildren يُحمّل شجرة فرعيّة كاملة من الـ routes.

Guards

الـ guards الحديثة دوال لا classes. CanActivateFn تستقبل الـ route وحالة الـ router، تنفّذ منطق الإذن، وتُرجع true أو false أو UrlTree لإعادة التوجيه. الدالّة inject() تُتيح الوصول إلى الخدمات من داخل الـ guard.

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

export const authGuard: CanActivateFn = () => {
  const auth = inject(AuthService);
  const router = inject(Router);
  if (auth.isAuthenticated()) return true;
  router.navigate(["/login"]);
  return false;
};

الـ guards الحديثة دوال. أبسط من classes الإصدارات السابقة.

Resolvers

للتحميل المسبق للبيانات قبل التنقّل:

import { ResolveFn } from "@angular/router";

export const clientResolver: ResolveFn<Client> = (route) => {
  const service = inject(ClientService);
  return service.byId(route.paramMap.get("id")!);
};

الـ resolvers تُحمّل البيانات قبل أن يُفعَّل الـ route — مفيد لجلب تفاصيل بطاقة منتج قبل عرض المكوّن. كما الـ guards، صارت دوال مُكتَّبة (ResolveFn<Type>) لها وصول إلى inject().

9. النماذج: Reactive مقابل Template

يقترح Angular منهجين.

Reactive Forms (الموصى به)

النماذج التفاعليّة في Angular تصف بنية النموذج في TypeScript خالص، ممّا يجعلها أسهل اختباراً وتأليفاً من template-driven. الـ FormBuilder هو الأداة المساعدة التي تجعل التصريح موجزاً. الـ validators دوال صرفة تُرجع null عند النجاح أو كائن أخطاء فيما عدا ذلك.

import { FormBuilder, ReactiveFormsModule, Validators } from "@angular/forms";

@Component({
  selector: "app-client-form",
  standalone: true,
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="form" (ngSubmit)="submit()">
      <input formControlName="nom" placeholder="الاسم" />
      <input formControlName="email" placeholder="البريد" />
      <button [disabled]="form.invalid">حفظ</button>
    </form>
  `,
})
export class ClientFormComponent {
  private fb = inject(FormBuilder);

  form = this.fb.group({
    nom: ["", [Validators.required, Validators.minLength(2)]],
    email: ["", [Validators.required, Validators.email]],
  });

  submit() {
    if (this.form.valid) {
      const data = this.form.getRawValue();
      // ...
    }
  }
}

الاستخدام: النماذج المعقّدة، validation شرطي، تبعيّات بين الحقول، نماذج ديناميكيّة. المنهج المُوصى به في 2026.

Template-driven Forms

أبسط نحويّاً لكن أقلّ قوّة. للنماذج التافهة فقط.

Validation مخصّص

للتحقّق من أنّ بريداً إلكترونيّاً غير مستعمل سابقاً على الخادم، validator غير متزامن يقوم بالاستعلام لحظة blur. الحقل يدخل حالة pending أثناء الاستدعاء، ثمّ valid أو invalid حسب الردّ. switchMap يضمن أنّ كلّ كتابة جديدة تُلغي الطلب السابق.

function emailUniqueValidator(service: ClientService): AsyncValidatorFn {
  return (ctrl) => service.emailExists(ctrl.value).pipe(
    map(exists => exists ? { emailTaken: true } : null),
  );
}

Validators غير المتزامنة أصيلة في Angular، عكس React حيث تحتاج بناءها بـ react-hook-form أو ما يشبهها.

النماذج الديناميكيّة

لحالات تكون فيها الحقول نفسها ديناميكيّة (نموذج مُولَّد من إعداد في قاعدة بيانات، نموذج بأقسام شرطيّة)، الـ FormArray وتأليف FormGroup مدعومان طبيعيّاً. هذه المرونة ثمينة في تطبيقات أعمال معقّدة: نماذج استبيان، نماذج عروض أسعار، نماذج إعداد منتج. حيث تطلب أُطر أخرى مكتبة مخصّصة أو كثيراً من الكود المخصّص، يوفّر Angular الميكانيكا الأساسيّة.

Typed Forms

منذ Angular 14، صارت Reactive Forms مُكتَّبة بالكامل. بنية النموذج معلومة لـ TypeScript، الإكمال التلقائي يشتغل على النماذج الفرعيّة، والقيم مُكتَّبة. هذا التحسين الصامت قضى على فئة كاملة من الأخطاء الشائعة في النماذج المعقّدة. للمشاريع القديمة التي لا تزال على untyped forms، الهجرة إلى typed forms تدريجيّة وتجلب مكسباً ملموساً في المتانة دون تغيير منطق العمل.

10. الأداء والتحسين

Change detection

مع provideZonelessChangeDetection() (Angular 18+)، Angular لم يعد يستخدم Zone.js. الـ change detection يُطلَق فقط عند تغيّرات الـ signals. الأداء يرتفع، خصوصاً في واجهات فيها كثير من المؤقّتات أو الأحداث.

للمكوّنات التي لا تزال في النمط الكلاسيكي: ChangeDetectionStrategy.OnPush يُخفّض عبء change detection.

@Component({
  selector: "app-card",
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `...`,
})

إستراتيجيّة OnPush تقول لـ Angular « لا تُعِد رسم هذا المكوّن إلّا حين يتغيّر أحد مدخلاته بالمرجع أو حين يتعدّل signal تقرؤه القالب ». مُقترِنة بـ signals، تُخفّض دورات change detection بشكل ملحوظ — هي أساس تطبيقات zoneless.

حجم الحزمة (bundle size)

لفهم ما يثقل الحزمة النهائيّة، الـ CLI يُنتج تقرير JSON قابل للاستثمار من قِبَل source-map-explorer أو webpack-bundle-analyzer. التقرير المفتوح في المتصفّح يعرض treemap حيث يمثّل كلّ مستطيل وحدة بحجمها النسبيّ — يتّضح فوراً سبب الـ bundle الثقيل.

ng build --configuration production --stats-json
npx webpack-bundle-analyzer dist/mon-app/stats.json

حدّد التبعيّات الكبيرة. عادة: moment.js (استبدل بـ date-fns)، lodash كاملاً (استورد ما يلزم فقط)، مكتبات UI سيّئة الـ tree-shaking.

Lazy loading

لا غنى عنه لـ routes نادرة الاستعمال. التفاصيل في تحسين أداء Angular.

تحسين الصور

يوفّر Angular توجيهاً NgOptimizedImage يطبّق تلقائيّاً أفضل الممارسات: lazy loading، أبعاد محدّدة لتفادي layout shift، صيغ حديثة (WebP وAVIF)، srcset لشاشات مختلفة. استعمله بشكل ممنهج بدلاً من <img> الكلاسيكي للصور المهمّة. الأثر على Core Web Vitals (LCP، CLS) فوريّ وقابل للقياس.

التحميل المسبق الذكيّ

PreloadAllModules يُحمّل كلّ الـ modules المُؤجَّلة بعد الإقلاع. لـ routes مستعمَلة بكثرة: استعمل استراتيجيّة مخصّصة لا تُحمّل مسبقاً إلّا ما يُرجَّح زيارته، استناداً إلى الـ routes المجاورة أو أنماط تنقّل ملاحَظة. تتجنّب دفع كلفة كلّ شيء فوراً مع تسريع الانتقالات المُرجَّحة.

Server Side Rendering

إضافة الرسم من الخادم لمشروع قائم تتلخّص في أمر واحد. الـ schematic يثبّت تبعيّات Node اللازمة، يُولّد src/server.ts وsrc/main.server.ts، يضبط angular.json ويُهيّئ pre-rendering لـ routes الثابتة. الخادم Express المُجمَّع يصبح قابلاً للنشر خلف VPS، حاوية Docker، أو خدمة serverless.

ng add @angular/ssr

للمواقع العامّة حيث يهمّ SEO والـ first paint. الإعداد الحديث آلي إلى حدّ بعيد بفضل الـ CLI، ممّا يبسّط التبنّي للفِرَق التي لا تملك خبيراً متخصّصاً في SSR.

11. أسئلة شائعة

Angular أم React لمشروع جديد؟

يتعلّق الأمر بالفريق والسياق. Angular أفضل لـ: الفرق الكبيرة، تطبيقات الأعمال المعقّدة، الفرق المعتادة على Angular أو Java/.NET. React أفضل لـ: الفرق الصغيرة، النظام البيئي الغنيّ بالمكتبات، المواقع العامّة ذات SEO. Vue موضع وسط بين الاثنين.

هل يجب نقل تطبيق Angular قديم؟

إذا كان على Angular 15+: حافظ عليه وانقل تدريجيّاً إلى الميزات الحديثة (signals، standalone). إذا كان على AngularJS (1.x): هذه إعادة كتابة كاملة، لا هجرة. قدّر الكلفة في مواجهة الرهان التجاريّ.

هل NgRx لا يزال مهمّاً؟

للتطبيقات المعقّدة ذات الحالة المُشتركَة الكثيفة: نعم. لمعظم الحالات، signals تكفي في 2026. NgRx يظلّ مهمّاً في سياقات يتقن فيها الفريق Redux بالفعل وحيث تجلب dev-tools الخاصّة بـ NgRx قيمة فعليّة.

كم من الوقت لينتقل مطوّر React إلى Angular؟

بضعة أسابيع للأساسيّات (المكوّنات، الخدمات، RxJS الأساسي، التوجيه)، بضعة أشهر للتمكّن (النماذج المعقّدة، RxJS المتقدّم، التحسين، المعمارية). المنحنى أحدّ من React لكن الاستثمار مربح بشكل دائم.

هل standalone إلزامي أم يمكن البقاء على NgModule؟

ليس إلزاميّاً لكن مُوصى به بقوّة للمشاريع الجديدة. الـ NgModules لا تزال مدعومة والمزج ممكن أثناء الهجرات. الاتّجاه طويل المدى للإطار نحو standalone حصراً.

هل Angular Material هي مجموعة UI الوحيدة؟

لا. PrimeNG وNebular وClarity Design بدائل. لتطبيق ببراندينغ مخصّص: Tailwind CSS مع مكوّنات مخصّصة خيار قابل للحياة أيضاً. تبقى Material الأكثر انسجاماً مع تطوّر Angular.

SSR في Angular: جاهز للإنتاج؟

نعم منذ Angular 17. Hydration محسّن، SSR streaming، اندماج مع الأدوات الجديدة. أبسط من ذي قبل، ويُقارن بـ Next.js لـ React.