رفع الـ state للأعلى

لديك الآن نموذج لإضافة الأفلام، وقائمة أفلام، وأزرار فلترة. كل منها يعمل وحده. ضعها على شاشة واحدة ولن يتحدّث بعضها مع بعض: لا يستطيع النموذج الإضافة إلى قائمة تعيش في component آخر، ولا تعرف القائمة أي زر فلترة مضغوط. لا تستطيع الـ components أن تمدّ يدها إلى الـ state الخاص ببعضها. هذا مقصود، والحلّ نمط ستستخدمه في كل تطبيق React تبنيه.

المشكلة: الإخوة لا يتشاركون

هذا شريط الفلترة كما قد تكتبه أول مرة:

function FilterBar() {
  const [filter, setFilter] = useState('all');
  return (
    <div>
      <button aria-pressed={filter === 'all'} onClick={() => setFilter('all')}>All</button>
      <button aria-pressed={filter === 'to-watch'} onClick={() => setFilter('to-watch')}>To watch</button>
      <button aria-pressed={filter === 'watched'} onClick={() => setFilter('watched')}>Watched</button>
    </div>
  );
}

يظهر الزر النشط مميّزًا بشكل صحيح، لكن MovieList أخ له. لا يصل إلى filter، فيعرض كل شيء مهما نقرت. الـ state خاص بالـ component الذي يعلن عنه.

الحلّ: ارفعه إلى الأب المشترك

اعثر على أقرب component يكون أبًا لكل ما يحتاج إلى الـ state. بالنسبة إلى الفلتر، هو App، أب كلٍّ من FilterBar وMovieList. انقل الـ state إليه، ثم:

1. مرّر القيمة إلى كل من يقرؤها، و
2. مرّر دالة إلى كل من يغيّرها.

export default function App() {
  const [movies, setMovies] = useState(INITIAL_MOVIES);
  const [filter, setFilter] = useState('all');

  const visible = movies.filter((m) =>
    filter === 'all' ? true : filter === 'watched' ? m.watched : !m.watched,
  );

  function handleAdd(title) {
    setMovies([...movies, { id: crypto.randomUUID(), title, watched: false }]);
  }

  return (
    <main>
      <Header movies={movies} />
      <AddMovieForm onAdd={handleAdd} />
      <FilterBar value={filter} onChange={setFilter} />
      <MovieList movies={visible} />
    </main>
  );
}

function FilterBar({ value, onChange }) {
  return (
    <div role="group" aria-label="Filter movies">
      <button aria-pressed={value === 'all'} onClick={() => onChange('all')}>All</button>
      <button aria-pressed={value === 'to-watch'} onClick={() => onChange('to-watch')}>To watch</button>
      <button aria-pressed={value === 'watched'} onClick={() => onChange('watched')}>Watched</button>
    </div>
  );
}

لم يعد لدى FilterBar أي state. إنه يعرض value ويبلّغ عن النقرات عبر onChange. ويُسمّى component كهذا controlled (متحكَّمًا به): أبوه يقرّر ما يعرضه. وصار الآن أسهل في الاختبار وإعادة الاستخدام، لأن كل ما يفعله ظاهر في الـ props الخاصة به.

البيانات تنزل، والأحداث تصعد

لاحظ الشكل. البيانات تتدفّق نزولًا في الشجرة كـ props: movies وfilter وvisible. والتغييرات تتدفّق صعودًا كاستدعاءات دوال: النموذج يستدعي onAdd، وشريط الفلترة يستدعي onChange. ولا يستدعي setMovies أو setFilter إلا App.

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

وانظر أيضًا إلى ما ليس state. تُحسب visible من movies وfilter في كل render، ويشتقّ Header العدد من movies. رفع الـ state لا يعني رفع كل شيء؛ بل يعني مالكًا واحدًا لكل قطعة state حقيقية، وكل ما عداها مشتقّ منها.

علامات أنك تحتاج إلى الرفع

نادرًا ما تخطّط لكل قطعة state بشكل مثالي من البداية. تكتشف الحاجة إلى الرفع أثناء البناء، والعلامات ثابتة:

• componentان يعرضان قيمتين يجب أن تتطابقا لكنهما لا تتطابقان أحيانًا.
• أنت على وشك كتابة effect وظيفته الوحيدة نسخ state component إلى آخر.
• ابنٌ يحتاج إلى تغيير شيء يعرضه أخوه.

كل واحدة من هذه تعني أن للبيانات نفسها مالكين، أو أن المالك منخفض جدًا في الشجرة. والرفع إعادة هيكلة صغيرة وآلية: اقطع سطر useState، والصقه في الأب، واستبدل الـ state القديم في الابن بـ props.

في أدنى مكان ممكن، وأعلى مكان ضروري

للرفع ثمن: المالك يعيد الـ render حين يتغيّر الـ state، ومعه أبناؤه، والـ props تضطر إلى قطع مسافة أطول. فلا ترفع كل شيء إلى App بحكم العادة.

النص الذي يُكتب في حقل العنوان مثال جيد. لا يهتمّ به إلا AddMovieForm أثناء الكتابة. أمّا App فلا يحتاج إلا إلى العنوان النهائي، الذي يصله من onAdd. لذا تبقى المسوّدة في النموذج. وإذا احتاج component آخر لاحقًا إلى معاينة المسوّدة، فسترفعها حينها.

وحين يحتاج إلى الـ state components متباعدة في الشجرة، يصبح تمريره عبر كل مستوى مملًّا. رأيت حلًّا في درس التركيب (تمرير العناصر إلى الأسفل)، والـ context في React هو الحل الآخر. أمّا Watchlist فتكفيه بضعة props.

صار لـ Watchlist مصدر واحد للحقيقة وثلاثة components تقرؤه وتغيّره. في الدرس التالي تزامن هذا الـ state مع شيء خارج React، أي عنوان تبويب المتصفّح وlocalStorage، باستخدام الـ effects.