أربعة أجزاء من Trailhead تهتم الآن بالبيانات نفسها. tab السجلّ يعرض الرحلات، وtab الإحصاءات يجمعها، وشاشة التفاصيل تعرض واحدة منها، ونموذج إضافة رحلة (في الدرس التالي) ينشئها. إن حمّلت كل شاشة نسختها الخاصة واحتفظت بها، فستتباعد النسخ: تحذف رحلة في شاشة التفاصيل، وتعود، فتجد tab الإحصاءات ما زال يحسبها، لأن شاشات الـ stack والـ tabs التي زرتها تبقى مركّبة ولا تُعيد التحميل.
\nالحل هو مبدأ React الذي تعرفه أصلًا، مطبّقًا على شجرة تنقّل: مصدر واحد للحقيقة، محفوظ فوق كل ما يحتاج إليه.
\nفي تطبيق ويب كنت ستضع الـ provider قرب الـ component الجذري. في Expo Router، الـ component الجذري هو src/app/_layout.tsx: فهو يرسم الـ Stack، الذي يرسم مجموعة الـ tabs وكل شاشة تُضاف. والـ provider الموضوع حول ذلك الـ Stack يغطّي التطبيق كله.
الرحلات تُضاف وتُعدَّل وتُحذف وتُفضَّل. بدلًا من بعثرة استدعاءات setHikes في الشاشات، صِف كل تغيير بوصفه action وعالجها كلها في دالة نقية واحدة:
export type Hike = { id: string; name: string; date: string; distanceKm: number; favorite: boolean };\n\nexport type HikesAction =\n | { type: 'added'; hike: Hike }\n | { type: 'updated'; id: string; changes: Partial<Omit<Hike, 'id'>> }\n | { type: 'deleted'; id: string }\n | { type: 'favoriteToggled'; id: string };\n\nexport function hikesReducer(state: Hike[], action: HikesAction): Hike[] {\n switch (action.type) {\n case 'added':\n return [action.hike, ...state];\n case 'updated':\n return state.map((h) => (h.id === action.id ? { ...h, ...action.changes } : h));\n case 'deleted':\n return state.filter((h) => h.id !== action.id);\n case 'favoriteToggled':\n return state.map((h) => (h.id === action.id ? { ...h, favorite: !h.favorite } : h));\n }\n}كل حالة تُرجع مصفوفة جديدة، وكائنًا جديدًا للرحلة التي تغيّرت. هكذا تعرف React أن شيئًا تغيّر، وهذا ما يسمح لـ HikeRow المغلّف بـ memo بتخطّي إعادة الـ render للصفوف الـ 599 التي لم تتغيّر.
لاحظ أسماء الـ actions: added وdeleted وfavoriteToggled. إنها تصف ما حدث، لا كيفية تحديث الـ state. وهذا يُبقي الشاشات بسيطة (شاشة التفاصيل تُبلغ أن المستخدم بدّل حالة التفضيل، ولا يهمّها كيف تُخزَّن القائمة)، ويعطيك مكانًا واحدًا تغيّره حين تتغيّر القواعد، كأن يصبح حذف رحلة يعني حذف صورها أيضًا.
ولأن الـ reducer لا يستورد شيئًا من React Native، فهو يعمل في أي مكان. ستختبر reducers كهذا باستخدام Jest العادي في القسم 5، وستكتب واحدًا في تمرين هذا الدرس.
\nimport { createContext, use, useMemo, useReducer, type Dispatch, type ReactNode } from 'react';\nimport { hikesReducer, type Hike, type HikesAction } from './hikesReducer';\n\nconst HikesContext = createContext<Hike[] | null>(null);\nconst DispatchContext = createContext<Dispatch<HikesAction> | null>(null);\n\nexport function HikesProvider({ initial, children }: { initial: Hike[]; children: ReactNode }) {\n const [hikes, dispatch] = useReducer(hikesReducer, initial);\n return (\n <DispatchContext value={dispatch}>\n <HikesContext value={hikes}>{children}</HikesContext>\n </DispatchContext>\n );\n}\n\nexport function useHikes() {\n const hikes = use(HikesContext);\n if (!hikes) throw new Error('useHikes must be used inside HikesProvider');\n return hikes;\n}\n\nexport function useHike(id: string | undefined) {\n const hikes = useHikes();\n return useMemo(() => hikes.find((h) => h.id === id), [hikes, id]);\n}\n\nexport function useHikesDispatch() {\n const dispatch = use(DispatchContext);\n if (!dispatch) throw new Error('useHikesDispatch must be used inside HikesProvider');\n return dispatch;\n}ثم غلّف الـ Stack في الـ root layout: <HikesProvider initial={sampleHikes}><Stack>…</Stack></HikesProvider>. وفي القسم 4 ستأتي البيانات الأولية من قاعدة بيانات الجهاز بدلًا من ذلك.
بعض التفاصيل تستحق النسخ. تسمح لك React 19 برسم الـ context مباشرة بوصفه provider (<HikesContext value={…}>) وقراءته باستخدام use. وفصل الـ state والـ dispatch في اثنين من الـ contexts منفصلَين يعني أن الـ components التي ترسل actions فقط، مثل زرّ حذف، لا يُعاد لها الـ render حين تتغيّر القائمة. والـ hooks ترمي خطأً واضحًا إن نسي أحدٌ الـ provider، بدلًا من الفشل لاحقًا برسالة “cannot read properties of null”.
وهكذا تُقرأ الشاشة الآن:
\nconst hike = useHike(id);\nconst dispatch = useHikesDispatch();\n// …\n<Pressable onPress={() => dispatch({ type: 'favoriteToggled', id: hike.id })}>يحتاج tab الإحصاءات إلى المسافة الإجمالية، وعدد الرحلات، وأطول رحلة. لا شيء من ذلك state. إنها قيم مشتقّة من قائمة الرحلات، فاحسبها:
\nconst hikes = useHikes();\nconst stats = useMemo(() => {\n const totalKm = hikes.reduce((sum, h) => sum + h.distanceKm, 0);\n const longest = hikes.reduce((best, h) => (!best || h.distanceKm > best.distanceKm ? h : best), undefined as Hike | undefined);\n return { count: hikes.length, totalKm, longest };\n}, [hikes]);يعيد الـ context الـ render لكل مستهلك حين تتغيّر قيمته. لقائمة الرحلات في Trailhead هذا جيد. لكنه يصبح مشكلة حين تتغيّر قيمة ما كثيرًا جدًا (موقع GPS حيّ يتحدّث كل ثانية)، أو حين يكون في تطبيق كبير مستهلكون كثيرون لا علاقة بينهم. عندها تلجأ الفرق إلى Zustand، وهي store صغيرة مع selectors بحيث لا يُعاد الـ render للـ components إلا بسبب الشريحة التي تقرؤها. أما البيانات التي تعيش على خادم فلها مشكلات مختلفة تمامًا (التخزين المؤقت، وإعادة الجلب، وتقادم البيانات)، وهذه وظيفة TanStack Query؛ ستلتقي بها في القسم 4. ابدأ بالـ reducer مع الـ context، وانتقل حين تقيس سببًا لذلك.
\nالتالي: الشاشة التي تنشئ الرحلات، أي نموذج يعمل مع لوحة مفاتيح الهاتف.
\n","toc":[{"id":"sec-1","text":"أين تعيش الـ state المشتركة في Expo Router","level":2},{"id":"sec-2","text":"reducer لكل تغيير","level":2},{"id":"sec-3","text":"الـ provider والـ hooks الخاصة به","level":2},{"id":"sec-4","text":"اشتقّ ولا تكرّر","level":2},{"id":"sec-5","text":"حين لا يكفي الـ context","level":2}],"takeaways":["الـ state التي تستخدمها عدّة مسارات مكانها فوقها جميعًا، وهذا في Expo Router يعني provider داخل_layout.tsx الجذري.","يجمع الـ reducer كل تغيير على قائمة الرحلات في دالة نقية واحدة قابلة للاختبار تُرجع مصفوفات وكائنات جديدة.","غلّف الـ context بـ hooks صغيرة مثل useHikes() وuseHike(id)، حتى لا تلمس الشاشات كائن الـ context مباشرة أبدًا.","اشتقّ المجاميع والقوائم المصفّاة من الـ state المصدر باستخدام useMemo؛ ولا تخزّنها منفصلة.","استخدم مكتبة مثل Zustand حين تصبح عمليات re-render الناتجة عن الـ context مشكلة مقيسة، وTanStack Query حين تعيش البيانات على خادم."],"further":[{"title":"Scaling Up with Reducer and Context","url":"https://react.dev/learn/scaling-up-with-reducer-and-context"},{"title":"Choosing the State Structure","url":"https://react.dev/learn/choosing-the-state-structure"},{"title":"useReducer","url":"https://react.dev/reference/react/useReducer"}],"quiz":[{"q":"يخزّن tab الإحصاءات totalKm في useState خاصة به، تُحدَّث داخل effect. بعد أن يحذف المستخدم رحلة، يبقى المجموع خاطئًا حتى يُعاد تشغيل التطبيق. ما أفضل إصلاح؟
totalKm إلى الـ reducer وحدّثه مع كل action.","why":"الآن يجب على كل action أن يتذكّر إبقاء المجموع متزامنًا، ومن هنا يأتي هذا النوع من الأخطاء بالضبط."},{"text":"أعِد تركيب tab الإحصاءات كلما حصل على التركيز.","why":"رمي الـ state الخاصة بالشاشة للتعافي من خطأ تزامن يكلّف أكثر من الخطأ نفسه."},{"text":"احذف الـ state واحسب المجموع من الرحلات المشتركة باستخدام useMemo.","why":"صحيح. القيم المشتقّة المحسوبة من مصدر واحد للحقيقة لا يمكن أن تخرج عن التزامن."}],"answer":3},{"q":"ما المشكلة في حالة الـ reducer هذه؟
\ncase 'favoriteToggled': {\n const hike = state.find((h) => h.id === action.id);\n hike.favorite = !hike.favorite;\n return state;\n}state.map مثلًا."},{"text":"لا يمكن أن تحتوي الـ reducers على تعريفات const محصورة في كتلة.","why":"التعريفات المحصورة في كتلة داخل case بين أقواس معقوفة لا بأس بها."},{"text":"find أبطأ من أن يُستخدم في reducer؛ يحتاج إلى بحث عبر فهرس.","why":"مع مئات الرحلات يكون find فوريًا. الخطأ في التعديل المباشر (mutation)، لا في السرعة."}],"answer":0},{"q":"أين يجب أن يُرسم HikesProvider الخاص بـ Trailhead لكي يقرأه tab السجلّ وtab الإحصاءات وشاشة /hikes/[id] جميعًا؟
(tabs)/index.tsx، لأن السجلّ هو مالك الرحلات.","why":"الإخوة وشاشة التفاصيل خارج ذلك الـ component، فلا يستطيعون قراءة الـ context الخاص به."},{"text":"في src/app/_layout.tsx، حول الـ Stack الجذري.","why":"صحيح. كل ما يرسمه الـ root layout، الـ tabs وشاشات الـ stack على السواء، يقع داخل الـ provider."},{"text":"في كل شاشة تحتاج إليه، ولكلٍّ منها نسختها الخاصة.","why":"الـ providers المنفصلة تعني state منفصلة؛ فالتعديل في شاشة لن يظهر في الأخرى."}],"answer":1}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// Trailhead keeps hikes sorted newest first (dates are 'YYYY-MM-DD').\nfunction hikesReducer(state, action) {\n switch (action.type) {\n case 'added':\n state.push(action.hike);\n return state;\n case 'updated': {\n const hike = state.find((h) => h.id === action.id);\n Object.assign(hike, action.changes);\n return state;\n }\n case 'deleted':\n return state.filter((h) => h.id !== action.id);\n case 'favoriteToggled': {\n const hike = state.find((h) => h.id === action.id);\n hike.favorite = !hike.favorite;\n return state;\n }\n default:\n throw new Error('Unknown action ' + action.type);\n }\n}\n\nconst start = [\n { id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false },\n { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true },\n];\nconsole.log(hikesReducer(start, { type: 'added', hike: { id: 'c', name: 'Fern Gully', date: '2026-10-10', distanceKm: 3.6, favorite: false } }).map((h) => h.id));\n"},"solution":{"js":"const byNewest = (a, b) => b.date.localeCompare(a.date);\n\nfunction hikesReducer(state, action) {\n switch (action.type) {\n case 'added':\n if (state.some((h) => h.id === action.hike.id)) return state;\n return [...state, action.hike].sort(byNewest);\n case 'updated': {\n if (!state.some((h) => h.id === action.id)) return state;\n return state\n .map((h) => (h.id === action.id ? { ...h, ...action.changes, id: h.id } : h))\n .sort(byNewest);\n }\n case 'deleted':\n return state.filter((h) => h.id !== action.id);\n case 'favoriteToggled':\n return state.map((h) => (h.id === action.id ? { ...h, favorite: !h.favorite } : h));\n default:\n return state;\n }\n}\n\nconst start = [\n { id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false },\n { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true },\n];\nconsole.log(hikesReducer(start, { type: 'added', hike: { id: 'c', name: 'Fern Gully', date: '2026-10-10', distanceKm: 3.6, favorite: false } }).map((h) => h.id));\n"},"checks":[{"id":"add-sorted","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'added', hike: { id: 'c', name: 'Fern', date: '2026-10-10', distanceKm: 3.6, favorite: false } }); return n !== s && n.map((h) => h.id).join() === 'a,c,b' && s.length === 2;"},{"id":"add-duplicate","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'added', hike: { id: 'a', name: 'Copy', date: '2026-01-01', distanceKm: 1, favorite: false } }); return n === s;"},{"id":"update","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'updated', id: 'b', changes: { name: 'Ridge Loop East', date: '2026-10-25', id: 'zzz' } }); return n !== s && n[0].id === 'b' && n[0].name === 'Ridge Loop East' && s[1].name === 'Ridge Loop' && n.length === 2;"},{"id":"toggle","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'favoriteToggled', id: 'a' }); return n !== s && n[0].favorite === true && s[0].favorite === false && n[1] === s[1];"},{"id":"delete","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'deleted', id: 'a' }); return n.length === 1 && n[0].id === 'b' && s.length === 2;"},{"id":"unknown","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); let n; try { n = hikesReducer(s, { type: 'somethingElse' }); } catch { return false; } return n === s;"}],"title":"اجعل reducer الرحلات غير قابل للتعديل المباشر","prompt":"يعدّل hikesReducer في Trailhead الـ state مباشرة، فلا تتحدّث الشاشات. أعد كتابته بحيث تُرجع كل حالة مصفوفات وكائنات جديدة ولا تغيّر state أبدًا. أبقِ القائمة مرتّبة من الأحدث أولًا بحسب date (نصوص بصيغة YYYY-MM-DD).
added: أدرج action.hike بترتيب التاريخ. إن كانت رحلة بذلك الـ id موجودة أصلًا، فأرجع state نفسها.updated: ادمج action.changes في الرحلة ذات action.id، وأعد الترتيب، ولا تسمح أبدًا لـ changes بالكتابة فوق الـ id.deleted: احذف الرحلة.favoriteToggled: اقلب قيمة favorite؛ والرحلات التي لم تتغيّر تحتفظ بالكائن نفسه، لكي تتخطّى الصفوف المغلّفة بـ memo إعادة الـ render.state نفسها (لا ترمِ خطأ).const byNewest = (a, b) => b.date.localeCompare(a.date);. و[...state, hike].sort(byNewest) يرتّب نسخة.","state.map((h) => (h.id === action.id ? { ...h, ...changes } : h)) ينسخ الرحلة التي تغيّرت فقط. ضع id: h.id بعد الـ spread لتكون لها الغلبة.","إرجاع state نفسها (المرجع نفسه) هو الطريقة التي يخبر بها الـ reducer React أن شيئًا لم يتغيّر."],"explanation":"تقرّر React إعادة الـ render بمقارنة المراجع، لذا فإن reducer يعدّل مباشرة ويُرجع المصفوفة نفسها يُخفي كل تغيير. تبني النسخة المُصلحة مصفوفات جديدة باستخدام الـ spread وmap وfilter وترتيب على نسخة، وتنشئ كائنًا جديدًا فقط للرحلة التي تغيّرت، وتُرجع state الأصلية حين لا يجب أن يتغيّر شيء (إضافة مكرّرة أو action غير معروف). الرحلات التي لم تتغيّر تحتفظ بهويّتها، وهذا بالضبط ما يتيح لـ memo(HikeRow) تخطّيها.