الإقليم ٠٣ — طاقم خلف الكواليس

يبني فوق: الرسم كدالّةٍ نقيّة تُستدعى من جديد بلا توقّع (١)، والإغلاقات كآلية حبس القيم لحظة الاستدعاء (٢). النطاق: متى ينفّذ React كوداً "بعد" استقرار الرسم على الشاشة، وكيف يتعامل مع مغادرة الممثل قبل انتهاء مهمّةٍ معلّقة. يفتح: الفعل مقابل التزامن (٤).

اللغز المستفزّ

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<UserData | null>(null);

  fetch(`/api/users/${userId}`)                    // مباشرة في جسم الدالّة
    .then((res) => res.json())
    .then((data: UserData) => setUser(data));

  return <div>{user ? user.name : "...جارٍ التحميل"}</div>;
}

ليش: الرسم يجب أن يبقى نقياً — الأثر الجانبي يحتاج بابه الخاص

جسم دالّة المكوّن يُستدعى بلا أي ضمانةٍ عن عدد المرّات أو التوقيت — React حرٌّ في استدعائه مرّةً، أو مرّتين (سترى لماذا بعد قليل)، أو تجاهل نتيجته إن قاطعه عملٌ أهم. لهذا يجب أن يبقى نقياً: يصف الواجهة فقط، لا يفعل أشياء في العالم الخارجي (شبكة، مؤقّتات، اشتراكات، document.title، localStorage). أي كودٍ كهذا يحتاج باباً منفصلاً، ينفّذه React بعد أن يستقرّ الرسم فعلياً على الشاشة، بضبطٍ صريح لمتى:

useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then((res) => res.json())
    .then((data: UserData) => setUser(data));
}, [userId]);                                       // ← "متى" بالضبط

useEffect يأخذ دالّةً (الأثر نفسه) ومصفوفة تبعيات. الفكرة المركزية:

الأثر لا يُزامَن مع "الرسم"، يُزامَن مع مصفوفة التبعيات. بعد كل رسمٍ، React يقارن قيم مصفوفة التبعيات بقيمها في الرسم السابق — نفس فكرة المقارنة (===) على كل عنصر، تماماً كمقارنة الإقليم ٠ لعقدتين، لكن هنا على قيمٍ لا عقد DOM. لو كلها متطابقة، الأثر لا يُعاد تنفيذه إطلاقاً. لو أيّ عنصرٍ اختلف، يُعاد تنفيذه كاملاً.

[] (مصفوفة فارغة) تعني "لا تبعيات أبداً تتغيّر" → الأثر يُنفَّذ مرّةً واحدة فقط، بعد أول رسم. [userId] تعني "أعد التنفيذ فقط إذا تغيّر userId تحديداً" — لا عند تغيّر أي حالةٍ أخرى في المكوّن. بلا مصفوفة إطلاقاً (لا تكتبها أصلاً) تعني "بعد كل رسمٍ بلا استثناء" — نادراً ما تريد هذا.

كيف: دورة الحياة الفعلية

مصفوفة التبعيات ليست تحسين أداء اختيارياً — هي عقد صحّة. لو أثرٌ يقرأ userId داخل جسمه ولم تذكره في التبعيات، الأثر سيستمر يستخدم القيمة المحبوسة في إغلاق الرسم الذي كُتب فيه (تماماً كمشكلة count المحبوس في TripleClick بالإقليم ٢) — أي سيبقى يجلب بيانات المستخدم الأول حتى لو تغيّر userId عشر مرّات بعده، لأن الإغلاق لا يعرف بالتغيير. هذا يُسمّى إغلاقٌ عالقٌ (stale closure)، وهو نفس آلية الإقليم ٢ بالضبط، في ثوبٍ جديد.

اللغز/البناء من الصفر — الجزء الأول

ليش وكيف: التنظيف (cleanup) — طاقمٌ يرتّب المسرح قبل المشهد التالي

كل مرّة يُعاد فيها تنفيذ أثرٍ (تبعياته تغيّرت)، أو يغادر الممثل المسرح نهائياً (unmount)، React ينفّذ أولاً دالّة التنظيف التي يُعيدها الأثر — إن أعاد شيئاً:

useEffect(() => {
  const id = setInterval(() => console.log(query), 3000);
  return () => clearInterval(id);          // التنظيف: أوقف المؤقّت القديم
}, [query]);

لماذا هذا إلزامي، لا اختياري: بدون التنظيف، كل مرّة يتغيّر فيها query تُنشئ مؤقّتاً جديداً فوق المؤقّتات القديمة التي لا تزال تعمل — بعد ١٠ تعديلات على حقل البحث، عندك ١٠ مؤقّتات تطبع كل ٣ ثوانٍ، لا واحد. هذا نفس شذوذ "نسخٍ متراكمة لم تُنظَّف" الذي رأيته في الإقليم ٠، لكن في الزمن لا في DOM.

متى تُنفَّذ دالّة التنظيف بالضبط؟

رسمٌ ١ (تبعية = "a")

الأثر يعمل، ينشئ الاشتراك

رسمٌ ٢ (تبعية = "b")

*أولاً* نظّف اشتراك الرسم ١ → ثم شغّل الأثر بتبعية "b"

رسمٌ ٣ (تبعية = "b")

لا تغيير → لا تنظيف، لا تشغيل جديد

المكوّن يُزال من الشجرة → نظّف اشتراك الرسم ٣ (الأخير) نهائياً

كل "تشغيل" للأثر له تنظيفه الخاص المرتبط به، لا تنظيفٌ عامٌّ واحد.

ليش: سباق التسابق — حين يتأخّر الردّ عن موعده

الإغلاق العالق شيء؛ ترتيب الوصول شيءٌ آخر تماماً، وأخطر. تخيّل: userId يتغيّر بسرعة من "1" إلى "2". الأثر يعمل مرّتين: طلبٌ لـ"1"، ثم طلبٌ لـ"2". الشبكة لا تضمن ترتيب الوصول بنفس ترتيب الإرسال — ماذا لو ردّ "1" (البطيء) وصل بعد ردّ "2" (السريع)؟

الشاشة تعرض بيانات خاطئة رغم أن كل سطر كودٍ "صحيح" منطقياً — هذا سباق تسابق (race condition): نتيجةٌ تعتمد على ترتيب وصولٍ غير مضمون.

اللغز/البناء من الصفر — الجزء الثاني: افتعِل السباق وأصلحه

function fakeFetchUser(id: string): Promise<UserData> {
  const delay = id === "1" ? 400 : 50;    // "1" دائماً أبطأ من "2"
  return new Promise((resolve) =>
    setTimeout(() => resolve({ id, name: `مستخدم ${id}` }), delay),
  );
}

useEffect(() => {
  let ignore = false;                              // خاصٌّ بهذا التشغيل فقط

  fakeFetchUser(userId).then((data) => {
    if (!ignore) setUser(data);                     // تجاهل لو صرت قديماً
  });

  return () => { ignore = true; };                  // التنظيف: أبطل هذا التشغيل
}, [userId]);

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((res) => res.json())
    .then(setUser)
    .catch((err) => {
      if (err.name !== "AbortError") throw err;      // تجاهل الإلغاء المتعمَّد فقط
    });

  return () => controller.abort();                    // ألغِ الطلب فعلياً، لا تتجاهله فقط
}, [userId]);

ليش: StrictMode يشغّل كل شيء مرّتين — عمداً

لو رأيت مكوّناتك تُرسَم مرّتين، أو أثراً يعمل ثم يُنظَّف ثم يعمل مجدداً، فوراً بلا أي تفاعل مستخدم — هذا على الأرجح <React.StrictMode> (كما في main.tsx لمشروعكم). في وضع التطوير فقط، React عمداً: يرسم مرّتين، وينفّذ كل أثرٍ بترتيب: تشغيل → تنظيف → تشغيل فوراً عند أول ظهور.

لماذا يفعل هذا بالله؟ لأنه اختبارٌ مجّانيّ لسؤالٍ حرج: *لو نُفِّذ الرسم أو الأثر مرّتين، هل يبقى السلوك النهائي المرئي للمستخدم مطابقاً لما لو نُفِّذ مرّة واحدة؟* رسمٌ نقيّ حقاً لا يتأثّر بإعادة الاستدعاء (لا يفعل شيئاً في العالم الخارجي). وأثرٌ منظَّف بشكل صحيح تماماً — تنظيفه يُبطل كل ما فعله تماماً — يجب أن يكون تشغيله-تنظيفه-تشغيله مرّةً واحدة غير مرئي للمستخدم، مطابقاً تماماً لتشغيلٍ واحد فقط. لو رأيت أثراً جانبياً مضاعفاً حقيقياً (طلبٌ مزدوجٌ ظاهر، اشتراكٌ مضاعَف)، فهذا ليس "علّة React" — هذا React يخبرك بدقّة: تنظيفك ناقص.

اللغز/البناء من الصفر — الجزء الثالث: استغلّ StrictMode كأداة تشخيص

useEffect(() => {
  emitter.addEventListener("tick", handleTick);
  // ⚠️ لا يوجد return هنا — لا تنظيف
}, []);

الخلاصة — أين تتّصل هذه العقدة بالشجرة

الوصلة بمشروعك