تنفيذ التحديثات المتفائلة يدويًا

تبدأ التحديثات المتفائلة اليدوية بحالة محلية للمكوّن تتم تهيئتها من بيانات الخادم: const [items, setItems] = useState(serverItems). وهذه الحالة المحلية هي ما تعرضه، وهي ما ستعدّله بشكل متفائل. لا تعدّل البيانات التي جلبها الخادم مباشرةً، بل احتفظ بنسخة محلية تتحكم فيها.

عندما يبدأ المستخدم عملية تعديل، مثل النقر على «إضافة» أو «إعجاب» أو «حذف»، نفّذ تحديث الحالة فورًا قبل استدعاء API: setItems(prev => [...prev, newItem]). تعكس الواجهة التغيير مباشرةً. وبعد هذا التحديث فقط، أرسل طلب الشبكة الفعلي.

قبل تنفيذ التحديث المتفائل، احفظ الحالة الحالية: const previousItems = items. وتُعد هذه اللقطة الهدف الذي ستتراجع إليه. فإذا فشل استدعاء API، تستعيد هذه القيمة. خزّنها في متغير، لا في الحالة، لأنك تحتاج إليها فقط طوال مدة عملية التعديل المعلّقة.

بعد التحديث المتفائل، أجرِ استدعاء API بشكل غير متزامن. لفّه داخل try/catch. عند النجاح، يمكنك اختياريًا إعادة جلب البيانات لمزامنة حالة الخادم، أو الوثوق بالحالة المتفائلة إذا كان الخادم سيعيد البيانات نفسها. وعند الفشل، استخدم الحالة السابقة التي حفظتها للتراجع.

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

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

عند إضافة عنصر جديد بشكل متفائل، لا يكون الخادم قد عيّن له معرّفًا حقيقيًا بعد. أنشئ معرّفًا مؤقتًا للعنصر المتفائل: const tempId = crypto.randomUUID(). استخدمه مفتاحًا للعنصر في القائمة. وبعد استجابة API بنجاح، استبدل المعرّف المؤقت بالمعرّف الحقيقي الذي عيّنه الخادم.

بعد نجاح عملية إنشاء، يستجيب الخادم بالمعرّف الحقيقي. حدّث حالتك لاستبدال العنصر المؤقت: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). وتضمن هذه التسوية استخدام معرّف الخادم الصحيح في العمليات اللاحقة.

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

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

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

لماذا تحتاج العناصر المضافة بتفاؤل إلى معرّف مؤقت؟

النمط اليدوي هو: احتفظ بنسخة من previousItems، واضبط items باستخدام الحالة الجديدة، واستدعِ واجهة برمجة التطبيقات، ثم أعد الحالة السابقة عند الفشل باستخدام setItems(previousItems) واعرض رسالة خطأ. عند الإضافة، استخدم crypto.randomUUID() كمعرّف مؤقت، ثم طابقه مع معرّف الخادم عند النجاح. امنع حالات التنافس بتعطيل زر التشغيل أثناء تنفيذ عمليات التغيير. يُعد التراجع + إشعار toast + إعادة المحاولة تجربة المستخدم القياسية عند الفشل.