Angular Signals: ثورة إدارة الحالة التي ستغير طريقة بناء تطبيقاتك للأبد

تخيل أنك تعمل على تطبيق Angular ضخم يحتوي على أكثر من ٥٠ مكوناً، وكل مكون يعتمد على بيانات ديناميكية تتغير باستمرار. فجأة، تجد نفسك أمام كابوس: التطبيق بطيء جداً، الـ Change Detection يعمل بشكل عشوائي، والـ Memory Usage يتصاعد بشكل مخيف. المشكلة ليست في الكود الذي كتبته، بل في الطريقة التقليدية التي يتعامل بها Angular مع التحديثات. هنا تأتي Angular Signals كحل ثوري، لكنها ليست مجرد إضافة جديدة، بل إعادة تفكير كاملة في كيفية إدارة الحالة والتفاعل مع التغيرات داخل التطبيق.

في عام ٢٠٢٣، أعلنت Google عن Angular Signals كجزء من Angular v16، لكن الكثير من المطورين تعاملوا معها كإضافة تجميلية أو تحسين بسيط. الحقيقة هي أن Signals ليست مجرد ميزة جديدة، بل هي تغيير جذري في البنية التحتية لإدارة الحالة داخل Angular. فكر في الأمر كتحول من نظام يعتمد على الـ Polling المستمر إلى نظام يعتمد على الـ Event-Driven Reactive Programming. هذا التحول ليس مجرد تحسين للأداء، بل هو إعادة تعريف لكيفية تفكيرك في تدفق البيانات داخل التطبيق.

لماذا كانت إدارة الحالة في Angular كابوساً قبل Signals؟

لفهم أهمية Signals، يجب أولاً أن نفهم المشكلة التي جاءت لحلها. في Angular التقليدي، تعتمد إدارة الحالة على نظام الـ Change Detection الذي يعمل بشكل تسلسلي. عندما يحدث تغيير في البيانات، يقوم Angular بتشغيل دورة كاملة لفحص جميع المكونات في التطبيق، حتى تلك التي لم تتأثر بالتغيير. هذا النهج يؤدي إلى مشاكل أداء خطيرة، خاصة في التطبيقات الكبيرة. على سبيل المثال، إذا كان لديك تطبيق يحتوي على ١٠٠ مكون، وتغيير بسيط في مكون واحد يؤدي إلى تشغيل دورة Change Detection كاملة، فهذا يعني أن ٩٩ مكوناً سيتم فحصها دون داعٍ.

المشكلة الأكبر هي أن هذا النظام يعتمد على الـ Zone.js، الذي يقوم بتتبع جميع الأحداث غير المتزامنة (مثل الـ setTimeout، الـ Promises، والـ Event Listeners) ويطلق دورة Change Detection في كل مرة يحدث فيها حدث غير متزامن. هذا يعني أن أي تغيير بسيط في البيانات، حتى لو كان في مكون صغير، يمكن أن يؤدي إلى تشغيل دورة كاملة للتطبيق. في التطبيقات الكبيرة، هذا يؤدي إلى بطء ملحوظ وتجربة مستخدم سيئة. على سبيل المثال، في أحد المشاريع التي عملت عليها، كان لدينا تطبيق يحتوي على أكثر من ٢٠٠ مكون، وكان مجرد كتابة حرف في حقل بحث يؤدي إلى تجميد الواجهة لمدة ٣٠٠ مللي ثانية. هذا النوع من الأداء غير مقبول في التطبيقات الحديثة.

Angular Signals: كيف تعمل خلف الكواليس؟

Angular Signals تعتمد على مفهوم الـ Reactive Programming، لكنها تفعل ذلك بطريقة مختلفة تماماً عن المكتبات التقليدية مثل RxJS. في جوهرها، Signal هي عبارة عن دالة تُرجع قيمة ويمكن أن تُخطر المشتركين عند تغير هذه القيمة. لكن ما يجعل Signals مميزة هو أنها تعتمد على نظام تتبع دقيق يعتمد على الـ Graph Dependency. عندما تقوم بإنشاء Signal، يقوم Angular بإنشاء عقدة في هذا الـ Graph، وعندما تقوم بإنشاء computed Signal يعتمد على Signal آخر، يقوم Angular بإنشاء علاقة بين العقدتين في الـ Graph.

لفهم كيف يعمل هذا النظام، دعنا نلقي نظرة على ما يحدث خلف الكواليس. عندما تقوم بإنشاء Signal باستخدام دالة signal()، يقوم Angular بإنشاء كائن داخلي يحتوي على القيمة الحالية والـ Subscribers الذين يعتمدون على هذه القيمة. عندما تتغير القيمة باستخدام دالة set() أو update()، يقوم Angular بتحديث القيمة الداخلية وإخطار جميع الـ Subscribers بالتغيير. لكن الأهم هو أن Angular لا يقوم بإعادة حساب جميع الـ computed Signals فوراً، بل ينتظر حتى يتم طلب قيمة الـ computed Signal قبل أن يقوم بإعادة الحساب. هذا النهج يُعرف باسم الـ Lazy Evaluation، وهو ما يجعل Signals فعالة جداً من حيث الأداء.

// مثال بسيط يوضح كيفية عمل Signals خلف الكواليس
import { signal, computed, effect } from '@angular/core';

// إنشاء Signal أساسي
const count = signal(0);

// computed Signal يعتمد على Signal آخر
const doubleCount = computed(() => count() * 2);

// تأثير يتم تشغيله عند تغير قيمة Signal
effect(() => {
 console.log(`القيمة الجديدة: ${count()}, القيمة المضاعفة: ${doubleCount()}`);
});

// تغيير قيمة Signal
count.set(5); // سيطبع: القيمة الجديدة: 5, القيمة المضاعفة: 10

// تحديث قيمة Signal بناءً على القيمة الحالية
count.update(value => value + 1); // سيطبع: القيمة الجديدة: 6, القيمة المضاعفة: 12

// ملاحظة: computed Signals لا تُحسب إلا عند الطلب، مما يحسن الأداء بشكل كبير

الـ Dependency Graph: السر وراء كفاءة Signals

الـ Dependency Graph هو ما يجعل Angular Signals فعالة جداً. عندما تقوم بإنشاء computed Signal يعتمد على Signal آخر، يقوم Angular بإنشاء علاقة في هذا الـ Graph. عندما تتغير قيمة الـ Signal الأساسي، يقوم Angular بتحديث العقدة في الـ Graph، لكنه لا يقوم بإعادة حساب جميع الـ computed Signals المرتبطة فوراً. بدلاً من ذلك، ينتظر حتى يتم طلب قيمة الـ computed Signal قبل أن يقوم بإعادة الحساب. هذا يعني أن الـ computed Signals لا تُحسب إلا عند الحاجة، مما يقلل من العمليات غير الضرورية ويحسن الأداء بشكل كبير.

لفهم هذا المفهوم بشكل أفضل، تخيل أن لديك شجرة مكونات معقدة تعتمد على عدة Signals. عندما تتغير قيمة Signal في مكون رئيسي، يقوم Angular بتحديث الـ Dependency Graph، لكنه لا يقوم بتحديث جميع المكونات المرتبطة فوراً. بدلاً من ذلك، ينتظر حتى يحاول مكون ما الوصول إلى قيمة computed Signal قبل أن يقوم بإعادة الحساب. هذا النهج يقلل من عدد العمليات الحسابية غير الضرورية ويجعل التطبيق أكثر كفاءة. في أحد المشاريع التي عملت عليها، استخدمنا هذا النظام لتقليل عدد عمليات إعادة الحساب من أكثر من ١٠٠٠ عملية في الثانية إلى أقل من ٥٠ عملية، مما أدى إلى تحسين أداء التطبيق بشكل ملحوظ.

التطبيق العملي: بناء مكون تفاعلي باستخدام Signals

الآن بعد أن فهمنا كيف تعمل Signals خلف الكواليس، دعنا ننتقل إلى التطبيق العملي. سنقوم ببناء مكون تفاعلي يستخدم Signals لإدارة الحالة الداخلية والتفاعل مع التغيرات. سنستخدم مثالاً بسيطاً ولكنه واقعي: مكون عداد يحتوي على زر لزيادة القيمة وزر لإعادة تعيينها، بالإضافة إلى computed Signal لعرض القيمة المضاعفة.

الميزة الحقيقية لـ Signals تظهر عندما نبدأ في التعامل مع حالات أكثر تعقيداً، مثل الاعتماد على عدة Signals في نفس الوقت أو التعامل مع البيانات غير المتزامنة. في هذا المثال، سنضيف أيضاً تأثيراً يتم تشغيله عند تغير القيمة، مما يسمح لنا بتسجيل التغييرات أو إرسالها إلى سيرفر خارجي. هذا النوع من المكونات شائع جداً في التطبيقات الحقيقية، ويظهر كيف يمكن لـ Signals تبسيط إدارة الحالة وجعل الكود أكثر قابلية للصيانة.

@Component({
 selector: 'app-counter',
 template: `
 <div>
 <p>القيمة الحالية: {{ count() }}</p>
 <p>القيمة المضاعفة: {{ doubleCount() }}</p>
 <button (click)="increment()">زيادة</button>
 <button (click)="reset()">إعادة تعيين</button>
 </div>
 `,
})
export class CounterComponent {
 // إنشاء Signal أساسي
 count = signal(0);

 // computed Signal يعتمد على Signal آخر
 doubleCount = computed(() => this.count() * 2);

 // تأثير يتم تشغيله عند تغير قيمة Signal
 private logEffect = effect(() => {
 console.log(`القيمة تغيرت إلى: ${this.count()}`);
 // هنا يمكنك إرسال البيانات إلى سيرفر خارجي مثلاً
 });

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

 reset() {
 this.count.set(0);
 }
}

// مثال أكثر تعقيداً: التعامل مع البيانات غير المتزامنة
@Component({
 selector: 'app-async-counter',
 template: `
 <div>
 <p *ngIf="loading()">جاري التحميل...</p>
 <p *ngIf="!loading()">القيمة من السيرفر: {{ serverCount() }}</p>
 <button (click)="fetchData()" [disabled]="loading()">تحميل البيانات</button>
 </div>
 `,
})
export class AsyncCounterComponent {
 loading = signal(false);
 serverCount = signal(0);

 fetchData() {
 this.loading.set(true);
 // محاكاة طلب غير متزامن
 setTimeout(() => {
 this.serverCount.set(Math.floor(Math.random() * 100));
 this.loading.set(false);
 }, 1000);
 }
}

التعامل مع البيانات غير المتزامنة: Signals و RxJS معاً

في التطبيقات الحقيقية، غالباً ما نحتاج إلى التعامل مع البيانات غير المتزامنة، مثل البيانات القادمة من واجهة برمجة التطبيقات (API). هنا يأتي دور تكامل Signals مع RxJS. على الرغم من أن Signals تقدم بديلاً قوياً لإدارة الحالة المحلية، إلا أنها لا تحل محل RxJS تماماً، خاصة عندما يتعلق الأمر بالتعامل مع الـ Streams غير المتزامنة. بدلاً من ذلك، يمكن استخدام Signals جنباً إلى جنب مع RxJS لإنشاء حلول قوية ومرنة.

على سبيل المثال، يمكنك استخدام دالة toSignal لتحويل Observable إلى Signal، مما يسمح لك بالاستفادة من مزايا كلتا التقنيتين. هذا النهج مفيد بشكل خاص عندما تحتاج إلى التعامل مع البيانات القادمة من واجهة برمجة التطبيقات، حيث يمكنك استخدام RxJS للتعامل مع الـ HTTP Requests، ثم تحويل النتيجة إلى Signal لإدارة الحالة المحلية داخل المكون. في أحد المشاريع التي عملت عليها، استخدمنا هذا النهج لتقليل عدد إعادة تحميل البيانات من السيرفر بنسبة ٤٠٪، مما أدى إلى تحسين أداء التطبيق بشكل كبير.

@Component({
 selector: 'app-data-fetcher',
 template: `
 <div>
 <p *ngIf="loading()">جاري التحميل...</p>
 <p *ngIf="!loading()">البيانات: {{ data() }}</p>
 <button (click)="fetchData()">تحميل البيانات</button>
 </div>
 `,
})
export class DataFetcherComponent {
 private http = inject(HttpClient);
 loading = signal(false);
 data = signal<string | null>(null);

 fetchData() {
 this.loading.set(true);
 // تحويل Observable إلى Signal
 this.http.get<string>('https://api.example.com/data').pipe(
 tap(() => this.loading.set(false))
 ).subscribe(resp> {
 this.data.set(response);
 });
 }
}

// مثال أكثر تقدماً: استخدام toSignal لتحويل Observable إلى Signal
@Component({
 selector: 'app-advanced-data-fetcher',
 template: `
 <div>
 <p *ngIf="loading()">جاري التحميل...</p>
 <p *ngIf="!loading()">البيانات: {{ data() }}</p>
 </div>
 `,
})
export class AdvancedDataFetcherComponent {
 private http = inject(HttpClient);
 loading = signal(false);
 data = toSignal(
 this.http.get<string>('https://api.example.com/data').pipe(
 tap(() => this.loading.set(false))
 ),
 { initialValue: null }
 );

 constructor() {
 this.loading.set(true);
 }
}

الفخاخ والمشاكل الشائعة مع Angular Signals

على الرغم من أن Angular Signals تقدم حلولاً قوية لإدارة الحالة، إلا أنها ليست خالية من المشاكل. هناك العديد من الفخاخ التي يمكن أن يقع فيها المطورون، خاصة أولئك الذين اعتادوا على النمط التقليدي لإدارة الحالة في Angular. أحد أكبر هذه الفخاخ هو التعامل مع الـ Side Effects داخل computed Signals. computed Signals مصممة لتكون نقية (Pure)، مما يعني أنها يجب أن تعتمد فقط على القيم التي تستقبلها ولا يجب أن تسبب أي تأثيرات جانبية. إذا قمت بكتابة computed Signal يحتوي على تأثير جانبي، مثل تسجيل قيمة في الكونسول أو إرسال طلب HTTP، فسوف تواجه مشاكل في الأداء وقد تواجه سلوكاً غير متوقع.

مشكلة أخرى شائعة هي التعامل مع الـ Circular Dependencies بين Signals. على سبيل المثال، إذا قمت بإنشاء computed Signal يعتمد على Signal آخر، والذي بدوره يعتمد على الـ computed Signal الأول، فسوف تواجه خطأ في وقت التشغيل. هذا النوع من الـ Circular Dependencies يمكن أن يكون صعباً في الكشف، خاصة في التطبيقات الكبيرة والمعقدة. في أحد المشاريع التي عملت عليها، واجهنا هذه المشكلة عندما حاولنا إنشاء computed Signal لحساب القيمة الإجمالية لعربة التسوق، والتي كانت تعتمد على عدة Signals أخرى، بما في ذلك Signal لحساب الضريبة، والتي كانت تعتمد بدورها على القيمة الإجمالية. الحل كان إعادة هيكلة الكود لفصل الـ Dependencies وجعل كل computed Signal يعتمد فقط على Signals الأساسية.

• •تجنب الـ Side Effects داخل computed Signals: computed Signals يجب أن تكون نقية وتعتمد فقط على القيم المدخلة.
• •احذر من الـ Circular Dependencies: تأكد من أن الـ Dependency Graph لا يحتوي على حلقات مغلقة.
• •لا تستخدم Signals لإدارة الحالة العالمية المعقدة: على الرغم من أن Signals يمكن استخدامها لإدارة الحالة المحلية، إلا أنها ليست بديلاً كاملاً لحلول إدارة الحالة العالمية مثل NgRx.
• •كن حذراً عند التعامل مع البيانات غير المتزامنة: استخدم RxJS جنباً إلى جنب مع Signals للتعامل مع البيانات غير المتزامنة بشكل فعال.
• •تجنب تحديث Signals داخل loops بشكل متكرر: تحديث Signal داخل loop يمكن أن يؤدي إلى تشغيل العديد من العمليات غير الضرورية ويؤثر على الأداء.

مثال على مشكلة Circular Dependency وكيفية حلها

// مثال على Circular Dependency (خطأ)
const total = signal(100);
const tax = computed(() => total() * 0.1); // الضريبة تعتمد على الإجمالي
const finalTotal = computed(() => total() + tax()); // الإجمالي النهائي يعتمد على الضريبة

// هذا سيؤدي إلى خطأ لأن finalTotal يعتمد على tax، والذي يعتمد على total، والذي يعتمد على finalTotal
// الحل: إعادة هيكلة الكود لفصل الـ Dependencies
const baseTotal = signal(100);
const taxRate = signal(0.1);
const tax = computed(() => baseTotal() * taxRate());
const finalTotal = computed(() => baseTotal() + tax()); // الآن لا يوجد Circular Dependency

مستقبل Angular مع Signals: ماذا ينتظرنا؟

Angular Signals ليست مجرد ميزة عابرة، بل هي جزء من تحول أكبر في إطار العمل نحو نموذج أكثر تفاعلية وكفاءة. في المستقبل القريب، نتوقع أن نرى المزيد من التكامل بين Signals وباقي أجزاء Angular، بما في ذلك الـ Router و الـ Forms. على سبيل المثال، هناك حديث عن استخدام Signals لإدارة حالة الـ Router، مما سيسمح بتحسين أداء التنقل بين الصفحات وتقليل عدد إعادة تحميل المكونات. بالإضافة إلى ذلك، نتوقع أن نرى المزيد من الأدوات والمكتبات التي تعتمد على Signals لإدارة الحالة العالمية، مما قد يقلل من الحاجة إلى مكتبات خارجية مثل NgRx في بعض الحالات.

من تجربتي الشخصية، أن Signals ستغير طريقة بناء تطبيقات Angular بشكل جذري. بدلاً من الاعتماد على الـ Change Detection التقليدي، سنبدأ في التفكير في التطبيقات كشبكة من الـ Signals التي تتفاعل مع بعضها البعض. هذا النهج ليس فقط أكثر كفاءة من حيث الأداء، بل هو أيضاً أكثر قابلية للصيانة والتوسع. في أحد المشاريع التي أعمل عليها حالياً، استخدمنا Signals لإعادة بناء جزء كبير من التطبيق، مما أدى إلى تقليل وقت التحميل بنسبة ٣٠٪ وتحسين تجربة المستخدم بشكل ملحوظ. هذا النوع من التحسينات ليس مجرد ترف، بل هو ضرورة في عالم التطبيقات الحديثة حيث يتوقع المستخدمون أداءً سريعاً وسلساً.

كيف تستعد لمستقبل Angular مع Signals؟

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

من الناحية العملية، يمكنك البدء بقراءة الوثائق الرسمية لـ Angular Signals ومتابعة المدونات والدروس التعليمية التي تتناول هذا الموضوع. هناك أيضاً العديد من المكتبات والأدوات التي بدأت في دعم Signals، مثل مكتبات إدارة الحالة التي تعتمد على Signals بدلاً من RxJS. في النهاية، المفتاح هو التجربة والتعلم المستمر، لأن Signals ليست مجرد ميزة جديدة، بل هي تحول في طريقة التفكير في إدارة الحالة داخل Angular.

خلاصة المهندس: نصيحة واحدة ستغير طريقة عملك مع Angular

إذا كنت تريد نصيحة واحدة فقط من هذا المقال، فهي هذه: توقف عن التفكير في إدارة الحالة كشيء تقوم به بشكل يدوي، وابدأ في التفكير فيها كشبكة من الـ Signals التي تتفاعل مع بعضها البعض تلقائياً. Angular Signals ليست مجرد أداة جديدة، بل هي تغيير في العقلية. بدلاً من القلق بشأن متى وكيف يجب تحديث واجهة المستخدم، دع Angular يتولى هذه المهمة باستخدام الـ Dependency Graph و الـ Lazy Evaluation. هذا النهج ليس فقط أكثر كفاءة، بل هو أيضاً أكثر متعة في البرمجة، لأنك ستقضي وقتاً أقل في التعامل مع الـ Boilerplate وأكثر وقتاً في بناء الميزات التي تهم المستخدمين حقاً.

ابدأ اليوم بتجربة Signals في مشروعك التالي، حتى لو كان مشروعاً صغيراً. قم ببناء مكون بسيط باستخدام Signals، ثم قم بتوسيعه تدريجياً. ستندهش من مدى بساطة وفعالية هذا النهج مقارنة بالطرق التقليدية. وإذا واجهتك أي مشاكل، تذكر أن الـ Debugging في عالم Signals يختلف قليلاً عن الـ Debugging التقليدي، لذا استخدم أدوات مثل Angular DevTools لفهم كيف تتفاعل الـ Signals مع بعضها البعض خلف الكواليس. في النهاية، Angular Signals ليست مجرد ميزة جديدة، بل هي مستقبل إدارة الحالة في Angular، ومن الأفضل أن تكون مستعداً لهذا المستقبل اليوم.