React 19 في 2026: المصرّف والإجراءات وما الذي تغيّر

أهم ما يجري في React الآن ليس خطافًا جديدًا، بل أن مصرّف React وصل إلى الإصدار المستقر 1.0، ما يعني أن أعمال التذكير التي كنت تكتبها يدويًا منذ سنوات صارت في معظمها بلا داعٍ.

ويغطي هذا الدليل ما يغيّره ذلك فعلًا، إضافة إلى الإجراءات وإضافات React 19.2. الإصدارات وقت الكتابة: React 19.2 مع مصرّف React 1.0.

المصرّف وما الذي يلغيه

تعيد React عرض المكوّن حين تتغير حالته أو خصائصه، وتعيد تنفيذ كل ما بداخله. وكان الحل التقليدي هو التغليف اليدوي:

// الطريقة القديمة — وهي كثيرة في معظم قواعد الشيفرة
const visibleItems = useMemo(
  () => items.filter(i => i.status === filter),
  [items, filter]
)

const handleSelect = useCallback(
  (id) => setSelected(id),
  []
)

ويفعل المصرّف ذلك تلقائيًا وقت البناء، بتحليل ما يعتمد فعليًا على ماذا:

// مع تفعيل المصرّف — الأداء نفسه بلا مراسم
const visibleItems = items.filter(i => i.status === filter)

function handleSelect(id) {
  setSelected(id)
}

كما يفعل شيئًا لا تستطيعه يدويًا: التذكير الشرطي، وبدقة أعلى من القيم الكاملة. فالخطافات لا يمكن استدعاؤها شرطيًا، ولهذا يكون التذكير اليدوي دائمًا أخشن من الأمثل.

تفعيله

npm i -D babel-plugin-react-compiler eslint-plugin-react-hooks

// vite.config.ts
export default defineConfig({
  plugins: [
    react({
      babel: { plugins: [['babel-plugin-react-compiler', {}]] },
    }),
  ],
})

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

هل تحذف استدعاءات useMemo الحالية؟

ليس على عجل، ولا دفعة واحدة.

فاستدعاءات useMemo وuseCallback القائمة تبقى تعمل، ولا يتعارض معها المصرّف، فلا ترحيل إجباري.

والأسلوب العملي: توقّف عن كتابة جديدة، واحذف القديمة حين تكون تعدّل ذلك الملف أصلًا. أما حذف جماعي عبر قاعدة الشيفرة فهو فرق كبير بمخاطرة انحدار حقيقية وبلا فائدة يراها المستخدم، وتلك مقايضة سيئة.

الإجراءات

import { useActionState } from 'react'

function UpdateProfile({ user }) {
  const [state, formAction, isPending] = useActionState(
    async (previousState, formData) => {
      try {
        await saveProfile({ name: formData.get('name') })
        return { ok: true, error: null }
      } catch (e) {
        return { ok: false, error: e.message }
      }
    },
    { ok: false, error: null }
  )

  return (
    <form action={formAction}>
      <input name="name" defaultValue={user.name} />
      <button disabled={isPending}>
        {isPending ? 'Saving…' : 'Save'}
      </button>
      {state.error && <p role="alert">{state.error}</p>}
    </form>
  )
}

فتحصل على isPending مجانًا، ولأن هذا action نموذج حقيقي، يعمل الإرسال قبل اكتمال الترطيب.

التحديثات التفاؤلية

const [optimistic, addOptimistic] = useOptimistic(
  comments,
  (state, newComment) => [...state, { ...newComment, pending: true }]
)

async function action(formData) {
  const text = formData.get('text')
  addOptimistic({ id: 'temp', text })   // يظهر فورًا
  await addComment(text)                 // يتراجع تلقائيًا عند الفشل
}

والتراجع التلقائي هو الجزء الثمين، فالتحديثات التفاؤلية المكتوبة يدويًا تصيب المسار السعيد عادةً وتخطئ في التراجع.

ما الذي أضافه React 19.2

function ChatRoom({ roomId, theme }) {
  // يقرأ السمة الحالية دون أن يعتمد التأثير عليها
  const onConnected = useEffectEvent(() => {
    showNotification('Connected', theme)
  })

  useEffect(() => {
    const conn = createConnection(roomId)
    conn.on('connected', onConnected)
    conn.connect()
    return () => conn.disconnect()
  }, [roomId])   // السمة ليست هنا — ولا تحتاج أن تكون
}

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

ما لا يستطيع المصرّف إصلاحه

• عرض أكثر مما ينبغي دفعة واحدة. فعشرة آلاف صف بطيئة سواء ذُكِّرت أم لا. استخدم العرض الافتراضي للقوائم.
• حساب مكلف فعلًا. فالمصرّف يتجنّب تكرار العمل ولا يجعل العمل أرخص.
• شلالات الشبكة. فالطلبات المتسلسلة مشكلة معمارية لا مشكلة عرض.
• حزم ضخمة. فلا شيء في التذكير يقلّل ما تشحنه.
• مكوّنات تخالف قواعد React. فهذه تُتخطى كليًا، ولهذا تحديدًا تشغّل أداة الفحص.

ترتيب معقول

1. أضف إضافة ESLint وأصلح ما تبلّغ عنه. مفيدة بذاتها.
2. فعّل المصرّف وتحقّق في أدوات React أن المكوّنات تظهر محسَّنة.
3. توقّف عن كتابة useMemo وuseCallback جديدة.
4. تبنَّ الإجراءات للنماذج كلما لمستها.
5. احذف التذكير القديم انتهازيًا لا كمسح شامل.

أسئلة شائعة

هل مصرّف React جاهز للإنتاج؟

نعم. فقد وصل إلى الإصدار المستقر 1.0 في أكتوبر 2025 بعد تجربة بيتا مطوّلة واستخدام مكثّف في الإنتاج لدى Meta، ويعمل مع React 19 و React Native.

هل ما زلت أحتاج useMemo و useCallback في React 19؟

نادرًا بعد تفعيل المصرّف، فهو يذكّر تلقائيًا وبدقة أعلى مما تتيحه الخطافات لأنه يستطيع التذكير الشرطي. وأبقِ useMemo فقط لحساب مكلف فعلًا تريد تخزينه لذاته.

هل أحذف كل استدعاءات useMemo الحالية؟

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

لماذا يتخطى المصرّف بعض مكوّناتي؟

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

ما هو useActionState؟

خطاف يغلّف معالج نموذج غير متزامن ويعطيك النتيجة وإجراء النموذج وراية الانتظار في استدعاء واحد، بدل العنقود المعتاد من حالات التحميل والخطأ. ولأنه يرتبط بإجراء نموذج حقيقي فهو يعمل قبل الترطيب أيضًا.

ما الغرض من useEffectEvent؟

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

ما مكوّن Activity؟

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

هل يجعل المصرّف تطبيقي أسرع تلقائيًا؟

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