حدود الخطأ وتجربة المستخدم للاسترداد

في بيئة الإنتاج، لا تحمل جميع حالات الفشل المعنى نفسه. فبعضها مؤقت وقابل للإصلاح، مثل طلب شبكة غير مستقر، أو مهلة قصيرة، أو حد معدل يتم مسحه عند إعادة المحاولة. بينما تشير حالات أخرى إلى أن واجهة المستخدم لم تعد موثوقة، مثل البيانات التالفة، أو انتهاك أحد الشروط الثابتة، أو حدث غير متوقع.null قيمة التي تخالف الافتراضات في أعماق الشجرة. إن التعامل مع كلا الفئتين بنفس الطريقة يؤدي إلى نتائج سيئة: إما أن تبالغ في رد فعلك (تخفي الشاشة بأكملها لمشكلة صغيرة) أو أن تقلل من رد فعلك (تستمر في عرض شجرة فرعية غير آمنة منطقيًا).

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

توفر حدود الأخطاء خيارًا أكثر أمانًا لـ React. فهي تسمح للمُعالج باكتشاف الأخطاء في شجرة فرعية محددة، وتثبيت واجهة مستخدم احتياطية لتلك المنطقة، مع الحفاظ على تشغيل باقي التطبيق. على عكس Suspense، لا تُوقف حدود الأخطاء عملية العرض أو تُعيد محاولتها تلقائيًا؛ فبمجرد حدوث خطأ، يتعامل React مع الشجرة الفرعية على أنها غير آمنة حتى يحدث تغيير ما في الشجرة. وعندما يكون ذلك مناسبًا، يمكن لحدود الأخطاء أيضًا دعم مسارات استرداد صريحة - إعادة المحاولة، أو إعادة التعيين، أو الانتقال إلى مكان آخر - دون إعادة تشغيل التطبيق بالكامل.

حدود الخطأ: عمليات احتياطية آمنة واستعادة صريحة

يتعامل React مع الأخطاء بشكل مختلف عن التعليق. إذا أطلق أحد المكونات خطأً أثناء العرض، فلا يمكن React متابعة عرض ذلك الجزء الفرعي بأمان. على عكسSuspense في حين أن React يمكنها التوقف مؤقتًا وإعادة المحاولة لاحقًا، يظل الخطأ "فشلًا" حتى يحدث تغيير ما، مثل جديدprops ،state أوremount .

ErrorBoundary تُنشئ المكونات مناطق احتواء. عند حدوث خطأ، يتتبع React الشجرة للعثور على أقرب منطقة احتواء.ErrorBoundary يصبح هذا الحد نقطة القرار: يتخلى React عن عملية العرض الفاشلة وcommits الحدودfallback بدلاً من ذلك، يتم استبدال الشجرة الفرعية المعطلة فقط مع الحفاظ على تشغيل باقي التطبيق.

الفرق مفتاح هو النية: أSuspense الخيار الاحتياطي يعني "غير جاهز بعد". بينماErrorBoundary يعني التراجع "عدم إمكانية العرض بأمان". لن يعيد React محاولة عرض شجرة فرعية بها خطأ تلقائيًا. يتطلب الاسترداد تغييرًا صريحًا، مثل تغيير المستخدم.retry ، أreset من حالة الحدود، أوremount .

عندما تقوم بالدمجErrorBoundary وSuspense ستحصل عن قصد على أداتين أمان متكاملتين: واحدة لـloading/latency وواحد لـruntime تُتيح هذه الأخطاء، مجتمعةً، للتطبيق التدهور تدريجيًا بدلًا من الانهيار. فالخطأ الذي يحدث أثناء العرض لا يُطبّق جزئيًا ثم يُصلح، بل يُبطل محاولة العرض الحالية لتلك الشجرة الفرعية. والسؤال مفتاح هو: هل ينتشر الخطأ صعودًا ويتسبب في انهيار مساحة أكبر، أم أنه محصور عند نقطة فاصلة مُصممة خصيصًا لهذا الغرض؟

يوضح الرسم التخطيطي بدء React لعملية عرض ومحاولة عرض شجرة فرعية. إذا تسبب أحد المكونات في حدوث خطأ أثناء العرض، يتخلى React فورًا عن محاولة عرض الشجرة الفرعية الفاشلة ويتجه تصاعديًا للعثور على أقرب شجرة فرعية.ErrorBoundary بمجرد العثور على العنصر المتضرر، يقوم React بتثبيت واجهة المستخدم الاحتياطية للحدود، مستبدلاً المنطقة المتضرر فقط مع الحفاظ على العناصر الأصلية والأشقاء المثبتة مسبقًا، بحيث تظل واجهة المستخدم المحيطة مرئية وتفاعلية. وتكون عملية الاسترداد واضحة: أي إجراء من المستخدم، أو تغيير في الحالة، أو إعادة ضبط الحدود، يؤدي إلى محاولة عرض جديدة لتلك الشجرة الفرعية، وإذا تم حل المشكلة الأساسية، يقوم React بتثبيت واجهة المستخدم العادية؛ وإلا، فإنه يقوم بتثبيت الواجهة الاحتياطية مرة أخرى.

مثال: إنشاء واجهة مستخدم للاسترداد مع حدود للأخطاء

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