كانت واجهاتنا تتصرف بعشوائية: كيف أنقذتنا ‘آلات الحالة المحدودة’ (State Machines) من جحيم الفوضى؟

يا جماعة الخير، السلام عليكم ورحمة الله. اسمحوا لي اليوم أحكي لكم قصة من قلب المعركة، من أيام ما كنا “نلطم على راسنا” من كثرة المشاكل في واجهات المستخدم اللي بنبنيها.

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

وصلنا لمرحلة أن إصلاح “بَغ” واحد كان يخلق اثنين جداد. كان الفريق محبط، والعميل بدأ يفقد صبره. في إحدى الليالي وأنا أحاول تتبع مشكلة “مستعصية”، وجدت نفسي أمام عشرات المتغيرات من نوع `isLoading`, `isFetching`, `hasError`, `isSuccess`, `isEditing`, `isSaving`… شعرت أني في متاهة. وقتها قلت لنفسي: “لأ، ما بزبط هيك. لازم يكون في طريقة أرتب من هيك”. وهنا كانت بداية رحلتي مع منقذنا: آلات الحالة المحدودة.

ما هي “آلة الحالة المحدودة” (Finite State Machine)؟ ببساطة شديدة

قبل ما ندخل في التفاصيل التقنية المعقدة، خلّونا نبسّط المفهوم. تخيل “إشارة المرور”. هي أبسط مثال على آلة الحالة.

• لديها عدد محدود من الحالات: (أخضر، أصفر، أحمر).
• في أي لحظة، لا يمكن أن تكون إلا في حالة واحدة فقط. مستحيل تكون “أخضر” و”أحمر” في نفس الوقت.
• تنتقل من حالة إلى أخرى بناءً على حدث معين (مثلاً، انتهاء عداد الوقت).

هذا هو جوهر آلة الحالة المحدودة (FSM): نظام لا يمكن أن يوجد إلا في حالة واحدة في كل مرة، وينتقل بين حالات محددة مسبقًا بناءً على أحداث معينة. هذا المفهوم البسيط، يا جماعة، هو ترياق فوضى الواجهات الرسومية.

المكونات الأساسية لآلة الحالة

1. الحالات (States): هي الأوضاع المختلفة التي يمكن أن يكون عليها نظامك. مثلاً في عملية جلب بيانات من سيرفر: idle (في وضع الخمول)، loading (جاري التحميل)، success (نجح)، error (فشل).
2. الأحداث (Events/Transitions): هي المحفزات التي تنقل النظام من حالة إلى أخرى. مثلاً، عندما يضغط المستخدم على زر “تحديث”، يقع حدث FETCH الذي ينقلنا من حالة idle إلى loading.
3. الإجراءات (Actions): هي المهام التي يتم تنفيذها عند الدخول إلى حالة أو الخروج منها. مثلاً، عند الدخول إلى حالة loading، نقوم بإجراء “إظهار مؤشر التحميل”. وعند الدخول لحالة error، نقوم بإجراء “إظهار رسالة الخطأ”.

قبل آلات الحالة: جحيم المتغيرات البوليانية (Boolean Flags)

دعونا نرى كيف كنا ندير الأمور في الماضي، وكيف أن هذه الطريقة هي وصفة للكوارث. تخيل أن لدينا مكونًا بسيطًا لجلب بيانات وعرضها.

“كان الكود الخاص بنا مليئًا بالمتغيرات المنفصلة التي تحاول وصف حالة واحدة. والنتيجة؟ حالات مستحيلة وأخطاء لا تنتهي.”

هكذا كان يبدو الكود (مثال بلغة جافاسكريبت، لكن الفكرة تنطبق على أي لغة):

// The "Boolean Flags" Hell 🔥
let data = null;
let error = null;
let isLoading = false;
let isSuccess = false;

async function fetchData() {
  isLoading = true; // الحالة الأولى
  isSuccess = false;
  error = null;
  // ... (Update UI to show spinner)

  try {
    const response = await api.get('/data');
    data = response.data;
    isLoading = false;
    isSuccess = true; // الحالة الثانية
    // ... (Update UI to show data)
  } catch (e) {
    error = e.message;
    isLoading = false; // الحالة الثالثة... هل نسينا شيئًا؟
    // ... (Update UI to show error)
  }
}

ما هي المشكلة هنا؟

• حالات مستحيلة: ماذا لو حدث خطأ في الكود ونسينا أن نجعل isLoading = false بعد حدوث خطأ؟ سيظل مؤشر التحميل ظاهرًا مع رسالة الخطأ! يمكن أن ينتهي بنا الأمر بـ isLoading و isSuccess كلاهما true. هذه حالات “مستحيلة” منطقيًا، لكنها ممكنة جدًا في هذا الكود.
• صعوبة التوسع: ماذا لو أردنا إضافة حالة “إعادة المحاولة” (retrying)؟ سنحتاج لمتغير جديد isRetrying ومزيد من الشروط المتداخلة، مما يزيد الطين بلة.
• صعوبة القراءة والتصحيح: لفهم حالة المكون، عليك قراءة قيمة 4 متغيرات مختلفة. هذا مرهق جدًا.

بعد آلات الحالة: النظام والوضوح في الواجهة

الآن، لنطبق مبدأ آلة الحالة. بدلًا من عدة متغيرات، سنستخدم متغيرًا واحدًا فقط لوصف الحالة. دعنا نسميه status.

// The State Machine Heaven ✨
let data = null;
let error = null;
let status = 'idle'; // الحالات الممكنة: 'idle', 'loading', 'success', 'error'

async function fetchData() {
  status = 'loading';
  // ... (Update UI based on 'loading' status)

  try {
    const response = await api.get('/data');
    data = response.data;
    status = 'success';
    // ... (Update UI based on 'success' status)
  } catch (e) {
    error = e.message;
    status = 'error';
    // ... (Update UI based on 'error' status)
  }
}

انظر إلى هذا الجمال! الآن أصبح من المستحيل أن نكون في حالة “تحميل” و “نجاح” في نفس الوقت. الحالة الحالية للمكون واضحة تمامًا من خلال متغير واحد فقط. أصبح الكود أسهل في القراءة، وأكثر متانة، وأقل عرضة للأخطاء بشكل كبير.

مثال عملي: نموذج تسجيل الدخول

لنفصل أكثر في مثال شائع. نموذج تسجيل الدخول له الحالات التالية:

• idle: النموذج فارغ وجاهز للإدخال. زر “تسجيل الدخول” مفعّل.
• submitting: تم الضغط على الزر، والبيانات تُرسل للسيرفر. زر “تسجيل الدخول” معطّل ويظهر بجانبه مؤشر تحميل.
• error: السيرفر أعاد خطأ (مثلاً، كلمة المرور خاطئة). تظهر رسالة الخطأ، ويعود زر “تسجيل الدخول” مفعّلاً ليتمكن المستخدم من المحاولة مرة أخرى.
• success: تم تسجيل الدخول بنجاح. يتم إخفاء النموذج وتوجيه المستخدم إلى لوحة التحكم.

عندما تفكر في واجهتك بهذه الطريقة (كمجموعة من الحالات المترابطة)، يصبح تصميم الواجهة وتطويرها “شغل مرتب” ومنظم. أنت والمصمم تتحدثان نفس اللغة، والكود يعكس هذه الحالات بوضوح.

نصيحة من أبو عمر

عندما تبدأ في مشروع جديد أو تصلح مكونًا قديمًا، أول شيء تفعله هو أن تسأل نفسك: “ما هي الحالات التي يمكن أن يمر بها هذا المكون؟”. ارسمها على ورقة أو استخدم أداة بسيطة. هذا التمرين الذهني وحده سيوفر عليك ساعات من تصحيح الأخطاء لاحقًا.

الارتقاء بالمستوى: استخدام مكتبات متخصصة مثل XState

للحالات البسيطة، يكفي استخدام متغير status مع جملة switch أو if/else. لكن ماذا عن الواجهات المعقدة جدًا، كتلك التي كنت أعمل عليها في قصتي؟ هنا يأتي دور المكتبات المتخصصة.

مكتبة مثل XState هي بمثابة “سوبرمان” لآلات الحالة. تسمح لك بتعريف الحالات، والأحداث، والإجراءات بطريقة تعريفية (declarative) واضحة جدًا.

أجمل ما في XState هو أنها تتيح لك تصور آلة الحالة الخاصة بك بشكل رسومي. يمكنك أن ترى كل الحالات الممكنة وكيفية الانتقال بينها، مما يجعل فهم المنطق المعقد أمرًا في غاية السهولة، حتى لغير المبرمجين في فريقك.

نصيحة عملية من خبرتي

لا تبدأ بـ XState مباشرة إذا كان المفهوم جديدًا عليك. ابدأ بتطبيق آلة الحالة البسيطة (متغير واحد و switch) في مكوناتك. عندما تشعر أن جملة switch أصبحت معقدة جدًا وبدأت تحتوي على منطق متداخل، حينها يكون الوقت قد حان لاستخدام مكتبة متخصصة مثل XState. التدرج هو مفتاح التعلم الصحيح.

فوائد تتجاوز مجرد الكود

تبني هذا النهج له فوائد تتجاوز الكود النظيف:

• تواصل أفضل بين الفريق: عندما يتفق المصمم والمبرمج ومدير المنتج على مخطط الحالات، يصبح الجميع على نفس الصفحة.
• تقليل الأخطاء بشكل جذري: القضاء على “الحالات المستحيلة” يعني القضاء على فئة كاملة من الأخطاء المزعجة.
• سهولة التطوير والصيانة: إضافة حالة جديدة (مثل حالة “نسيت كلمة المرور”) تصبح عملية واضحة ومحددة، بدلًا من عملية تخمين فوضوية.

خلاصة الكلام والنصيحة الأخيرة 💡

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

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

ويعطيكو العافية! 🙏