الإقليم ٠٢ — دفتر الممثل

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

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

function Counter(): VNode {
  let count = 0;
  return h("button", { onClick: () => { count++; console.log(count); } },
    String(count),
  );
}

function Counter(): VNode {
  let count = 0;                                        // ⚠️
  return h("button", { onClick: () => { count++; rerender(); } },
    String(count),
  );
}

ليش: الذاكرة تعيش خارج الدالّة، في سجلٍّ يخصّ كل نسخة

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

useState هو ذلك المقبض. لا يُنشئ الذاكرة داخل الدالّة — يقرأ ويكتب في خانةٍ مخصّصة له داخل fiber النسخة الحالية.

كيف: ابنِ useState بيدك — عشرة أسطر تشرح كل شيء

لنبسّط أولاً بعالمٍ فيه نسخة مكوّنٍ واحدة نشطة (عدّاد وحيد، لا اثنان بعد). سجلّها الوحيد: مصفوفة ومؤشّر:

let hookStates: unknown[] = [];
let hookIndex = 0;

function useStateNano<T>(initial: T): [T, (next: T) => void] {
  const slot = hookIndex;                              // "خانتي" في هذا النداء تحديداً

  if (!(slot in hookStates)) {
    hookStates[slot] = initial;                          // أوّل مرّة فقط: ازرع القيمة الابتدائية
  }

  const setState = (next: T): void => {
    hookStates[slot] = next;                              // اكتب في نفس الخانة، أياً كانت
    scheduleRerender();                                   // اطلب استدعاءً جديداً للدالّة
  };

  hookIndex++;                                            // الخانة التالية لنداء useState التالي
  return [hookStates[slot] as T, setState];
}

والدالّة المسؤولة عن الرسم تُصفّر المؤشّر قبل كل استدعاء، لا بعده:

function renderRoot(): void {
  hookIndex = 0;                                          // ابدأ من أول خانة، كل مرة
  const tree = Counter();
  patch(rootDom, currentTree, tree, container);
  currentTree = tree;
}

جرّب الآن:

function Counter(): VNode {
  const [count, setCount] = useStateNano(0);
  return h("button", { onClick: () => setCount(count + 1) }, String(count));
}

يعمل! لماذا؟ تتبّع بيدك: النداء الأول لـuseStateNano(0) يقع في الخانة ٠، يزرع 0. تنقر: setCount(1) يكتب 1 في الخانة ٠ ويطلب رسماً جديداً. renderRoot يُصفّر hookIndex لصفر وينادي Counter() من جديد. useStateNano(0) يُنادى مجدداً — نفس الخانة ٠ بالضبط (لأن hookIndex بدأ من صفر مرّة أخرى) — يجدها موجودة مسبقاً (0 in hookStates)، فيتجاهل القيمة الابتدائية 0 المُمرَّرة، ويُرجع القيمة المخزَّنة: 1. هذا بالضبط لماذا الوسيط الذي تُعطيه لـuseState يُستخدَم مرّةً واحدة فقط (أول رسم) ويُتجاهَل في كل مرّة بعدها — والآن تعرف السبب الآلي الدقيق، لا مجرّد الحقيقة.

لماذا زوجٌ (Tuple) لا كائن؟

لاحظ أن useStateNano تُرجع [value, setter]، لا {value, setter}. زوجٌ موضعي يسمح لك تُسمّي كل طرفٍ كما تشاء عبر الهدم الموضعي (destructuring): const [email, setEmail] = ... ثم const [password, setPassword] = ... — لو كان كائناً، كنتَ ستُضطرّ لإعادة تسمية كل حقلٍ يدوياً في كل نداء (const {value: email, setValue: setEmail} = ...). قرارٌ تصميميٌّ صغير، لكنه يوفّر عليك سطراً في كل استدعاء — ولأنك تعرف الفرق بين هدم المصفوفات (بالموضع) وهدم الكائنات (بالاسم) مسبقاً من TypeScript، هذا يجب أن يكون بديهياً الآن.

اللغز/البناء من الصفر — الجزء الأول: عدّادان مستقلّان

type Fiber = {
  hookStates: unknown[];
  hookIndex: number;
  type: ComponentFn;
  props: Record<string, unknown>;
};

let currentFiber: Fiber | null = null;

function renderFiber(fiber: Fiber): Child {
  currentFiber = fiber;
  fiber.hookIndex = 0;                     // صفّر مؤشّر *هذا الـfiber تحديداً*
  const output = fiber.type(fiber.props);
  currentFiber = null;
  return output;
}

ليش: هنا تُشتقّ "قواعد الـhooks" — لا تُحفظ

الآن — وبدون أي حفظٍ إضافي — جاوب بنفسك: ماذا يحدث لو كتبتَ:

function Weird(): VNode {
  const [a, setA] = useStateNano(1);
  if (a > 5) {
    const [b, setB] = useStateNano(100);       // ⚠️ نداءٌ شرطي
  }
  const [c, setC] = useStateNano(3);
  // ...
}

في أول رسمٍ (a = 1)، الشرط كاذب: تُستدعى useStateNano مرّتين فقط — a في الخانة ٠، c في الخانة ١. لو صار a > 5 لاحقاً، الشرط يصير صادقاً: الآن تُستدعى ثلاث مرّات — a في الخانة ٠، b في الخانة ١ (الخانة التي كانت تخصّ c سابقاً!)، وc في الخانة ٢ (خانة جديدة، ستُهيَّأ من جديد بقيمتها الابتدائية، ناسيةً أي قيمة سابقة). c فقدت ذاكرتها بصمت، وb ورثت خانة c القديمة بقيمةٍ غريبة. لا استثناء يُرمى. فقط سلوكٌ خاطئ يبدو تصادفياً، صعب التصحيح جداً لأنه يظهر فقط تحت شروطٍ معينة.

هذا تحديداً لماذا القاعدة صارمة: *نادِ الـhooks دائماً بنفس العدد ونفس الترتيب، بلا شروطٍ ولا حلقات ولا نداءات متداخلة.* ليست القاعدة اصطلاحاً جمالياً يفرضه فريق React — هي نتيجة رياضية مباشرة لكون الذاكرة مربوطة بالموضع (index) لا بالاسم. أنت الآن لا تحفظ هذه القاعدة، أنت اشتققتها من تطبيقٍ بنيته بيدك، وتقدر تشرح بالضبط أي خانة تُصاب متى ولماذا في أي مثال يُعطى لك مستقبلاً.

القاعدة الثانية ("نادِ الـhooks فقط من مكوّنات React أو من hooks مخصّصة") لها نفس التفسير: useStateNano تفترض وجود currentFiber غير فارغ (نداءٌ جارٍ لدالّة مكوّن). نادِها من زرّ حدثٍ عادي أو دالّة مساعدة عشوائية خارج أي رسم، وcurrentFiber سيكون null — لا يوجد سجلٌّ لتكتب فيه أصلاً.

كيف: من نسختنا المصغّرة إلى useState الحقيقي

استورد الآن الحقيقي وقارن بصمت:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

نفس التوقيع بالضبط، نفس السلوك بالضبط. الفرق أن fiber الحقيقي في React ليس مصفوفة بسيطة — هو قائمةٌ مرتبطة (linked list) حقيقية من عقد hooks، وآلية الرسم أعقد بكثير (مجدولة، قابلة للمقاطعة والاستئناف، بأولويات). لكن الجوهر الذي بنيتَه بيدك صحيحٌ حرفياً: خانةٌ لكل نداء hook، بالترتيب، معاد تصفيرها موضعياً قبل كل رسم لنفس الـfiber.

أثرٌ جانبيٌّ مهم: التحديثات الدالّية (functional updates)

جرّب بنفسك، بـuseState الحقيقي هذه المرّة:

function TripleClick() {
  const [count, setCount] = useState(0);
  const handleClick = () => {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
  };
  return <button onClick={handleClick}>{count}</button>;
}

توقّع بنفسك قبل التشغيل: كم سيزيد العدّاد بعد نقرةٍ واحدة؟ ثم شغّلها. النتيجة ١ فقط، لا ٣. السبب: الرسم الذي بُني فيه handleClick أغلق (closure) على قيمة count كما كانت لحظة ذلك الرسم بالذات — الثلاث نداءات كلها ترى نفس count القديم، فكلها تكتب "القديم + 1" في نفس الخانة، والأخيرة فقط تفوز. الإصلاح: مرّر دالّة بدل قيمة، تستقبل "آخر قيمةٍ معلّقة فعلياً" لا القيمة المحبوسة في الإغلاق:

const handleClick = () => {
  setCount((c) => c + 1);
  setCount((c) => c + 1);
  setCount((c) => c + 1);      // كل نداء يبني على نتيجة الذي قبله فعلياً
};

الآن تزيد ٣. لاحظ: هذا ليس تفصيلاً عشوائياً — هو نتيجة مباشرة لكون count داخل handleClick إغلاقٌ على قيمة تلك اللحظة بالذات، لا مرجعاً حياً يتحدّث تلقائياً.

اللغز/البناء من الصفر — الجزء الثاني: تحقّق بيدك

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

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