صفحات خطأ مخصصة في التفاعل مع GraphQL وحدود الخطأ

صفحة الخطأ GitHub الرائعة 500

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

أحد التحديات التي واجهتها مؤخرًا أثناء العمل مع GraphQL و React هو كيفية التعامل مع الأخطاء. كمطورين ، من المحتمل أننا طبقنا الصفحات الافتراضية 500 و 404 و 403 في التطبيقات التي تم تقديمها بواسطة الخادم من قبل ، ولكن اكتشاف كيفية القيام بذلك باستخدام React و GraphQL أمر صعب.

في هذا المنشور ، سأتحدث عن الطريقة التي تعامل بها فريقنا مع هذه المشكلة ، والحل النهائي الذي طبقناه ، والدروس المثيرة للاهتمام من مواصفات GraphQL.

خلفية

كان المشروع الذي كنت أعمل عليه عبارة عن تطبيق CRUD نموذجي إلى حد ما تم بناؤه في React باستخدام GraphQL و Apollo Client و Express-graphQL. أردنا التعامل مع أنواع معينة من الأخطاء - على سبيل المثال ، الخادم متوقف - عن طريق عرض صفحة خطأ قياسية للمستخدم.

كان التحدي الأولي الذي يواجهنا هو اكتشاف أفضل طريقة لإبلاغ العميل بالأخطاء. لا يستخدم GraphQL رموز حالة HTTP مثل 500 و 400 و 403. وبدلاً من ذلك ، تحتوي الاستجابات على صفيف أخطاء مع قائمة بالأشياء التي حدث بها خطأ (اقرأ المزيد عن الأخطاء في مواصفات GraphQL).

على سبيل المثال ، إليك ما بدا عليه استجابة GraphQL عندما حدث شيء ما على الخادم:

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

يجب أن يحتوي كل خطأ على إدخال مع رسالة مفتاح مع وصف سلسلة من الخطأ المقصود للمطور كدليل لفهم وتصحيح الخطأ.

إضافة رموز الخطأ إلى ردود GraphQL

لحل هذا الأمر ، أضفنا رموز خطأ موحدة إلى كائنات الخطأ الخاصة بنا ، والتي يمكن استخدامها من قبل العملاء لتحديد الأخطاء برمجيًا. استلهم هذا الأمر من كيفية إرجاع واجهة برمجة تطبيقات REST API الخاصة بشرائط Stripe ، بالإضافة إلى الرسائل القابلة للقراءة البشرية.

لقد قررنا بدء تشغيل ثلاثة رموز خطأ: مصادقة ، مورد ، خطأ ، و server_error.

لإضافة هذه إلى استجابات GraphQL الخاصة بنا ، قمنا بتمرير دالة formatError الخاصة بنا إلى express-graphql التي تقوم بتعيين الاستثناءات التي تم طرحها على الخادم على الرموز القياسية التي تتم إضافتها إلى الاستجابة. لا تشجع مواصفات GraphQL بشكل عام إضافة خصائص إلى كائنات خطأ ، ولكنها تسمح بذلك عن طريق تداخل تلك الإدخالات في كائن ملحقات.

كانت أخطاء استجابة GraphQL الخاصة بنا سهلة التصنيف:

بينما قمنا بتطوير طريقتنا الخاصة لإضافة رموز إلى الاستجابات التي تم إنشاؤها بواسطة تعبير graphql ، يبدو أن خادم apollo يقدم سلوكًا مشابهًا مدمجًا.

تقديم صفحات الخطأ مع حدود خطأ الرد

بمجرد أن نتوصل إلى طريقة جيدة للتعامل مع الأخطاء في خادمنا ، فإننا نحول انتباهنا إلى العميل.

بشكل افتراضي ، أردنا أن يعرض تطبيقنا صفحة خطأ عامة (على سبيل المثال ، صفحة بها رسالة "oops حدث خطأ ما") عندما واجهنا server_error أو Authorization_error أو authorization_not_found. ومع ذلك ، أردنا أيضًا المرونة لتكون قادرًا على معالجة خطأ في مكون معين إذا أردنا ذلك.

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

ولتحقيق ذلك ، قمنا أولاً بإنشاء مكون يسمى GraphqlErrorHandler والذي سيكون بين مكونات Query و Mutation الخاصة بـ apollo-client وأطفالهم ليتم عرضهم. ألقى هذا المكون الذي تم التحقق من رموز الخطأ في الاستجابة استثناءً إذا حدد رمزًا قمنا برعايته:

لاستخدام GraphqlErrorHandler ، قمنا بتغليف مكونات الاستعلام والتحويل من apollo-client:

بعد ذلك ، استخدم مكون الميزة الخاص بنا مكون الاستعلام الخاص بنا بدلاً من الوصول مباشرة إلى رد فعل apollo:

الآن وبعد أن ألقى تطبيق React الخاص بنا استثناءات عندما أرجع الخادم الأخطاء ، أردنا التعامل مع هذه الاستثناءات وتعيينها على السلوك المناسب.

تذكر من وقت سابق أن هدفنا كان هو التقصير في عرض صفحات الأخطاء العامة (على سبيل المثال ، صفحة تحمل رسالة "oops حدث خطأ ما") ، ولكن لا تزال لدينا المرونة اللازمة للتعامل مع أي خطأ محليًا داخل أي مكون إذا أردنا ذلك.

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

لقد أنشأنا حدود خطأ تسمى GraphqlErrorBoundary من شأنها أن تلحق أي استثناءات متعلقة بالخادم وتعرض صفحة الخطأ المناسبة:

نستخدم حدود الخطأ كملف لكل مكونات تطبيقنا:

يمكن استخدام حدود الخطأ بشكل أعمق في شجرة المكون إذا أردنا معالجة الأخطاء في مكون بدلاً من تقديم صفحة خطأ.

على سبيل المثال ، إليك ما سيبدو إذا كنا نرغب في معالجة سلوك مخصص في مكوننا من قبل:

يتم إحتوائه

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