لقد قمنا بالفعل بتطوير خادم REST API كامل
باستخدام Express و MongoDB كجزء من هذه الدورة.
لكي يتمكن هذا الخادم من التواصل بشكل مفيد مع عملائنا،
سنقوم بإجراء بعض التعديلات الطفيفة
عليه بحيث يقوم بإرجاع النوع الصحيح من البيانات حتى
يتمكن تطبيق العميل من العمل
بكفاءة أكبر مع البيانات التي يتم إرجاعها من موقع الخادم الخاص بنا.
لذلك، للقيام بذلك،
دعونا نعمل على بعض التعديلات على موقع الخادم لدينا في هذا التمرين.
قبل البدء في هذا التمرين،
أفترض أنك لم تقم
بالدرس السابق على دمج العميل الزاوي
والخادم لأنك تقوم بهذا الدرس القادم من خلال تخصص React.
لذا، ستفترض التغييرات التي سأجريها على الخادم
أن إصدار الخادم الذي تقوم بتعديله هو قبل الدرس السابق.
في حال كنت قد فعلت هذا الدرس على العميل الزاوي،
سيتم تكرار بعض التغييرات التي قمت بها على الخادم الخاص بك مرة أخرى
في هذا التمرين حتى تتمكن من تخطي هذا الجزء من التغييرات.
انتقل إلى الخادم لدينا في المحرر.
قبل أن نبدأ العمل على الخادم،
أود أن أقترح أن تقوم بتنزيل جميع الصور التي
قدمتها كملف مضغوط في موارد التمرين تسمى images.zip.
قم بفك ضغط الملف ثم الحصول على جميع الصور من هناك ثم قم بنسخ تلك الصور
إلى مجلد الصور العامة في الخادم الخاص بنا.
لذلك، ترى أن هنا قمت بنسخ جميع الصور في مجلد الصور العامة الخاص بي هنا
بالفعل لأن خادمنا هو الذي
سيخدم كل هذه الصور لتطبيق العميل الخاص بنا.
بعد ذلك، نذهب إلى CORS وضبط القائمة البيضاء هنا.
لذلك، بالنسبة لتطبيق عميل React الخاص بنا،
إذا بدأنا باستخدام أمر بدء الغزل،
فإنه يعمل على اسم جهاز الكمبيوتر الخاص بك: 3001.
لذا، فإن أي طلب قادم من موقعنا
إلى الخادم سيحمل ذلك كمصدر هناك.
لهذا السبب سأقوم بإضافة ذلك إلى قائمتي البيضاء بحيث
يتم معالجة أي مشاكل CORS تلقائيًا.
لذلك، الذهاب إلى ملف cors.js في قائمتي البيضاء هنا،
اسمحوا لي أن أضيف في
اسم الكمبيوتر http://my: 3001 وهذا هو
الأصل الذي موكلي
سوف تنشأ الطلبات التي تأتي إلى هذا الخادم.
لذا، بهذه الطريقة لن يسبب CORS مشاكل لموكلي.
بعد ذلك، نحن بحاجة إلى تحديث عدد قليل من المسارات
للتعامل مع معلمات الاستعلام وأيضا بعض التعديلات الأخرى الطفيفة.
اسمحوا لي أن أبدأ مع ملف promoRouter.js.
هذا بسيط للحصول على تحديث.
لذلك، الذهاب إلى ملف promoRouter.js،
في ملف برومورووتر لطلب الحصول على أن نحصل
هنا بدلا من القيام الترقيات تجد مع كائن جافا سكريبت فارغة،
وهنا أود أن توريد req.query كمعلمة إلى الترقيات تجد هنا،
نفس الشيء مع جهاز التوجيه زعيم أيضا.
لذلك، اسمحوا لي أن انتقل إلى ملف leaderRouter.js.
في جهاز التوجيه الزعيم أيضا،
هنا حيث تجد Leaders.Find مع كائن جافا سكريبت فارغة بدلا من
ذلك استبدال ذلك مع req.query بحيث سيتم تمرير معلمات الاستعلام في.
لذلك، هذا هو المكان الذي سنمر فيه في الميزات: true كمعلمة الاستعلام هنا.
الآن، بعد تعديل هذين،
دعونا نعمل الآن على جهاز التوجيه الطبق.
لذلك، انتقل إلى ملف dishRouter.js،
حتى في جهاز التوجيه طبق أيضا نفس التحديث هنا.
لذلك، انتقل إلى هذه الأطباق. ابحث في طريقة الحصول هنا،
قم بتغيير ذلك إلى req.query.
لذلك، مع هذا، تم الانتهاء من تحديث جهاز التوجيه طبق بلدي.
لذلك، قمنا الآن بتحديث جهاز التوجيه الترويجي، الزعيم،
وجهاز التوجيه الطبق،
ثم سننتقل إلى تحديث جهاز التوجيه المفضل.
الآن، كنت قد نفذت جهاز التوجيه المفضل كجزء من المهمة الرابعة الخاصة بك.
الآن، في جهاز التوجيه المفضل،
سترى أن لجهاز التوجيه المفضل،
وأنا لا تظهر لك الجزء المتبقي لأنه
كان يجب أن تفعل كجزء من مهمتك.
أولا، اسمحوا لي أن ألفت انتباهكم إلى طريقة الحصول على favoriterouter.rout: dishid.
الآن أنا ذاهب إلى استخدام هذه الطريقة الحصول فقط للتحقق للتأكد
من أن طبق معين مع معرف الطبق هو بالفعل المفضلة للمستخدم.
لذلك، بدلا من مجرد قول getoperation.sanded،
أنا ذاهب فقط للاستفادة من وجود هذه العملية الحصول على وبعد ذلك سنقول،
favorites.Findone وسنقول المستخدم: req.user.
لذلك، سوف نجد المفضلة لهذا المستخدم معين ومن ثم سنقول ثم
المفضلة والقبض الخطأ المقبل.
ثم هنا بالمثل، سنضيف في الخطأ هنا، الخطأ التالي هنا.
لذلك، داخل هذا ثم،
عندما نحصل على المفضلة،
ثم نحن سوف تحقق إذا لم يكن المفضلة.
لذلك، إذا لم تكن هناك المفضلة
لهذا المستخدم، فمن الواضح أن الطبق الذي نقوم بالتحقق منه غير موجود،
لذلك سنعود Res.StatusCode 200،
Setheader، نوع المحتوى،
application/json ثم سنعود قائلا موجود كاذبة.
ما نحدده هنا هو أنه إذا تم القيام به إلى نقطة النهاية هذه مع معرف الطبق،
سيتم تعيين هذا العلم الموجود هنا إلى true إذا كان هذا الطبق جزءًا من المفضلة.
إذا كان هذا الطبق ليس جزءا من المفضلة,
وسوف أضع هناك علم موجود إلى كاذبة.
حتى هنا، ترى أنه منذ ليس لدي أي المفضلة لذلك
يجب أن يكون موجودا كاذبة تلقائيا في هذه المرحلة.
لذلك، سنقول موجود كاذبة وبعد ذلك سوف نعود المفضلة هنا.
حسنا، من الواضح، في هذه الحالة المفضلة ستكون فارغة في هذه المرحلة.
خلاف ذلك، مما يعني أن المفضلة ليست فارغة،
لذلك سنقول إذا favorites.dishes.indexOf.
لذا، نحن سَنَبْحثُ عن Req.params.dishid.
لذا، سنقوم بالبحث في مجموعة الأطباق المفضلة هذه
لمعرفة ما إذا كان هذا الطبق موجودًا هناك وإذا لم يكن موجودًا، فمن
الواضح أن هذا سيعود إلى مؤشر سلبي هنا.
في هذه الحالة أيضا،
سأعود بالضبط نفس هنا.
لذا، إذا قامت بإرجاع فهرس سلبي، فهذا يعني أنه
على الرغم من أن
هذا المستخدم معين لديه مجموعة من المفضلة،
فإن هذا الطبق المحدد غير موجود في قائمة المفضلة له، ولهذا السبب سيعود كاذبة هنا.
الآن، وإلا فإن هذا يعني أن الطبق موجود في قائمة المفضلة.
لذلك، في هذه الحالة،
سأعود رمز الحالة 200 موجود صحيح.
وبهذه الطريقة، عندما يقوم المستخدم بإجراء عملية الحصول على نقطة النهاية هذه
مع/favorites/dished حيث يتم توفير معرف الطبق كمعلمة هنا،
كمعلمة الطلب هنا،
ثم سنتحقق لمعرفة ما إذا كان هذا الطبق موجودًا في المفضلة.
إذا لم يكن أي من المفضلة موجودًا لهذا المستخدم، فسنقوم بإرجاع خطأ موجود.
وبالمثل، إذا كانت المفضلة موجودة ولكن
هذا الطبق معين غير موجود في المفضلة ثم سنعود كاذبة،
وإلا سنعود صحيح.
لذلك هذا العلم موجود يمكن استخدامها من قبل موكلي للتحقق لمعرفة ما إذا كان هذا الطبق هو
جزء من قائمة الأطباق المفضلة لهذا المستخدم أم لا.
أيضا بينما نحن في المفضلة,
كلما نجري أي تغييرات على المفضلة,
نريد أن تكون قادرة على ملء المستخدم والأطباق المعلومات,
المفضلة, قبل أن نعود.
على سبيل المثال، في المشاركة التي
نقوم بها، عندما نقوم بحفظ المفضلة ثم في هذه المرحلة،
نود أن نفعل أولا المفضلة.
findByID، لذلك لأننا فقط جعل التغييرات سوف نقول favorite_id
ونحن سوف
ملء كل من المستخدم وأيضا ملء الأطباق في المفضلة.
ثم عندما يتم إرجاع المفضلة،
سنقوم بإرجاع تلك المفضلة بدلا من ذلك.
لذلك، اسمحوا لي أن أجري هذا التغيير هنا.
لذلك، سوف نقطع هذا من هنا ومن ثم داخل ذلك الحين،
سنعيد المفضلة.
بعد أن نقوم بحفظ المفضلة،
ثم سنبحث عنها،
عن FavoriteByID ثم نعيد
تلك المفضلة هنا لذلك سنقول ثم العودة المفضلة ورمز الحالة.
هذا التغيير الذي يجب أن نقوم به.
إذا كنت قد نفذت هذا بالفعل في المفضلة لديك،
ثم لا تحتاج إلى إجراء هذا التغيير.
ولكن ما نقوم به هو كلما نجري تغييرات على المفضلة،
سنقوم بملء كل من معلومات المستخدم والأطباق ثم إرجاع هذه القيمة
لأن عميل React يتوقع أن يكون هناك.
الآن، نفس النوع من التغيير،
سنحتاج إلى إجراء متغير ب، حفظ التغييرات.
حتى في آخر هنا،
سنقوم بإجراء تغيير على ذلك،
لذلك سنقول favorites.save وبعد ذلك سوف نفعل favorites.findbyid وجعل هذا التغيير.
وبالمثل، تحت معرف الطبق،
أيضا في آخر،
سوف تكون بالمثل، كلما قمت بإجراء تغييرات على المفضلة،
وسوف ننظر أولا لذلك ومن ثم ملء كل من المستخدم والأطباق ومن ثم إعادته، ومن
ثم وبالمثل في الجزء الآخر.
لذلك، يجب أن تكون قد نفذت هذا في مهمتك الرابعة.
لذلك، قم بإجراء هذا التغيير الإضافي حيث ستقوم
بملء المستخدم والأطباق قبل إرجاع القيمة.
أيضا مع الحذف،
سنقوم بنفس التغييرات هنا.
لذلك، لاحظت أنه في الحذف،
لقد قمت بالفعل بإجراء هذا التغيير هنا.
لذلك، بعد حفظ التغييرات على المفضلة،
سنقوم ثم البحث عن المفضلة ومن ثم
العودة بعد ملء كل من المستخدم والأطباق والمفضلة.
هذا ما يتوقع منا عميلنا React القيام به.
لذلك، حتى بالنسبة للحذف،
سنقوم بنفس التغييرات.
الآن، مع هذا، يتم تحديث جهاز التوجيه المفضل لدي
لذلك سنمضي قدما لتحديث users.js المقبل.
وأخيرا، سنقوم بتحديث ملف users.js.
الآن، في ملف users.js نحن بحاجة إلى إضافة في
مجال router.options آخر هنا،
لأنه في بعض الأحيان طلب آخر كما رأيت
مع تسجيل الدخول سوف ترسل الخيارات أولا للتحقق،
وخاصة مع السيارات، ما إذا كان سيتم السماح بطلب آخر.
لذلك هذا هو السبب في أننا سوف تحقق بالطبع مع الخيارات هنا وبعد ذلك
سنقوم ببساطة بإرجاع
رسالة
حالة 200 ردا على ذلك.
لأي نقطة نهاية تحت المستخدمين إذا تلقينا الخيارات،
سنقوم ببساطة بإرجاع حالة 200 هنا.
الآن وظيفة تسجيل الدخول التي قمنا بتنفيذها في وقت سابق،
كنا قد فعلت ببساطة passport.authenticate
المحلية هنا وفحصنا عن القيم المتبقية هنا.
الآن، هذا passport.authenticate المحلية،
إذا لم يتم مصادقة المستخدم،
فإنه ببساطة إرجاع غير مصرح به في رسالة الرد.
الآن قد لا يكون ذلك مفيدًا جدًا لجانب العميل لعرض هذه المعلومات،
ولهذا السبب سنقوم بتحسين
طريقة تسجيل الدخول إلى جهاز التوجيه
هذه بحيث تقوم المصادقة بإرجاع معلومات أكثر أهمية في هذه المرحلة.
لذلك للقيام بذلك،
ونحن لن يكون القيام passport.authenticate هنا،
بدلا من ذلك سوف نأخذ.
لذلك، اسمحوا لي إزالة ذلك من هناك وبعد ذلك سترى
كيف سوف تحديث وظيفة جهاز التوجيه هنا.
لذلك، سنرى بالطبع مع الخيارات وبعد ذلك سنقوم بتضمين req،
الدقة والقادم هنا.
داخل هذا req، res والقادم هنا،
سوف passport.authenticate استدعاء هذا مع المحلية.
الآن، عندما نسمي هذا مع المحلي، في
حالة حدوث خطأ
في المصادقة، يمكن إجراء passport.authenticate لإرجاع
قيمة الخطأ، كما أنه سيعيد المستخدم إذا
لم يكن هناك خطأ ومعلمة ثالثة تسمى المعلومات
التي ستحمل معلومات إضافية قد يتم تحليلها مرة أخرى إلى المستخدم.
سيتم إرجاع هذا الخطأ عند وجود
خطأ حقيقي يحدث في passport.authenticate.
ولكن إذا
تم إرسال معلومات المستخدم إلى passport.authenticate ولكن المستخدم غير موجود،
فإن ذلك لا يتم حسابه كخطأ.
بدلاً من ذلك، سيتم حسابها نظرًا لأن المستخدم غير موجود
ويتم تحليل هذه المعلومات مرة أخرى في كائن المعلومات الذي يأتي.
لذلك، سيتم إرجاع الخطأ عندما يكون هناك
خطأ حقيقي يحدث أثناء عملية المصادقة،
ولكن المعلومات سوف تحتوي على معلومات إذا كان المستخدم غير موجود.
لذلك، يقوم passport.authenticate بتمرير رسالة تفيد بأن
المستخدم غير موجود أو إما أن اسم المستخدم
غير صحيح أو كلمة المرور غير صحيحة وهكذا.
لذلك، سيتم تمرير هذه المعلومات في رسالة المعلومات.
الآن سنرى كيف يكون هذا مفيدًا
لنا عندما ننظر إلى جانب العميل في وقت لاحق قليلاً.
لذلك، في هذه الحالة،
سوف نتعامل مع هذا على النحو التالي،
وليس فقط أنه عندما نسمي هذا passport.authenticate،
نحن بحاجة أيضا إلى تمرير في
req، الدقة، بعد المعلمات الثلاثة لذلك.
لذا، هذا هو الهيكل عندما تحتاج إلى استدعاء passport.authenticate ونتوقع منه أن
يمرر لك معلومات مثل هذه كطريقة رد الاتصال هنا،
لذلك تحتاج أيضًا إلى توفير هذا req، res،
التالي هناك أيضًا.
الآن، إذا حدث هذا،
لذلك سنقول إذا كان خطأ،
لذلك إذا كان هناك خطأ الذي يحدث،
سنقول العودة الخطأ التالي ثم السماح
معالج الخطأ من جهاز التوجيه السريع لدينا ورعاية ذلك.
الآن، سننظر في حالات أخرى، إن لم يكن المستخدم.
لذا، إذا وصلنا إلى هذه النقطة،
فهذا يعني أنه لم يكن خطأ حدث
ولكن بدلاً من ذلك ربما لا يمكن العثور على المستخدم.
إذا لم يتم العثور على المستخدم،
ثم سيتم تعيين المستخدم هنا إلى فارغة في هذه الحالة.
لذلك، في هذه الحالة،
إذا كان المستخدم غير موجود،
ثم نحن بحاجة إلى أن تكون قادرة على تمرير المعلومات مرة أخرى إلى جانب الخادم.
لذلك، ما سنفعله هو أننا سوف تمر في هذه المعلومات في هذا الشكل.
لذلك، أنا ذاهب لقطع هذا خارج من هنا
ومن ثم لصقه في هنا وبعد ذلك سوف نقوم بتحرير هذا.
لذلك، إذا كان المستخدم فارغًا،
فسنرسل رمز الحالة كـ 401 مما يعني
غير مصرح به ثم سنرسل معلومات نجاح كاذبة،
ومن ثم لن نقوم بتمرير الرمز المميز مرة أخرى،
سنقوم بتمرير رسالة الحالة مرة أخرى.
لذلك، هنا سوف نقول
«تسجيل الدخول غير ناجحة» ثم المعلومات الثالثة،
ونحن سوف تمر هذه المعلومات أن الكائن الذي تلقيناه هنا
كجزء ثالث في رسالة الرد التي نرسل مرة أخرى من الخادم لدينا هنا.
لذلك، سيتم تعيين علامة النجاح إلى false،
سيتم تعيين الحالة تسجيل الدخول غير ناجحة وسيتم تمرير
معلومات الخطأ التي يتم تمريرها في المعلومات مرة أخرى.
الآن، لاحظ أن هذا الموقف سيحدث إذا كان
اسم المستخدم وكلمة المرور غير صحيحة،
وبالتالي هذا ليس خطأ بمعنى الخطأ ولكن حقيقة أن
المصادقة لا يمكن العثور على المستخدم أو كلمة مرور المستخدم غير صحيحة.
لذلك، سيتم ترميز هذه المعلومات في المعلومات التي تأتي، وحتى أنني سوف
تمر مرة أخرى كخطأ إلى جانب العميل الخاص بي.
يتم التعامل مع الجزء خلاف ذلك كما Req.Login.
لذلك، إذا كان هذا ناجحا،
passport.authenticate سنقوم بإضافة هذه الطريقة تسمى Req.login للمستخدم.
لذلك، في هذه المرحلة،
سنقوم ببساطة بتمرير كائن المستخدم الذي حصلنا عليه.
حتى هنا، إذا وصلنا إلى هذه النقطة،
ثم وهذا يعني أن كائن المستخدم ليست فارغة وأيضا لم يحدث خطأ،
وهذا يعني أن المستخدم يمكن تسجيل الدخول.
لذلك، سنقول خطأ،
سنحاول تسجيل الدخول إلى المستخدم.
لذلك، سوف نقول إذا كان خطأ
وبعد ذلك سوف نمر مرة أخرى نفس النوع من معلومات الخطأ التي فعلناها هنا.
حتى في هذه الحالة، إذا كان خطأ،
ثم سنقوم بتمرير رمز الحالة كما 401 وسنقول النجاح
هو خطأ وحالة تسجيل الدخول غير ناجحة،
ثم معلومات الخطأ،
بدلا من المعلومات،
ونحن سوف تمر في «تعذر تسجيل الدخول المستخدم».
لذلك، هذه هي الرسالة التي سنمررها مرة أخرى هنا إذا حدث الخطأ.
وإلا، سنكون أسفل هنا.
لذلك، في هذه المرحلة،
سنكون قادرين على توليد الرمز المميز.
لذا، إذا وصلنا إلى هذه النقطة،
فهذا يعني أن المستخدم قد قام بتسجيل الدخول بنجاح،
وبالتالي يمكننا الآن إنشاء الرمز المميز.
لذلك، سنقوم بإنشاء الرمز المميز استنادًا إلى معرف المستخدم،
ثم سنقوم بتمرير الرمز المميز مرة أخرى إلى المستخدم.
لذلك، هنا، سوف نقول رمز فار،
وبعد ذلك يمكننا أن نقول res.StatusCode هو 200 ثم نجاح res.json صحيح،
لذلك، مما يعني أن المستخدم قام بتسجيل الدخول بنجاح.
لذلك، فإن الحالة ستكون تسجيل الدخول ناجحة.
ثم، الجزء الثالث،
بدلا من الخطأ،
وسوف تمرير الرمز مرة أخرى إلى المستخدم.
لذلك، سوف نقول رمزية،
وهذا الرمز الذي حصلنا عليه للتو في وقت سابق.
لذلك، سيتم تمرير هذا الرمز المميز كخاصية رمزية لرسالة الرد.
لذلك، هنا، لاحظ أن يتم تعيين النجاح إلى true، لذلك،
مما يعني أن المستخدم تسجيل الدخول بنجاح،
وبالتالي يمكن للمستخدم المضي قدما في هذه المرحلة.
يجب القيام بذلك داخل Req.Login هنا.
لذلك، في هذه المرحلة،
سنقوم بإغلاق Req.Login.
لذلك، لاحظ أن هذا هو داخل هذا req.Login هنا.
لذلك، في هناك، ونحن سوف تمر هذه الثلاثة مرة أخرى.
لذلك، اسمحوا لي فقط المسافة البادئة هذه الأسطر الثلاثة في.
لذا، هذه هي الطريقة التي سنتعامل بها مع طريقة تسجيل المستخدم.
لذلك، مرة أخرى، مراجعة هذا الرمز مرة أخرى.
لذلك، سنقوم بعمل وظيفة جهاز التوجيه،
ولكن بدلاً من القيام بمصادقة جواز السفر هناك،
سنقول req، res
، التالي، ثم في الداخل هنا،
سنقوم بإجراء مصادقة جواز سفر للمحلي،
وسوف تمر هذه المصادقة مرة أخرى.
لذلك، يمكننا توفير وظيفة رد اتصال لذلك،
وستعود وظيفة رد الاتصال هذه إما الخطأ، أو
المستخدم، أو المعلومات هنا.
لذلك، إذا كان خطأ،
ونحن سوف تسمح فقط معالج الخطأ صريحة لرعاية ذلك.
إذا كان المستخدم فارغًا،
فهذا يعني أن تسجيل دخول المستخدم لم يكن ناجحًا،
وسيكون السبب في ذلك في المعلومات.
لذلك، سيتم تمرير ذلك كخطأ المعلومات في رسالة الرد هنا.
إذا وصلنا إلى هذه النقطة،
ثم يتم التحقق من المستخدم بنجاح.
لذلك، ثم سنقوم بتسجيل الدخول للمستخدم.
لذا، مصادقة جواز السفر،
سنضيف في هذه الطريقة تسمى تسجيل الدخول إلى req، رسالة الطلب.
لذلك، يمكننا استدعاء تسجيل الدخول مع المستخدم.
إذا كان هذا إرجاع خطأ،
ثم سنقوم بإرجاع الخطأ هنا بشكل مناسب.
إذا لم يكن الأمر كذلك، فسنكون قد وصلنا إلى النقطة التي يتم فيها مصادقة المستخدم بنجاح.
لذلك، يمكننا إنشاء JSON Web Token هنا ثم إرجاع رمز
JSON Web Token إلى المستخدم للتأكد من تسجيل دخول المستخدم بنجاح.
إذن، هذه هي مجموعة الخطوات التي سنستخدمها هنا.
الآن، السبب في أنني أفعل طريقة أكثر تفصيلاً للتعامل معها هو
أنني أريد التمييز بين الوضع الذي
يحدث فيه خطأ حقيقي أثناء عملية المصادقة بدلاً من الوضع الذي
يكون فيه اسم المستخدم غير صالح أو كلمة المرور غير صالحة.
لذلك، سيتم التعامل مع هاتين الحالتين من خلال هذا الوضع،
حيث المعلومات سوف تحمل المعلومات مرة أخرى لنا.
لذلك، هذا ليس خطأ في حد ذاته،
ولكن هذا هو الوضع حيث المستخدم
ليس مستخدمًا صالحًا أو كلمة مرور المستخدم غير صالحة.
لذا، هذه هي الطريقة التي سنتعامل بها مع عملية تسجيل الدخول الخاصة بالمستخدم.
بالإضافة إلى ذلك، سأضيف
طريقة واحدة أخرى هنا تسمى CheckJwtToken.
من الممكن تمامًا أنه في حين قام العميل بتسجيل الدخول والحصول على رمز JSON Web Token، في
وقت لاحق، قد تنتهي صلاحية JSON Web Token.
لذا، إذا حاول المستخدم الوصول من جانب العميل باستخدام رمز مميز منتهي الصلاحية
إلى الخادم، فلن يتمكن الخادم من مصادقة المستخدم.
لذلك، على فترات دورية،
قد نرغب في التحقق للتأكد من أن رمز JSON Web Token لا يزال صالحًا.
لذلك، هذا هو السبب في أنني بما في ذلك هذا،
نقطة نهاية أخرى تسمى CheckJwtToken.
لذا، إذا قمت بالوصول إلى CheckJwtToken عن طريق
تضمين الرمز المميز في رأس التفويض،
فستعود هذه المكالمة إلى true أو false
للإشارة إليك إلى ما إذا كان JSON Web Token لا يزال صالحًا أم لا.
إذا لم يكن صالحًا، فيمكن لجانب العميل بدء تسجيل دخول آخر
للمستخدم للحصول على JSON Web Token الجديد إذا لزم الأمر.
لذلك، للقيام بذلك،
سنقول Cors.CorsWithOptions و req،
الدقة هنا كما هو متوقع.
هنا، سنقول
جواز السفر مصادقة jwt
والجلسة: false،
وهذا من شأنه أن يعود err، المستخدم، المعلومات.
لذلك، تذكر كيف نستخدم مصادقة جواز السفر في وقت سابق.
لذلك، نحن ندعو جوت مع جلسة كاذبة هنا.
لذلك، في وقت سابق هنا، نقول جواز السفر المصادقة المحلية.
لذلك، هذا هو للمصادقة المحلية.
لذلك، هذا هو لمصادقة JSON Web Token.
لذلك، عندما نسمي ذلك،
فنظرًا لأن ذلك سيتحقق من رمز JSON Web Token، لذا سنقول
، إذا أرجع الخطأ التالي،
ثم دع معالج الخطأ السريع يعتني بهذا الوضع.
ثم، سنقول، إن لم يكن المستخدم،
إذا كان المستخدم غير موجود، ثم وبالمثل آخر.
لذا، مما يعني أنه إذا تم
العثور على كائن المستخدم من JSON Web Token ثم تم تحميله على
req.user، فهذا يعني أن المستخدم مستخدم صالح،
وبالتالي يمكن السماح له بالمضي قدما.
خلاف ذلك، سنقول أن المستخدم غير موجود.
لذلك، نحن بحاجة إلى إبلاغ أن JSON Web Token قد انتهت صلاحيتها.
لذلك، في هذه المرحلة،
سنرسل دقة
مع رمز الحالة 401.
لذلك، غير مصرح به، سيثيادر، نوع المحتوى،
التطبيق/جسون، وبعد ذلك سنعود الدقة.
سيقول Res.json حالة JWT
غير صالحة، وبعد ذلك،
سنقوم بإرجاع علامة تسمى سقوط النجاح، وبعد ذلك،
سنقوم بإرجاع المعلومات التي نحصل عليها إذا
لم يتم مصادقة المستخدم كخطأ في هذه المرحلة.
خلاف ذلك، وهذا يعني أننا وصلنا إلى هذه النقطة،
ثم المستخدم هو مستخدم صالح.
لذلك، في هذه الحالة،
اسمحوا لي فقط نسخ هذا الرمز هنا،
ونحن سوف ترسل رمز الحالة من 200 ثم res.json،
وسوف ترسل جوت صالحة وناجحة كونها صحيحة.
الجزء الثالث، سوف نرسل معلومات المستخدم.
وبهذه الطريقة، عندما يتم استدعاء نقطة النهاية هذه باستخدام طريقة get،
فسيتحقق هذا مما إذا كان الرمز المميز صالحًا أم لا.
إذا كان الرمز المميز صالحًا،
فستتلقى هذا الرد ومن علامة النجاح في الرد،
يمكنك التحقق لمعرفة ما إذا كان jsonwebtoken صالحًا أم لا.
هذا مفيد على جانب العميل.
الآن، هذا جواز السفر المصادقة هنا يجب أن يتم توفيره
مع req و res كمعلمتين هنا.
لذا، هذه هي الطريقة التي نسميها جواز السفر المصادقة.
لذا، لاحظ أنه كلما اتصلت
بمصادقة جواز السفر وتتوقع وظيفة رد الاتصال هذه هنا،
تحتاج إلى إلحاق هذه النقطة req.res بمصادقة جواز السفر في الخلف هنا.
في خادم واجهة برمجة التطبيقات الخاص بنا،
قمنا بتنفيذ تعليقاتنا بطريقة
شكلت التعليقات مستندات فرعية داخل وثيقة ديش،
لذلك يشترون كل طبق مغلق مجموعة التعليقات الخاصة به.
ولكن الطريقة التي نفذنا بها عميل React هو
أن التعليقات تبقى مستقلة عن الأطباق،
والتعليقات نفسها تحمل معرف الطبق المقابل.
الآن، هذه طريقتان مختلفتان
لتنفيذ جانب الخادم بالإضافة إلى جانب العميل.
في تطبيق Angular الذي يتم تنفيذه في تخصصنا Angular،
استخدمنا طريقة المستند الفرعي
للتعامل مع التعليقات في تطبيق عميل Angular الخاص بنا.
لذا، تم
تنفيذ خادم واجهة برمجة التطبيقات الباقي بطريقة كانت أكثر ملاءمة للعميل Angular.
ولكن بالنسبة لعملاء React نظرًا لأننا أبقينا التعليقات مستقلة
عن الأطباق، ثم استخدم معرف الطبق داخل التعليق،
لذلك نحتاج إلى إعادة هيكلة خادم واجهة برمجة التطبيقات
الخاص بنا، بحيث يكون لدينا نقطة نهاية تعليق منفصلة مستقلة عن نقطة نهاية الأطباق.
لذلك، نحن بحاجة إلى إعادة هيكلة التعليمات البرمجية لدينا في الخادم
لتقديم /التعليقات ريست أبي نقطة النهاية في هذه المرحلة.
لذلك، للقيام بذلك،
دعونا نمضي قدما وتنفيذ نموذج جديد يسمى comment.js.
لذلك، الذهاب إلى النماذج،
اسمحوا لي تنفيذ ملف جديد اسمه comments.js.
في ملف comments.js،
سنقوم بنقل التعليقات من ملف dishes.js
إلى ملف comments.js ثم إزالته تمامًا من ملف. dishes.js
ولكن قبل أن نفعل ذلك،
نحن بحاجة إلى نسخ النمس والمخطط من هنا،
لذلك اسمحوا لي فقط نسخ هذا من dishes.js إلى comment.js.
بعد ذلك، الذهاب إلى dishes.js،
اسمحوا لي أن قطع هذا التعليق تماما من هنا،
لأننا سوف يكون لها هذا بشكل منفصل في نموذج التعليقات هنا.
لذلك، دعونا نقل ذلك إلى نموذج التعليقات ثم لصقه هنا.
ولكن بالطبع هذه ليست كاملة،
ونحن في طريقنا إلى تحديث التعليقات قليلا.
ولكن قبل أن نفعل ذلك،
والعودة إلى ملف dishes.js وفي ملف الأطباق،
ونحن سوف إزالة التعليقات من ديششيما،
لأننا في طريقنا إلى تخزين المحتوى بشكل منفصل عن
الأطباق في هذا الإصدار من خادمنا.
لذلك، هذه هي الطريقة التي سنقوم بتحديث نموذج الأطباق هنا.
لذلك، قمنا بإزالة التعليقات تماما من نموذج الأطباق هنا.
الذهاب إلى نموذج التعليقات،
لذلك نرى الآن أن لدينا التعليقات التي تم تنفيذها هنا.
ولكن بالإضافة إلى ذلك، في التعليقاتSchema،
نحتاج الآن إلى الإشارة بوضوح إلى
الطبق المحدد الذي يكون هذا التعليق التعليق هو التعليق المقابل.
الآن، هذا هو المكان الذي
لدينا السكان النمس
والطريقة التي نخزن بها الكائنات الهويات تأتي لإنقاذنا.
لذلك، سنقوم بتحديث التعليقات قائلا سيكون لدينا التقييم،
والتعليق، والمؤلف هنا.
بالإضافة إلى المؤلف،
وسوف نقدم حقل واحد آخر يسمى الطبق هنا الذي هو من
نوع: mongoose.مخطط types. Objectid،
وهكذا هذا سوف يشير إلى طبق هنا.
لذلك، سيكون هذا إشارة كائن إلى نموذج الطبق هنا،
وهكذا مع هذا التعديل الآن
سوف تحتوي تعليقاتنا على حقل التصنيف، حقل التعليق،
المؤلف الذي هو مرة أخرى إشارة إلى المستخدم المقابل،
ثم حقل الطبق الذي هو إشارة إلى طبق هنا.
لذلك، مما يعني أننا سنحتاج الآن إلى
ملء التعليقات مع كل من المؤلف ومجال الطبق.
بمجرد الانتهاء من
ذلك، فإننا سوف نقول var التعليقات
mongoose.model وسنسمي هذا «التعليق»،
ومن ثم يستخدم هذا التعليقات التي حددناها للتو هنا،
وبعد ذلك نحن بحاجة إلى تصدير هذا من هنا،
والتعليقات.model من هنا.
لذلك، الآن بعد أن قدمنا التعليقات.model،
ثم سنمضي قدما ثم نقدم جهاز توجيه جديد يسمى المعلق.
لذلك، لإدخال موجه التعليق،
دعونا نذهب إلى المسارات هنا،
ومن ثم إنشاء ملف جديد باسم commentRouter.js.
في commentRouter.js، اسمحوا لي بنسخ بعض الأشياء
من DishRouter.
لذلك، سيكون لدينا هذه التعليقات هنا،
لذلك اسمحوا لي أن نسخ على هذه الأشياء من وأيضا،
بينما أنا في ذلك اسمحوا لي فقط نسخ هذه أيضا حتى تلك النقطة،
وبعد ذلك سوف تحديث ذلك قليلا في وقت لاحق.
لذلك، الذهاب إلى التعليق،
نحن بحاجة إلى كل هذه الأجزاء،
لذلك سنقول كوم، إكسبريس، بوديبارسر، النمس،
المصادقة، كورس، وبعد ذلك سنقوم
باستيراد تعليقات من النماذج/التعليقات.
ثم سنقوم استدعاء هذا كما التعليق الذي هو express.Router هنا.
ثم سنقول CommentRouter استخدام بوديبارسر،
وبعد ذلك سيصبح هذا الآن مسار التعليق.
الآن، نحن بحاجة للذهاب إلى ديشروتر ومن ثم
إزالة جميع الأجزاء التي تشير إلى التعليقات هنا.
لذلك، اسمحوا لي فقط قطع هذا الجزء وبعد ذلك سوف نقوم بإعادة استخدام هذه ل المعلقين لدينا.
لذلك، لم تعد هناك حاجة إلى كل هذه في DishRouter.
لذلك، أنا ذاهب لإزالة كل هذا من DishRouter هنا،
لذلك اسمحوا لي أن قطعها،
كل ما يتعلق مسار التعليقات من DishRouter،
ثم سنذهب إلى التعليق،
ثم اسمحوا لي المضي قدما ولصق ذلك في مكان هنا،
ثم سنقوم بتحرير ذلك هنا.
ثم بعد ذلك، نحن بحاجة إلى تصدير المعلقين.
لذلك، سيتم تصدير المعلقين بالنسبة لنا.
ولكن بالطبع، هذا الرمز ليس دقيقًا تمامًا.
لذلك، نحن بحاجة إلى المضي قدما وإصلاح هذا الرمز هنا.
لذلك، بالنسبة لهذا الرمز،
ندرك الآن أن هذا ليس مسار DishRouter،
بدلاً من ذلك يجب أن يكون
نقطة/النهاية لأننا
سنقوم بتركيب هذا في/التعليقات نقطة النهاية هنا.
لذلك، سنقول CommentRouter،
ثم الخيارات CorsWithOptions (
req، الدقة) التي لا تزال على هذا النحو هناك،
ثم الحصول على cors.cors ثم req.res،
وبعد ذلك هذا واحد سوف تصبح تعليقات.
( فيندبيد)، (ريك)
لذلك، سيكون هذا التعليقات. البحث
و req.query هنا.
لذلك، عندما يتم العثور على التعليقات
، ثم، في هذه المرحلة،
سنقوم بملء المؤلف،
بالفعل هناك، وملء هنا.
لذلك، أنا فقط ذاهب لإزالة هذه التعليقات.المؤلف، وبعد ذلك،
سنقوم ببساطة ملء المؤلف هنا.
ثم، وهذا من شأنه أن يعطينا تعليقات هنا.
ثم، سنقول، وهذا يمكن تبسيطها بشكل كبير.
لذلك، خطأ الصيد هناك على أي حال.
لذا، عندما يأتي التعليق، سيعود ببساطة.
آسف، هذا يجب أن يكون.
لذا، إذا كان للحصول على،
عندما نحصل على التعليقات
والتعليقات.Find req.query، .populate المؤلف هنا
، وبعد ذلك، سوف نقول،. ثم التعليقات،
وبعد ذلك، سنقول، Res.StatusCode 200،
setheader، وبعد ذلك، سنقوم بإرجاع التعليقات من هنا،
تعليقات res.json من هنا.
الآن، أنا لا ملء الأطباق هنا لأنني لا أحتاج صراحة إلى
الأطباق بالطريقة التي أستخدم بها هذه المعلومات في عميل رد الفعل الخاص بي.
أنا فقط بحاجة إلى معرف الطبق،
ومعرف الطبق موجود بالفعل هناك،
وهذا جيد بما فيه الكفاية بالنسبة لي لاستخدام هذه البيانات في عميل رد الفعل الخاص بي.
لذلك، أنا ذاهب إلى ترك الأمر على هذا النحو هناك.
سأقوم فقط بملء
معلومات المؤلف هناك لأننا بحاجة إلى معلومات المؤلف الكاملة
كلما قمنا بتقديم عنصر تعليق في عميل الرد الخاص بنا.
لذلك، سيتم تحديث الحصول على مثل هذا هنا.
بالنسبة للوظيفة CorsWithOptions،
سنقول، Authenticate.VerifyUser req، الدقة، التالي.
من الواضح، من أجل نشر تعليق،
تحتاج إلى أن يكون المؤلف مستخدمًا صحيحًا تم تسجيل دخوله.
عندها فقط، ستسمح للمستخدم بنشر تعليق.
ثم، يأتي التعليق نفسه في نص رسالة الطلب الواردة.
لذا، أولاً، سنتحقق من الجسم
للتأكد من تضمين التعليق في الجسم هنا.
لذلك، هنا، أنا ذاهب لإزالة كل هذه الأجزاء، وبعد ذلك،
تبسيطها أكثر، وبعد ذلك،
سنقوم بتنفيذ هذا بشكل صحيح هناك.
لذا، في هذه المرحلة، سنقول،
إذا req.body لا يساوي فارغة،
مما يعني أن هناك تعليق مغلق داخل الجسم.
لذلك، اسمحوا لي أن قطع هذا ونقل هذا إلى إذا كان الجزء هنا،
وبعد ذلك، ونحن سوف تحرير ذلك هنا.
لذلك، إذا كان الجسم غير موجود،
ثم سوف يسبب خطأ.
لذلك، سنقول، خطأ جديد خطأ،
لم يتم العثور على تعليق في نص الطلب.
لذلك، سنرفع هذا الخطأ هنا.
حالة الخطأ هي 404.
ثم، سنقول، العودة الخطأ التالي.
لذلك، دعونا نتعامل مع جزء الخطأ هنا إذا كان الجسم
لا يحتوي على معلومات التعليق المناسبة.
إذا كان يحتوي، ثم، بطبيعة الحال،
ما سنفعله بعد ذلك هو،
سنقول، req.body.author هو req.user. _id
السبب في قيامنا بذلك هو أننا نتذكر أنه إذا كان
مستخدمًا مسجلاً وقام المستخدم بتسجيل الدخول،
فسيحتوي req.user على معلومات المستخدم.
لذلك، أنا فقط بحاجة إلى معرف المستخدم الذي قام بتسجيل الدخول حاليا.
لذا، سنقول، req.user. _id، وبعد ذلك،
سنقوم بتعيين req.body.author إلى req.user.
الآن، سيضمن المستخدم التحقق تلقائيًا أنه إذا قمت بالهبوط في هذه المرحلة،
فمن الواضح أنه سيكون لديك مستخدم قام بتسجيل الدخول بشكل صحيح.
وإلا، فإن ذلك قد تسبب بالفعل في المشكلة هناك.
لذلك، عندما تصل في هذه المرحلة،
سيكون لديك مستخدم صالح قام بتسجيل الدخول بالفعل إلى النظام هناك.
لذا، هذا هو المكان الذي ستتمكن منه الآن.
لذا، ما نقوم به هو أن حقل المؤلف،
ونحن نضعه بشكل صريح في معرف المستخدم هنا بحيث
يحتوي req.body على الأجزاء المتبقية من التعليق.
لذلك، كما تدرك، يحتوي التعليق على التصنيف،
والتعليق نفسه، والمؤلف، وحقول الطبق.
لذلك، يجب أن يتم ملء الأجزاء المتبقية من قبل المستخدم.
يجب بالفعل ملء التصنيف والتعليق ومعلومات الطبق
في نص رسالة الطلب الواردة.
يتم ترك جزء المؤلف شاغلاً هناك،
والذي سنقوم بإدراجه بشكل صريح في هذه المرحلة في الجسم هنا.
لذلك، الآن، سيحتوي req.body على معلومات التعليق بالكامل.
لذلك، في هذه المرحلة،
بدلا من القيام بذلك، وسوف نقول، والتعليقات. إنشاء.
باستخدام req.body، سنقوم بإنشاء التعليقات هنا.
بعد ذلك، سيعود هذا
التعليق المقابل للتعليق الذي قمنا بإدراجه هنا للتو.
الآن، مرة واحدة قد عاد التعليق،
ثم يجب أن نفعل التعليقات. findbyID.
الآن، السبب في أننا بحاجة إلى القيام بذلك هو أننا بحاجة
إلى ملء معلومات المؤلف هنا.
لذلك، سنقول، تعليقات فيندبيد. _id،
وبعد ذلك، سنقوم بملء معلومات المؤلف في التعليق نفسه.
ثم، سنقول، ثم التعليق.
الآن، من الواضح، هنا، ستجد أن التعليق سيكون
موجودًا لأننا قمنا للتو بإدراج هذا التعليق في مكانه هناك.
لذلك، هنا، سوف نعود ببساطة، Res.StatusCode هو 200،
Res.Setheader هو نوع المحتوى، التطبيق/json.
التعليق نفسه سيقول، res.json، ثم قم
بإرجاع التعليق في هذه المرحلة.
لذا، هذه هي الطريقة التي سنتعامل بها مع
إدراج تعليق جديد في جانب العميل لدينا هنا.
بالنسبة للوضع، كما تدرك،
لن تكون قادرًا على وضع النقاط/التعليقات/النهاية.
لذلك، سنقول، عملية بوت غير معتمدة على/التعليقات/نقطة النهاية.
هذا هو المغزى هذه هي الرسالة التي ستعود
لذلك، StatusCode هو 403،
وبعد ذلك، عملية PUT غير معتمدة على/التعليقات/.
الآن، عندما نقوم بحذف،
اسمحوا لي فقط قطع هذا من هنا، وبعد ذلك، سنقول،
التعليقات. إزالة.
مكتوبة فارغة. لذلك، عند القيام بحذف على نقطة النهاية تعليقات شرطة مائلة،
ستقوم بإزالة جميع التعليقات من النظام الخاص بك.
لذلك، هذه عملية خطيرة جدا، ولذا،
يجب أن لا تفعل ذلك بشكل طبيعي.
لذلك، سنسمح فقط للمشرف بإجراء مثل هذه العملية.
لذلك، سنقوم بإزالة جميع التعليقات من هناك.
لذلك، عندما تحصل على الرد،
ثم سنقول Res.StatusCode 200.
لذلك، اسمحوا لي فقط نسخ هذه الأجزاء هنا،
ومن ثم تأتي ولصقها هنا.
لذلك، سنقول، التعليقات. إزالة.
ثم الاستجابة Res.StatusCode 200 تطبيق json ثم res.json (استجابة) هنا.
لذا، هذه هي الطريقة التي نتعامل بها مع الحذف.
حذف العملية على نقطة نهاية تعليقات الشرطة المائلة.
الآن، المسار التالي هو موجه التعليق.
لذلك، هنا سوف نقول CommentRouter.Route
ونقطة النهاية هنا سيكون شرطة مائلة CommentId.
لذلك، هنا سوف تبقى الخيارات على هذا النحو.
ثم للحصول على جهاز التوجيه الحالي،
للحصول على سنقول، التعليقات. findbyID (req.params.
هذا سيكون موضع الثناء.
لذلك، بمجرد أن نجد التعليق المحدد،
فإننا سوف ملء فقط المؤلف من هناك.
ثم بمجرد ملء المؤلف،
ثم سنقول، ثم التعليق.
الآن، كل هذا الجزء غير ضروري هنا،
لذلك أنا ذاهب فقط لحذف الجزء.
هذا أيضا ليس الشيء المناسب هنا.
لذلك، اسمحوا لي إعادة تسمية رمز.
لذلك، سنقول للحصول على التعليقات. FindbyID،
ثم ملء المؤلف،
ثم التعليق، res.StatusCode هو 200، Setheader.
ثم الباقي هو جسون.
سنقوم ببساطة بإعادة التعليقات هنا.
لذلك، سنقوم بإرجاع التعليق في هذه المرحلة، res.json (تعليق).
ستجد التعليق المحدد،
ثم تعيد هذا التعليق للنشر.
بالنسبة لما بعد العملية، كما تدرك،
لا
يُسمح بما بعد العملية على التعليقات CommentId.
لذا، هذه هي الرسالة التي سنرسل،
عملية POST غير معتمدة على التعليقات المائلة CommentId.
لذا، هذه هي الرسالة التي سنقولها للوضع.
الآن، لوضع، ونحن سوف نقول التعليقات. العثور على حيث معرف (Req.params.commentid).
لذلك، سنجد التعليق هناك
، وهناك تعليق، لذلك لوضع.
لذلك، سنجد التعليق هناك،
ثم سنقول للتعليقات.
لذا، إذا وجدنا التعليق،
إذا لم يكن التعليق فارغًا،
فسنتحقق أيضًا مما إذا كان التعليق.
إذا لم يكن كذلك، فإن التعليق.arthur يساوي (req.user. _id).
لذلك، نحن نتبادل التحقق للتأكد من
أن التعليقات.المؤلف هو نفس المستخدم الحالي.
فقط المستخدم الحالي الذي تم تسجيل الدخول - إذا كان المستخدم هو نفسه كاتب التعليقات،
ثم سيتم السماح للمستخدم لتحديث.
لذلك، وهذا هو أول شيء أننا سوف تحقق.
لذلك، التعليقات، ثم التعليقات.author.equall rec.user.
إذا لم يكن الأمر كذلك، فستقول أنك غير مأذون له بتحديث هذا التعليق.
كما تشاه.403،
ثم قم بإرجاع الخطأ التالي هنا.
لذلك، سنقوم بإنشاء الخطأ هناك.
ثم بعد ذلك، ثم سنقول
req.body.author، req.user.
هذا مهم
الآن، هذين ليست ضرورية هنا،
لأننا نقوم بحفظ التعليق مباشرة.
ثم حبوب منع الحمل، وسنقول التعليقات.findbyidandupdate،
وreq.params.Commentid.
لذلك، سنجد هذا التعليق المحدد،
لأننا قد تم تزويدنا بالفعل معرف التعليق.
لذلك، سنقوم بالتعليقات findByid Req.params.Commentid.
ثم سنقول بعد ذلك (تعليق).
عند توفير Req.params.Commentid،
سيكون علينا توفير المعلمة الثانية بشكل صريح،
وهو ما نريد تغييره.
لذلك، سنقول مجموعة $: req.body.
لذا، فإن المعلمة الثانية، بشكل أساسي،
تخبرك بأي جزء تقوم بتغييره.
الآن، بما أننا قد تم تزويدنا الجسم الذي يحتوي على التعليق المحدث،
سنقوم فقط بتحديث التعليق بأكمله نفسه.
ثم الجزء الآخر الذي سنطلبه هو جديد: صحيح.
لذلك، سيضمن هذا أن التعليق المحدث سيتم إرجاعه
في دن هذه المكالمة إلى التعليقات. findbyidandupdate.
لذلك، سوف نقول ثم التعليقات.
عندما يتم إرجاع هذا التعليق،
ثم سنقول التعليقات. findbyID (تعليق. _id).
ثم ملء المؤلف هناك.
سنقوم بملء المؤلف هناك،
وبعد ذلك سنقول ثم التعليق.
لذلك، ترى أننا سوف تحصل على التعليق ومن ثم إرجاع التعليق في هذه المرحلة.
لذلك، هذه هي الطريقة التي سنقوم بتحديث التعليق.
لذا، هذا هو الوضع الذي لا يكون فيه التعليق فارغًا.
لذلك، هذا إذا كان البيان للتعليق ليس فارغًا.
لذلك، وإلا إذا كان جزء،
والآن هذا لا ينطبق،
لذلك سنقول آخر، خطأ.
الخطأ في هذه الحالة.
لذلك، إذا كان التعليق فارغًا،
فهذا يعني أننا لم نجد التعليق هناك،
لذلك لا يمكنك تعديل تعليق غير موجود.
لذلك سنقول خطأ،
لم يتم العثور على تعليق خطأ جديد Req.params.commentID وبعد ذلك سنقوم بإرجاع الخطأ.
لذلك، هذه هي الطريقة التي سنتعامل بها مع جزء من تعليقنا هنا،
ثم في النهاية الحذف.
للحذف، مرة أخرى سيكون لدينا للعثور أولا
التعليقات. findbyid (Req.params.commentid)
ثم التعليق.
لذا، سنبحث عن التعليق.
لذا، سنتحقق أولاً مما إذا كان التعليق لا يساوي القيمة الفارغة.
من المهم التحقق من ذلك هنا.
ثم، الجزء التالي الذي سنتحقق منه هو إذا كان التعليق.author يساوي req.user.
نحن نتأكد من أن هذا المستخدم الذي يحاول حذف
هذا التعليق هو بالضبط نفس المستخدم الذي أدرج التعليق في المقام الأول.
إذا لم يكن كذلك، لذلك إذا كان هذا هو الوضع،
ثم سترى «أنت غير مأذون لحذف هذا التعليق!»
ثم أعد الحالة هناك.
ثم أسفل هنا،
سنقول التعليقات. findbyidandRemove هنا.
لذلك، سنقول التعليقات. findbyidandRemove (Req.params.commentid)،
ثم سنحصل على بعض الرد من التعليق.
لذلك، في هذه المرحلة،
سنقول ببساطة، Res.StatusCode.
لذلك سنقول التعليقات. findbyidandRemove ثم الاستجابة.
إذا تمت إزالته بشكل صحيح،
فسنقول 200 ثم res.json
الاستجابة هنا وسنقوم أيضًا بالقبض على الخطأ في هذه المرحلة.
لذلك، اسمحوا لي فقط نسخ ذلك هنا وبعد ذلك سوف تشمل الصيد من الخطأ في هذه المرحلة.
إذاً، هذا أول شيء سنتحقق منه
سنضمن أن التعليق لا يساوي القيمة الفارغة.
خلاف ذلك، لذلك هذا هو الجزء الآخر.
لذلك، هذا هو الجزء الآخر من إذا كان خطأ آخر
تعليق جديد req.params.commentid لم يتم العثور عليه ثم
404 وإرسال جزء آخر بالنسبة لنا ومن ثم الجزء ثم التعامل بشكل مناسب.
لذلك، هذه هي التغييرات التي نجريها لجهاز التوجيه التعليق هنا.
لذلك، نحن نتعامل مع وظيفة الحصول على وضع وحذف
لتعليقات شرطة مائلة ونقطة شرطة مائلة لتأثير CommentId.
لذلك بمجرد الانتهاء من هذا،
ثم نحن بحاجة إلى تضمين هذا في ملف app.js.
لذلك، سوف نذهب إلى ملف app.js وبعد ذلك سنقول
فار التعليق
تتطلب المساربات/التعليق.
لذلك، لدينا جهاز توجيه التعليق هنا وبعد ذلك سوف نذهب
إلى ملف app.js أسفل هنا
وبعد ذلك سوف نقول app.use
تعليقات شرطة مائلة، CommentRouter هنا.
هذا كل شيء حتى الآن،
موجه التعليق الخاص بي جاهز.
لذلك، دعونا المضي قدما وحفظ جميع التغييرات.
ثم يتم تحديث الخادم لدينا الآن
من أجل التعامل مع جميع الطلبات من عملائنا React هنا.
الآن، إذا كنت تريد أن تفعل الطريقة البديلة، وهذا هو،
لديك تعليقاتك كوثائق فرعية من الطبق الخاص بك ومن ثم تريد التعامل مع ذلك،
ثم سوف تحتاج إلى تحديث العميل رد فعل
لتكون قادرة على استخدام التعليقات من داخل كل طبق بشكل مناسب.
هذا سيترك كممارسة لك
فكر في كيفية تصميم عميل رد الفعل الخاص بك بحيث
يعمل بشكل جيد للغاية مع الإصدار السابق من
الخادم الذي كان لديه تعليقات كوثائق فرعية من الأطباق الخاصة بك أنفسهم.
الآن، ستكون هذه طريقة مثيرة للاهتمام لتنفيذها.
بالطبع، الأمر أكثر تعقيدًا قليلاً من الطريقة التي
نفذنا بها عميل React حيث أبقينا التعليقات مستقلة عن
الأطباق ولكن بعد ذلك يكون العمل الإضافي هو مسؤولية
جانب العميل لأنك تحتاج إلى تحديد
التعليقات المناسبة عند عرض طبق معين.
تحتاج إلى تحديد التعليقات من جميع التعليقات هنا.
لذا، هذا عمل إضافي يقوم به عميل React الخاص بنا بسبب
حقيقة أننا فصلنا التعليقات عن الأطباق نفسها.
وبالمثل، إذا كنت تستطيع إعادة تصميم العميل الزاوي الخاص بك لتكون قادرة
على التعامل مع الوضع حيث يتم الاحتفاظ التعليقات مستقلة عن الأطباق الخاصة بك.
الآن، هذه هي جميع التمارين التي يمكنك القيام بها من أجل معرفة كيف يمكنك
توسيع تطبيقات العميل الخاصة بك للتعامل مع أي نوع من الخوادم، وهما
نوعان مختلفان من الخوادم هناك.
لذلك، مع هذا، ونحن استكمال التحديث إلى الخادم لدينا هنا.
لذلك، مع هذا، قمنا بتحديث كل شيء على جانب الخادم.
لذلك، دعونا حفظ جميع التغييرات على جانب الخادم.
حتى الآن، الخادم الخاص بنا جاهز للتعامل مع الطلبات الواردة من عميل React الخاص بنا.
مع هذا، نكمل هذا التمرين.
في هذا التمرين، قمنا الآن بإعداد الخادم السريع الخاص بنا
للتعامل مع الطلبات الواردة من عميل React الخاص بنا.
في التمرين التالي، سننظر إلى العميل المتفاعل بمزيد من التفصيل
لفهم كيفية التواصل مع هذا الخادم الإضافي.
هذا هو الوقت المناسب بالنسبة لك للقيام
بتغطية git مع رسالة دمج العميل والخادم.