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

إذًا، إليك كيفية تعاملي مع الأمر.

الرعب الأولي

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

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

كسرها

لقد بدأت بتحديد المسؤوليات المختلفة للمكون. كانت هناك ثلاث مناطق واضحة:

1. إدارة الحالة: كانت معالجة حالة المكون متشابكة مع منطق واجهة المستخدم.

2. استدعاءات واجهة برمجة التطبيقات: جلب البيانات ومعالجة حالات التحميل.

3. عرض واجهة المستخدم: عرض البيانات في بنية واجهة مستخدم معقدة إلى حد ما.
   يجب فصل كل من هذه المسؤوليات.

استخراج الخطافات لمنطق الحالة وواجهة برمجة التطبيقات (API).

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

ذكر بعض الكود هنا (ليس الأصلي):

function useDataFetching(apiEndpoint) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchData() {
      try {
        let response = await fetch(apiEndpoint);
        let result = await response.json();
        setData(result);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    }

    fetchData();
  }, [apiEndpoint]);

  return { data, loading, error };
}

باستخدام useDataFetching، قمت بسحب منطق استدعاء واجهة برمجة التطبيقات (API) والتعامل مع حالات التحميل والخطأ. الآن، يحتاج المكون فقط إلى استدعاء هذا الخطاف والحصول على البيانات الضرورية، بشكل واضح وبسيط.

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

function renderLoading() {
  return 
Loading...
;
}

function renderError(error) {
  return 
Error: {error.message}
;
}

function renderData(data) {
  return 
{/* Complex UI logic here */}
;
}
//After that, component is ni much pretty shape

function MyComponent() {
  const { data, loading, error } = useDataFetching('/api/data-endpoint');

  if (loading) return renderLoading();
  if (error) return renderError(error);
  if (data) return renderData(data);

  return null;
}

الحديث النهائي

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

عززت هذه التجربة بعض الدروس الأساسية بالنسبة لي:

• لا تخف من إعادة البناء: من السهل ترك التعليمات البرمجية الفوضوية كما هي، خاصة عندما تعمل. لكن أخذ الوقت الكافي لتنظيف الأمر يجعل حياتك – وحياة نفسك المستقبلية – أسهل بكثير.

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

• حافظ على البساطة: إن تبسيط وظيفة العرض عن طريق إلغاء تحميل المنطق إلى وظائف أصغر جعل المكون أكثر قابلية للقراءة.

لذا، إذا كان لديك مكون فوضوي مثلك، فلا تتردد في إعادة البناء. لا يقتصر الأمر على التعليمات البرمجية النظيفة فحسب، بل يتعلق بجعل حياتك أسهل كمطور. ومن لا يريد ذلك؟