لديك كل القطع: دوال مساعدة للمال، والتحقّق من المدخلات، والعرض، والأحداث، والنموذج، والتخزين، والوحدات، والأصناف. يجمعها هذا الدرس في Pocket المكتمل، والأهم أنه يُريك الشكل الذي يُمسك تطبيقًا صغيرًا متماسكًا فيبقى سهل التغيير.
\nلكل تطبيق تفاعلي بيانات تتغيّر. في Pocket هي قائمة المصاريف وفلتر الفئة الذي اختاره المستخدم. ضعها كلها في كائن واحد، هو الـ state (الحالة):
\nconst state = {\n expenses: loadExpenses(),\n filter: \"all\",\n};ثم اجعل دالة واحدة هي الطريقة الوحيدة لتغييره. إنها تطبّق التغيير، وتحفظ، وتعيد العرض:
\nfunction update(changes) {\n Object.assign(state, changes);\n saveExpenses(state.expenses);\n render();\n}Object.assign(state, changes) تنسخ خصائص changes إلى state، لذلك لا تغيّر update({ filter: "food" }) إلا الفلتر. وصار كل معالج حدث ينتهي بالطريقة نفسها: احسب القيم الجديدة، ثم استدعِ update. ولن تحتاج أبدًا إلى تذكّر الحفظ أو إعادة الرسم، لأن نسيانهما صار مستحيلًا.
تقرأ render الـ state وترسم الواجهة كلها. وكل ما يمكن حسابه من الـ state يُحسب هنا، لا يُخزَّن: القائمة المرئية تعتمد على الفلتر، والمجموع يعتمد على القائمة المرئية.
function render() {\n const visible =\n state.filter === \"all\"\n ? state.expenses\n : state.expenses.filter((e) => e.category === state.filter);\n\n list.replaceChildren();\n if (visible.length === 0) {\n const empty = document.createElement(\"li\");\n empty.className = \"empty\";\n empty.textContent = \"No expenses yet. Add your first one above.\";\n list.append(empty);\n }\n for (const expense of visible) {\n list.append(renderItem(expense));\n }\n totalEl.textContent = `Total: ${formatMoney(totalCents(visible))}`;\n}\n\nfunction renderItem(expense) {\n const li = document.createElement(\"li\");\n li.dataset.id = expense.id;\n const text = document.createElement(\"span\");\n text.textContent = `${expense.label}: ${formatMoney(expense.amount)} (${expense.category})`;\n const button = document.createElement(\"button\");\n button.type = \"button\";\n button.className = \"delete\";\n button.textContent = \"Delete\";\n button.setAttribute(\"aria-label\", `Delete ${expense.label}`);\n li.append(text, button);\n return li;\n}لأن render تبدأ دائمًا من الـ state، لا يمكن للفلتر والقائمة والمجموع أن تتناقض أبدًا. وتبديل الفلتر إلى “food” لا يُخفي بعض عناصر <li> ويعيد حساب رقم؛ بل يرسم ببساطة صورة مختلفة للـ state نفسه.
تفصيلتان تستحقّان النسخ. الحالة الفارغة تحوّل القائمة الخالية إلى إرشاد. والـ aria-label على زر الحذف تخبر مستخدمي قارئات الشاشة أيّ مصروف يحذفه الزر، فعشرة أزرار كلها باسم “Delete” لا فائدة منها لمن لا يرى الصف.
حين يكون الـ state وupdate وrender في مكانها، تصبح كل ميزة بضعة أسطر:
form.addEventListener(\"submit\", (event) => {\n event.preventDefault();\n const result = readExpenseForm(form); // { values } or { errors }\n if (result.errors) {\n showErrors(form, result.errors);\n return;\n }\n update({ expenses: addExpense(state.expenses, { id: nextId(), ...result.values }) });\n form.reset();\n form.elements.label.focus();\n});\n\nlist.addEventListener(\"click\", (event) => {\n const button = event.target.closest(\".delete\");\n if (!button) return;\n const id = button.closest(\"li\").dataset.id;\n update({ expenses: state.expenses.filter((e) => e.id !== id) });\n});\n\nfilterSelect.addEventListener(\"change\", () => {\n update({ filter: filterSelect.value });\n});\n\nrender();readExpenseForm وshowErrors هما كود النموذج من القسم 4، وقد نُقل إلى دالتين صغيرتين لهما اسمان: الأولى تقرأ وتشذّب وتحوّل وتتحقّق، وتُرجع إمّا قيمًا نظيفة أو كائن أخطاء؛ والثانية تكتب الرسائل وتضبط aria-invalid. ومنح كل منهما اسمًا يحوّل معالج الإرسال إلى ملخّص تستطيع قراءته في خمس ثوانٍ.
لاحظ ما لا تحتويه معالجات الأحداث: لا بناء للـ DOM، ولا حفظ، ولا مجاميع. إنها تقرأ الحدث، وتستدعي دوال نقية مثل addExpense من القسم 3، وتسلّم النتيجة إلى update. القواعد تعيش في expenses.js، حيث تستطيع اختبارها دون متصفّح؛ أما معالجات الأحداث فهي الغراء الذي يربط الأجزاء.
“إضافة مصروف تعمل” هي نقطة بداية الاختبار، لا نهايته. قبل أن تقول إن Pocket اكتمل، مرّ على هذه القائمة يدويًا:
\nabc أو 0 أو -5، كل منها يعرض رسالة واضحة ولا يضيف شيئًا.<b>hi</b> تظهر نصًا، والتسمية الطويلة جدًا لا تكسر التخطيط.كل بند هنا يأتي من درس في هذه الدورة، وكل منها يلتقط فئة حقيقية من الأخطاء كان المستخدمون سيكتشفونها نيابةً عنك.
\n\nالتمرين أدناه يسلّمك Pocket شبه مكتمل، وما زال عليك ربط التصفية والحذف. وبعد ذلك، درس قصير أخير حول وجهتك التالية.
\n","toc":[{"id":"sec-1","text":"الشكل: state واحد، وطريقة واحدة لتغييره","level":2},{"id":"sec-2","text":"دالة render تشتقّ كل شيء","level":2},{"id":"sec-3","text":"معالجات الأحداث تترجم الأحداث إلى تحديثات","level":2},{"id":"sec-4","text":"تعريف “مكتمل”","level":2}],"takeaways":["احتفظ بكل البيانات المتغيّرة في مكان واحد، وغيّرها عبر دالة واحدة تحفظ وتعيد العرض، فلا تختلف الصفحة والبيانات والتخزين أبدًا.","اشتقّ كل ما يمكنك اشتقاقه، مثل القائمة المرئية والمجاميع، من الـ state وقت العرض بدلًا من تخزينه منفصلًا.","الدوال النقية تحمل القواعد؛ ومعالجات الأحداث تبقى قصيرة ولا تفعل إلا ترجمة الأحداث إلى تغييرات في الـ state.","يكتمل التطبيق حين يتعامل مع الحالة الفارغة، والمدخلات السيئة، وإعادة التحميل، والاستخدام بلوحة المفاتيح وحدها، لا مع المسار السعيد فقط."],"further":[{"title":"Document.createElement() (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement"},{"title":"HTMLElement: change event (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event"}],"quiz":[{"q":"يعرض Pocket المصاريف مصفّاةً على “food” مع مجموع في الأسفل. من أين يجب أن تأتي القائمة المصفّاة؟
","options":[{"text":"من مصفوفة ثانية،foodExpenses، تُحدَّث كلما أُضيف مصروف أو حُذف.","why":"المصفوفتان اللتان يجب إبقاؤهما متزامنتين ستختلفان في النهاية، مثلًا بعد حذف لا يحدّث إلا إحداهما."},{"text":"من قراءة عناصر <li> الموجودة حاليًا على الصفحة.","why":"الصفحة صورة للبيانات. وقراءة البيانات منها تربط منطقك بالوسوم وتنكسر بسهولة."},{"text":"تُحسب داخل render من state.expenses وstate.filter في كل مرة.","why":"صحيح. البيانات المشتقّة التي يُعاد حسابها من مصدر الحقيقة الوحيد لا يمكن أن تصبح قديمة أبدًا."}],"answer":2},{"q":"كل معالج حدث في Pocket ينتهي بالخطوات الثلاث نفسها. أيّ ترتيب صحيح؟
","options":[{"text":"حدّث الـ state، ثم احفظه، ثم اعرض منه.","why":"صحيح. يتغيّر الـ state أولًا؛ ثم يقرأ الحفظ والعرض كلاهما من الـ state الجديد، فيعكسان البيانات نفسها."},{"text":"اعرض، ثم حدّث الـ state، ثم احفظ.","why":"العرض قبل تغيّر الـ state يرسم البيانات القديمة، فتكون الشاشة دائمًا متأخّرة خطوة."},{"text":"احفظ، ثم حدّث الـ state، ثم اعرض.","why":"الحفظ قبل التحديث يخزّن البيانات القديمة، فيضيع آخر تغيير عند إعادة التحميل."}],"answer":0},{"q":"أيّ مما يلي جزء من تعريف معقول لـ “مكتمل” في Pocket، يتجاوز “إضافة مصروف تعمل”؟
","options":[{"text":"كل دالة مكتوبة على شكل method في صنف.","why":"الأصناف أداة لا غاية. والدوال العادية غالبًا هي الخيار الأفضل للمنطق النقي."},{"text":"في التطبيق حركة (animation) واحدة على الأقل.","why":"اللمسات الجمالية لطيفة، لكنها لا تقول شيئًا عن صلاحية التطبيق للاستخدام الحقيقي."},{"text":"الكود لا يستخدم أي تعليمةif.","why":"الشروط ضرورية في البرامج الحقيقية. وتجنّبها ليس مقياسًا للجودة."},{"text":"تعرض القائمة رسالة مفيدة حين لا توجد مصاريف، وتنجو البيانات من إعادة التحميل.","why":"صحيح. الحالات الفارغة واستمرار البيانات جزء مما يختبره المستخدمون، لذلك مكانهما ضمن “مكتمل”."}],"answer":3}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"Pocket على وشك الاكتمال: الـ state وupdate وrender والتخزين ونموذج الإضافة كلها تعمل. اربط القطع الثلاث الأخيرة:
visibleExpenses() تُرجع فقط المصاريف التي تطابق category فيها قيمة state.filter، أو كلها حين يكون الفلتر "all". وrender تستخدمها أصلًا للقائمة وللمجموع.#filter، حدّث الفلتر.#expense-list يحذف المصروف الذي نُقر زر الحذف الخاص به.لا تغيّر البيانات إلا عبر update(...)، كي يُحفظ كل تغيير ويُعاد عرضه.
visibleExpenses عبارة عن if واحدة وfilter واحدة: state.expenses.filter((e) => e.category === state.filter).","filterSelect.addEventListener("change", () => update({ filter: filterSelect.value }));","للحذف: const button = event.target.closest(".delete"); if (!button) return; ثم اقرأ button.closest("li").dataset.id واستدعِ update({ expenses: state.expenses.filter((e) => e.id !== id) })."],"explanation":"الميزات الثلاث صغيرة لأن البنية تتولّى العمل الثقيل. الفلتر لا يُخزَّن في أي مكان سوى state.filter؛ والقائمة المرئية ومجموعها يُشتقّان منه وقت العرض، فلا يمكن أن يختلفا أبدًا. ومعالجا التصفية والحذف لا يفعلان إلا حساب القيم الجديدة واستدعاء update، التي تطبّقها، وتحفظها في التخزين، وتعيد العرض، فتكون البيانات المحفوظة دائمًا هي ما يراه المستخدم. والتفويض يعني أن مستمع الحذف يظل يعمل عبر كل إعادة عرض ومع المصاريف المضافة حديثًا. ولأن idCounter يبدأ بعد أعلى معرّف محفوظ، لا تعيد المصاريف الجديدة أبدًا استخدام معرّف مخزّن أصلًا.