1 00:00:03,650 --> 00:00:08,385 لقد قمنا بالفعل بتطوير خادم REST API كامل 2 00:00:08,385 --> 00:00:12,485 باستخدام Express و MongoDB كجزء من هذه الدورة. 3 00:00:12,485 --> 00:00:16,965 لكي يتمكن هذا الخادم من التواصل بشكل مفيد مع عملائنا، 4 00:00:16,965 --> 00:00:19,590 سنقوم بإجراء بعض التعديلات الطفيفة 5 00:00:19,590 --> 00:00:22,440 عليه بحيث يقوم بإرجاع النوع الصحيح من البيانات حتى 6 00:00:22,440 --> 00:00:24,780 يتمكن تطبيق العميل من العمل 7 00:00:24,780 --> 00:00:28,935 بكفاءة أكبر مع البيانات التي يتم إرجاعها من موقع الخادم الخاص بنا. 8 00:00:28,935 --> 00:00:30,410 لذلك، للقيام بذلك، 9 00:00:30,410 --> 00:00:36,580 دعونا نعمل على بعض التعديلات على موقع الخادم لدينا في هذا التمرين. 10 00:00:36,580 --> 00:00:39,215 قبل البدء في هذا التمرين، 11 00:00:39,215 --> 00:00:42,410 أفترض أنك لم تقم 12 00:00:42,410 --> 00:00:46,430 بالدرس السابق على دمج العميل الزاوي 13 00:00:46,430 --> 00:00:55,395 والخادم لأنك تقوم بهذا الدرس القادم من خلال تخصص React. 14 00:00:55,395 --> 00:01:01,190 لذا، ستفترض التغييرات التي سأجريها على الخادم 15 00:01:01,190 --> 00:01:07,430 أن إصدار الخادم الذي تقوم بتعديله هو قبل الدرس السابق. 16 00:01:07,430 --> 00:01:11,540 في حال كنت قد فعلت هذا الدرس على العميل الزاوي، 17 00:01:11,540 --> 00:01:16,505 سيتم تكرار بعض التغييرات التي قمت بها على الخادم الخاص بك مرة أخرى 18 00:01:16,505 --> 00:01:22,495 في هذا التمرين حتى تتمكن من تخطي هذا الجزء من التغييرات. 19 00:01:22,495 --> 00:01:26,055 انتقل إلى الخادم لدينا في المحرر. 20 00:01:26,055 --> 00:01:29,125 قبل أن نبدأ العمل على الخادم، 21 00:01:29,125 --> 00:01:33,530 أود أن أقترح أن تقوم بتنزيل جميع الصور التي 22 00:01:33,530 --> 00:01:38,380 قدمتها كملف مضغوط في موارد التمرين تسمى images.zip. 23 00:01:38,380 --> 00:01:43,160 قم بفك ضغط الملف ثم الحصول على جميع الصور من هناك ثم قم بنسخ تلك الصور 24 00:01:43,160 --> 00:01:48,290 إلى مجلد الصور العامة في الخادم الخاص بنا. 25 00:01:48,290 --> 00:01:55,010 لذلك، ترى أن هنا قمت بنسخ جميع الصور في مجلد الصور العامة الخاص بي هنا 26 00:01:55,010 --> 00:01:58,160 بالفعل لأن خادمنا هو الذي 27 00:01:58,160 --> 00:02:02,275 سيخدم كل هذه الصور لتطبيق العميل الخاص بنا. 28 00:02:02,275 --> 00:02:07,835 بعد ذلك، نذهب إلى CORS وضبط القائمة البيضاء هنا. 29 00:02:07,835 --> 00:02:11,565 لذلك، بالنسبة لتطبيق عميل React الخاص بنا، 30 00:02:11,565 --> 00:02:15,275 إذا بدأنا باستخدام أمر بدء الغزل، 31 00:02:15,275 --> 00:02:18,470 فإنه يعمل على اسم جهاز الكمبيوتر الخاص بك: 3001. 32 00:02:18,470 --> 00:02:22,040 لذا، فإن أي طلب قادم من موقعنا 33 00:02:22,040 --> 00:02:25,760 إلى الخادم سيحمل ذلك كمصدر هناك. 34 00:02:25,760 --> 00:02:30,380 لهذا السبب سأقوم بإضافة ذلك إلى قائمتي البيضاء بحيث 35 00:02:30,380 --> 00:02:35,390 يتم معالجة أي مشاكل CORS تلقائيًا. 36 00:02:35,390 --> 00:02:40,985 لذلك، الذهاب إلى ملف cors.js في قائمتي البيضاء هنا، 37 00:02:40,985 --> 00:02:49,460 اسمحوا لي أن أضيف في 38 00:02:49,460 --> 00:02:55,640 اسم الكمبيوتر http://my: 3001 وهذا هو 39 00:02:55,640 --> 00:02:58,610 الأصل الذي موكلي 40 00:02:58,610 --> 00:03:02,075 سوف تنشأ الطلبات التي تأتي إلى هذا الخادم. 41 00:03:02,075 --> 00:03:07,075 لذا، بهذه الطريقة لن يسبب CORS مشاكل لموكلي. 42 00:03:07,075 --> 00:03:11,690 بعد ذلك، نحن بحاجة إلى تحديث عدد قليل من المسارات 43 00:03:11,690 --> 00:03:17,690 للتعامل مع معلمات الاستعلام وأيضا بعض التعديلات الأخرى الطفيفة. 44 00:03:17,690 --> 00:03:21,280 اسمحوا لي أن أبدأ مع ملف promoRouter.js. 45 00:03:21,280 --> 00:03:25,010 هذا بسيط للحصول على تحديث. 46 00:03:25,010 --> 00:03:27,570 لذلك، الذهاب إلى ملف promoRouter.js، 47 00:03:27,570 --> 00:03:32,360 في ملف برومورووتر لطلب الحصول على أن نحصل 48 00:03:32,360 --> 00:03:37,610 هنا بدلا من القيام الترقيات تجد مع كائن جافا سكريبت فارغة، 49 00:03:37,610 --> 00:03:47,320 وهنا أود أن توريد req.query كمعلمة إلى الترقيات تجد هنا، 50 00:03:47,320 --> 00:03:49,680 نفس الشيء مع جهاز التوجيه زعيم أيضا. 51 00:03:49,680 --> 00:03:52,745 لذلك، اسمحوا لي أن انتقل إلى ملف leaderRouter.js. 52 00:03:52,745 --> 00:03:54,815 في جهاز التوجيه الزعيم أيضا، 53 00:03:54,815 --> 00:04:00,545 هنا حيث تجد Leaders.Find مع كائن جافا سكريبت فارغة بدلا من 54 00:04:00,545 --> 00:04:06,685 ذلك استبدال ذلك مع req.query بحيث سيتم تمرير معلمات الاستعلام في. 55 00:04:06,685 --> 00:04:14,260 لذلك، هذا هو المكان الذي سنمر فيه في الميزات: true كمعلمة الاستعلام هنا. 56 00:04:14,260 --> 00:04:16,945 الآن، بعد تعديل هذين، 57 00:04:16,945 --> 00:04:19,340 دعونا نعمل الآن على جهاز التوجيه الطبق. 58 00:04:19,340 --> 00:04:22,115 لذلك، انتقل إلى ملف dishRouter.js، 59 00:04:22,115 --> 00:04:26,310 حتى في جهاز التوجيه طبق أيضا نفس التحديث هنا. 60 00:04:26,310 --> 00:04:31,200 لذلك، انتقل إلى هذه الأطباق. ابحث في طريقة الحصول هنا، 61 00:04:31,200 --> 00:04:33,945 قم بتغيير ذلك إلى req.query. 62 00:04:33,945 --> 00:04:38,070 لذلك، مع هذا، تم الانتهاء من تحديث جهاز التوجيه طبق بلدي. 63 00:04:38,070 --> 00:04:42,085 لذلك، قمنا الآن بتحديث جهاز التوجيه الترويجي، الزعيم، 64 00:04:42,085 --> 00:04:43,850 وجهاز التوجيه الطبق، 65 00:04:43,850 --> 00:04:48,050 ثم سننتقل إلى تحديث جهاز التوجيه المفضل. 66 00:04:48,050 --> 00:04:54,380 الآن، كنت قد نفذت جهاز التوجيه المفضل كجزء من المهمة الرابعة الخاصة بك. 67 00:04:54,380 --> 00:04:56,530 الآن، في جهاز التوجيه المفضل، 68 00:04:56,530 --> 00:04:58,910 سترى أن لجهاز التوجيه المفضل، 69 00:04:58,910 --> 00:05:01,010 وأنا لا تظهر لك الجزء المتبقي لأنه 70 00:05:01,010 --> 00:05:03,435 كان يجب أن تفعل كجزء من مهمتك. 71 00:05:03,435 --> 00:05:11,520 أولا، اسمحوا لي أن ألفت انتباهكم إلى طريقة الحصول على favoriterouter.rout: dishid. 72 00:05:11,520 --> 00:05:17,405 الآن أنا ذاهب إلى استخدام هذه الطريقة الحصول فقط للتحقق للتأكد 73 00:05:17,405 --> 00:05:25,460 من أن طبق معين مع معرف الطبق هو بالفعل المفضلة للمستخدم. 74 00:05:25,460 --> 00:05:29,130 لذلك، بدلا من مجرد قول getoperation.sanded، 75 00:05:29,130 --> 00:05:36,165 أنا ذاهب فقط للاستفادة من وجود هذه العملية الحصول على وبعد ذلك سنقول، 76 00:05:36,165 --> 00:05:47,500 favorites.Findone وسنقول المستخدم: req.user. 77 00:05:49,220 --> 00:05:59,340 لذلك، سوف نجد المفضلة لهذا المستخدم معين ومن ثم سنقول ثم 78 00:06:03,070 --> 00:06:25,530 المفضلة والقبض الخطأ المقبل. 79 00:06:25,530 --> 00:06:35,265 ثم هنا بالمثل، سنضيف في الخطأ هنا، الخطأ التالي هنا. 80 00:06:35,265 --> 00:06:37,380 لذلك، داخل هذا ثم، 81 00:06:37,380 --> 00:06:39,495 عندما نحصل على المفضلة، 82 00:06:39,495 --> 00:06:45,360 ثم نحن سوف تحقق إذا لم يكن المفضلة. 83 00:06:45,360 --> 00:06:47,690 لذلك، إذا لم تكن هناك المفضلة 84 00:06:47,690 --> 00:06:53,900 لهذا المستخدم، فمن الواضح أن الطبق الذي نقوم بالتحقق منه غير موجود، 85 00:06:53,900 --> 00:07:07,520 لذلك سنعود Res.StatusCode 200، 86 00:07:07,520 --> 00:07:14,370 Setheader، نوع المحتوى، 87 00:07:17,230 --> 00:07:36,735 application/json ثم سنعود قائلا موجود كاذبة. 88 00:07:36,735 --> 00:07:44,215 ما نحدده هنا هو أنه إذا تم القيام به إلى نقطة النهاية هذه مع معرف الطبق، 89 00:07:44,215 --> 00:07:52,835 سيتم تعيين هذا العلم الموجود هنا إلى true إذا كان هذا الطبق جزءًا من المفضلة. 90 00:07:52,835 --> 00:07:55,290 إذا كان هذا الطبق ليس جزءا من المفضلة, 91 00:07:55,290 --> 00:07:58,100 وسوف أضع هناك علم موجود إلى كاذبة. 92 00:07:58,100 --> 00:08:01,190 حتى هنا، ترى أنه منذ ليس لدي أي المفضلة لذلك 93 00:08:01,190 --> 00:08:04,770 يجب أن يكون موجودا كاذبة تلقائيا في هذه المرحلة. 94 00:08:04,770 --> 00:08:13,020 لذلك، سنقول موجود كاذبة وبعد ذلك سوف نعود المفضلة هنا. 95 00:08:13,180 --> 00:08:19,090 حسنا، من الواضح، في هذه الحالة المفضلة ستكون فارغة في هذه المرحلة. 96 00:08:19,090 --> 00:08:26,440 خلاف ذلك، مما يعني أن المفضلة ليست فارغة، 97 00:08:26,440 --> 00:08:32,750 لذلك سنقول إذا favorites.dishes.indexOf. 98 00:08:36,840 --> 00:08:45,995 لذا، نحن سَنَبْحثُ عن Req.params.dishid. 99 00:08:45,995 --> 00:08:51,220 لذا، سنقوم بالبحث في مجموعة الأطباق المفضلة هذه 100 00:08:51,220 --> 00:08:56,605 لمعرفة ما إذا كان هذا الطبق موجودًا هناك وإذا لم يكن موجودًا، فمن 101 00:08:56,605 --> 00:09:00,525 الواضح أن هذا سيعود إلى مؤشر سلبي هنا. 102 00:09:00,525 --> 00:09:02,340 في هذه الحالة أيضا، 103 00:09:02,340 --> 00:09:05,440 سأعود بالضبط نفس هنا. 104 00:09:05,440 --> 00:09:08,630 لذا، إذا قامت بإرجاع فهرس سلبي، فهذا يعني أنه 105 00:09:08,630 --> 00:09:12,260 على الرغم من أن 106 00:09:12,260 --> 00:09:16,190 هذا المستخدم معين لديه مجموعة من المفضلة، 107 00:09:16,190 --> 00:09:22,340 فإن هذا الطبق المحدد غير موجود في قائمة المفضلة له، ولهذا السبب سيعود كاذبة هنا. 108 00:09:22,340 --> 00:09:30,255 الآن، وإلا فإن هذا يعني أن الطبق موجود في قائمة المفضلة. 109 00:09:30,255 --> 00:09:31,859 لذلك، في هذه الحالة، 110 00:09:31,859 --> 00:09:36,670 سأعود رمز الحالة 200 موجود صحيح. 111 00:09:36,670 --> 00:09:43,825 وبهذه الطريقة، عندما يقوم المستخدم بإجراء عملية الحصول على نقطة النهاية هذه 112 00:09:43,825 --> 00:09:52,015 مع/favorites/dished حيث يتم توفير معرف الطبق كمعلمة هنا، 113 00:09:52,015 --> 00:09:55,630 كمعلمة الطلب هنا، 114 00:09:55,630 --> 00:10:00,650 ثم سنتحقق لمعرفة ما إذا كان هذا الطبق موجودًا في المفضلة. 115 00:10:00,650 --> 00:10:05,775 إذا لم يكن أي من المفضلة موجودًا لهذا المستخدم، فسنقوم بإرجاع خطأ موجود. 116 00:10:05,775 --> 00:10:08,120 وبالمثل، إذا كانت المفضلة موجودة ولكن 117 00:10:08,120 --> 00:10:12,320 هذا الطبق معين غير موجود في المفضلة ثم سنعود كاذبة، 118 00:10:12,320 --> 00:10:13,910 وإلا سنعود صحيح. 119 00:10:13,910 --> 00:10:20,260 لذلك هذا العلم موجود يمكن استخدامها من قبل موكلي للتحقق لمعرفة ما إذا كان هذا الطبق هو 120 00:10:20,260 --> 00:10:27,755 جزء من قائمة الأطباق المفضلة لهذا المستخدم أم لا. 121 00:10:27,755 --> 00:10:30,139 أيضا بينما نحن في المفضلة, 122 00:10:30,139 --> 00:10:33,410 كلما نجري أي تغييرات على المفضلة, 123 00:10:33,410 --> 00:10:37,870 نريد أن تكون قادرة على ملء المستخدم والأطباق المعلومات, 124 00:10:37,870 --> 00:10:39,535 المفضلة, قبل أن نعود. 125 00:10:39,535 --> 00:10:43,240 على سبيل المثال، في المشاركة التي 126 00:10:43,240 --> 00:10:48,470 نقوم بها، عندما نقوم بحفظ المفضلة ثم في هذه المرحلة، 127 00:10:48,470 --> 00:10:55,470 نود أن نفعل أولا المفضلة. 128 00:10:55,620 --> 00:11:06,380 findByID، لذلك لأننا فقط جعل التغييرات سوف نقول favorite_id 129 00:11:07,740 --> 00:11:15,325 ونحن سوف 130 00:11:15,325 --> 00:11:25,490 ملء كل من المستخدم وأيضا ملء الأطباق في المفضلة. 131 00:11:25,740 --> 00:11:32,420 ثم عندما يتم إرجاع المفضلة، 132 00:11:32,610 --> 00:11:36,940 سنقوم بإرجاع تلك المفضلة بدلا من ذلك. 133 00:11:36,940 --> 00:11:40,440 لذلك، اسمحوا لي أن أجري هذا التغيير هنا. 134 00:11:40,440 --> 00:11:46,910 لذلك، سوف نقطع هذا من هنا ومن ثم داخل ذلك الحين، 135 00:11:46,910 --> 00:11:49,645 سنعيد المفضلة. 136 00:11:49,645 --> 00:11:53,510 بعد أن نقوم بحفظ المفضلة، 137 00:11:53,510 --> 00:11:54,980 ثم سنبحث عنها، 138 00:11:54,980 --> 00:11:58,285 عن FavoriteByID ثم نعيد 139 00:11:58,285 --> 00:12:03,940 تلك المفضلة هنا لذلك سنقول ثم العودة المفضلة ورمز الحالة. 140 00:12:03,940 --> 00:12:05,355 هذا التغيير الذي يجب أن نقوم به. 141 00:12:05,355 --> 00:12:08,180 إذا كنت قد نفذت هذا بالفعل في المفضلة لديك، 142 00:12:08,180 --> 00:12:09,760 ثم لا تحتاج إلى إجراء هذا التغيير. 143 00:12:09,760 --> 00:12:13,310 ولكن ما نقوم به هو كلما نجري تغييرات على المفضلة، 144 00:12:13,310 --> 00:12:17,380 سنقوم بملء كل من معلومات المستخدم والأطباق ثم إرجاع هذه القيمة 145 00:12:17,380 --> 00:12:22,360 لأن عميل React يتوقع أن يكون هناك. 146 00:12:22,360 --> 00:12:24,685 الآن، نفس النوع من التغيير، 147 00:12:24,685 --> 00:12:28,350 سنحتاج إلى إجراء متغير ب، حفظ التغييرات. 148 00:12:28,350 --> 00:12:33,125 حتى في آخر هنا، 149 00:12:33,125 --> 00:12:36,090 سنقوم بإجراء تغيير على ذلك، 150 00:12:36,090 --> 00:12:42,705 لذلك سنقول favorites.save وبعد ذلك سوف نفعل favorites.findbyid وجعل هذا التغيير. 151 00:12:42,705 --> 00:12:45,210 وبالمثل، تحت معرف الطبق، 152 00:12:45,210 --> 00:12:47,095 أيضا في آخر، 153 00:12:47,095 --> 00:12:51,070 سوف تكون بالمثل، كلما قمت بإجراء تغييرات على المفضلة، 154 00:12:51,070 --> 00:12:57,715 وسوف ننظر أولا لذلك ومن ثم ملء كل من المستخدم والأطباق ومن ثم إعادته، ومن 155 00:12:57,715 --> 00:12:59,910 ثم وبالمثل في الجزء الآخر. 156 00:12:59,910 --> 00:13:06,290 لذلك، يجب أن تكون قد نفذت هذا في مهمتك الرابعة. 157 00:13:06,290 --> 00:13:09,010 لذلك، قم بإجراء هذا التغيير الإضافي حيث ستقوم 158 00:13:09,010 --> 00:13:12,350 بملء المستخدم والأطباق قبل إرجاع القيمة. 159 00:13:12,350 --> 00:13:14,685 أيضا مع الحذف، 160 00:13:14,685 --> 00:13:17,385 سنقوم بنفس التغييرات هنا. 161 00:13:17,385 --> 00:13:19,890 لذلك، لاحظت أنه في الحذف، 162 00:13:19,890 --> 00:13:21,830 لقد قمت بالفعل بإجراء هذا التغيير هنا. 163 00:13:21,830 --> 00:13:27,085 لذلك، بعد حفظ التغييرات على المفضلة، 164 00:13:27,085 --> 00:13:29,480 سنقوم ثم البحث عن المفضلة ومن ثم 165 00:13:29,480 --> 00:13:33,465 العودة بعد ملء كل من المستخدم والأطباق والمفضلة. 166 00:13:33,465 --> 00:13:36,505 هذا ما يتوقع منا عميلنا React القيام به. 167 00:13:36,505 --> 00:13:38,145 لذلك، حتى بالنسبة للحذف، 168 00:13:38,145 --> 00:13:39,995 سنقوم بنفس التغييرات. 169 00:13:39,995 --> 00:13:44,115 الآن، مع هذا، يتم تحديث جهاز التوجيه المفضل لدي 170 00:13:44,115 --> 00:13:48,575 لذلك سنمضي قدما لتحديث users.js المقبل. 171 00:13:48,575 --> 00:13:52,370 وأخيرا، سنقوم بتحديث ملف users.js. 172 00:13:52,370 --> 00:13:57,060 الآن، في ملف users.js نحن بحاجة إلى إضافة في 173 00:13:57,060 --> 00:14:05,245 مجال router.options آخر هنا، 174 00:14:05,245 --> 00:14:10,610 لأنه في بعض الأحيان طلب آخر كما رأيت 175 00:14:10,610 --> 00:14:16,315 مع تسجيل الدخول سوف ترسل الخيارات أولا للتحقق، 176 00:14:16,315 --> 00:14:21,610 وخاصة مع السيارات، ما إذا كان سيتم السماح بطلب آخر. 177 00:14:21,610 --> 00:14:30,080 لذلك هذا هو السبب في أننا سوف تحقق بالطبع مع الخيارات هنا وبعد ذلك 178 00:14:31,860 --> 00:14:35,450 سنقوم ببساطة بإرجاع 179 00:14:39,960 --> 00:14:43,045 رسالة 180 00:14:43,045 --> 00:14:46,180 حالة 200 ردا على ذلك. 181 00:14:46,180 --> 00:14:52,960 لأي نقطة نهاية تحت المستخدمين إذا تلقينا الخيارات، 182 00:14:52,960 --> 00:14:56,530 سنقوم ببساطة بإرجاع حالة 200 هنا. 183 00:14:56,530 --> 00:15:03,580 الآن وظيفة تسجيل الدخول التي قمنا بتنفيذها في وقت سابق، 184 00:15:03,580 --> 00:15:07,470 كنا قد فعلت ببساطة passport.authenticate 185 00:15:07,470 --> 00:15:12,930 المحلية هنا وفحصنا عن القيم المتبقية هنا. 186 00:15:12,930 --> 00:15:15,215 الآن، هذا passport.authenticate المحلية، 187 00:15:15,215 --> 00:15:17,600 إذا لم يتم مصادقة المستخدم، 188 00:15:17,600 --> 00:15:21,800 فإنه ببساطة إرجاع غير مصرح به في رسالة الرد. 189 00:15:21,800 --> 00:15:28,380 الآن قد لا يكون ذلك مفيدًا جدًا لجانب العميل لعرض هذه المعلومات، 190 00:15:28,380 --> 00:15:30,480 ولهذا السبب سنقوم بتحسين 191 00:15:30,480 --> 00:15:36,310 طريقة تسجيل الدخول إلى جهاز التوجيه 192 00:15:36,310 --> 00:15:41,765 هذه بحيث تقوم المصادقة بإرجاع معلومات أكثر أهمية في هذه المرحلة. 193 00:15:41,765 --> 00:15:43,210 لذلك للقيام بذلك، 194 00:15:43,210 --> 00:15:49,395 ونحن لن يكون القيام passport.authenticate هنا، 195 00:15:49,395 --> 00:15:51,955 بدلا من ذلك سوف نأخذ. 196 00:15:51,955 --> 00:15:55,140 لذلك، اسمحوا لي إزالة ذلك من هناك وبعد ذلك سترى 197 00:15:55,140 --> 00:15:58,930 كيف سوف تحديث وظيفة جهاز التوجيه هنا. 198 00:15:58,930 --> 00:16:08,620 لذلك، سنرى بالطبع مع الخيارات وبعد ذلك سنقوم بتضمين req، 199 00:16:08,620 --> 00:16:12,160 الدقة والقادم هنا. 200 00:16:12,160 --> 00:16:16,885 داخل هذا req، res والقادم هنا، 201 00:16:16,885 --> 00:16:27,954 سوف passport.authenticate استدعاء هذا مع المحلية. 202 00:16:27,954 --> 00:16:31,210 الآن، عندما نسمي هذا مع المحلي، في 203 00:16:31,210 --> 00:16:34,970 حالة حدوث خطأ 204 00:16:34,970 --> 00:16:38,240 في المصادقة، يمكن إجراء passport.authenticate لإرجاع 205 00:16:38,240 --> 00:16:44,230 قيمة الخطأ، كما أنه سيعيد المستخدم إذا 206 00:16:44,230 --> 00:16:48,960 لم يكن هناك خطأ ومعلمة ثالثة تسمى المعلومات 207 00:16:48,960 --> 00:16:54,000 التي ستحمل معلومات إضافية قد يتم تحليلها مرة أخرى إلى المستخدم. 208 00:16:54,000 --> 00:16:56,580 سيتم إرجاع هذا الخطأ عند وجود 209 00:16:56,580 --> 00:16:59,950 خطأ حقيقي يحدث في passport.authenticate. 210 00:16:59,950 --> 00:17:03,400 ولكن إذا 211 00:17:03,400 --> 00:17:07,645 تم إرسال معلومات المستخدم إلى passport.authenticate ولكن المستخدم غير موجود، 212 00:17:07,645 --> 00:17:10,490 فإن ذلك لا يتم حسابه كخطأ. 213 00:17:10,490 --> 00:17:14,690 بدلاً من ذلك، سيتم حسابها نظرًا لأن المستخدم غير موجود 214 00:17:14,690 --> 00:17:19,305 ويتم تحليل هذه المعلومات مرة أخرى في كائن المعلومات الذي يأتي. 215 00:17:19,305 --> 00:17:21,500 لذلك، سيتم إرجاع الخطأ عندما يكون هناك 216 00:17:21,500 --> 00:17:24,925 خطأ حقيقي يحدث أثناء عملية المصادقة، 217 00:17:24,925 --> 00:17:30,820 ولكن المعلومات سوف تحتوي على معلومات إذا كان المستخدم غير موجود. 218 00:17:30,820 --> 00:17:36,920 لذلك، يقوم passport.authenticate بتمرير رسالة تفيد بأن 219 00:17:36,920 --> 00:17:39,575 المستخدم غير موجود أو إما أن اسم المستخدم 220 00:17:39,575 --> 00:17:42,850 غير صحيح أو كلمة المرور غير صحيحة وهكذا. 221 00:17:42,850 --> 00:17:46,870 لذلك، سيتم تمرير هذه المعلومات في رسالة المعلومات. 222 00:17:46,870 --> 00:17:49,230 الآن سنرى كيف يكون هذا مفيدًا 223 00:17:49,230 --> 00:17:52,060 لنا عندما ننظر إلى جانب العميل في وقت لاحق قليلاً. 224 00:17:52,060 --> 00:17:55,400 لذلك، في هذه الحالة، 225 00:17:55,400 --> 00:18:01,455 سوف نتعامل مع هذا على النحو التالي، 226 00:18:01,455 --> 00:18:06,810 وليس فقط أنه عندما نسمي هذا passport.authenticate، 227 00:18:06,810 --> 00:18:10,220 نحن بحاجة أيضا إلى تمرير في 228 00:18:10,220 --> 00:18:15,080 req، الدقة، بعد المعلمات الثلاثة لذلك. 229 00:18:15,080 --> 00:18:20,130 لذا، هذا هو الهيكل عندما تحتاج إلى استدعاء passport.authenticate ونتوقع منه أن 230 00:18:20,130 --> 00:18:25,270 يمرر لك معلومات مثل هذه كطريقة رد الاتصال هنا، 231 00:18:25,270 --> 00:18:27,630 لذلك تحتاج أيضًا إلى توفير هذا req، res، 232 00:18:27,630 --> 00:18:30,250 التالي هناك أيضًا. 233 00:18:30,250 --> 00:18:32,270 الآن، إذا حدث هذا، 234 00:18:32,270 --> 00:18:36,780 لذلك سنقول إذا كان خطأ، 235 00:18:36,780 --> 00:18:40,425 لذلك إذا كان هناك خطأ الذي يحدث، 236 00:18:40,425 --> 00:18:45,395 سنقول العودة الخطأ التالي ثم السماح 237 00:18:45,395 --> 00:18:51,480 معالج الخطأ من جهاز التوجيه السريع لدينا ورعاية ذلك. 238 00:18:51,480 --> 00:18:56,755 الآن، سننظر في حالات أخرى، إن لم يكن المستخدم. 239 00:18:56,755 --> 00:18:59,630 لذا، إذا وصلنا إلى هذه النقطة، 240 00:18:59,630 --> 00:19:02,580 فهذا يعني أنه لم يكن خطأ حدث 241 00:19:02,580 --> 00:19:05,615 ولكن بدلاً من ذلك ربما لا يمكن العثور على المستخدم. 242 00:19:05,615 --> 00:19:07,100 إذا لم يتم العثور على المستخدم، 243 00:19:07,100 --> 00:19:11,190 ثم سيتم تعيين المستخدم هنا إلى فارغة في هذه الحالة. 244 00:19:11,190 --> 00:19:14,634 لذلك، في هذه الحالة، 245 00:19:14,634 --> 00:19:17,375 إذا كان المستخدم غير موجود، 246 00:19:17,375 --> 00:19:23,680 ثم نحن بحاجة إلى أن تكون قادرة على تمرير المعلومات مرة أخرى إلى جانب الخادم. 247 00:19:23,680 --> 00:19:28,435 لذلك، ما سنفعله هو أننا سوف تمر في هذه المعلومات في هذا الشكل. 248 00:19:28,435 --> 00:19:32,020 لذلك، أنا ذاهب لقطع هذا خارج من هنا 249 00:19:32,020 --> 00:19:36,640 ومن ثم لصقه في هنا وبعد ذلك سوف نقوم بتحرير هذا. 250 00:19:36,640 --> 00:19:40,704 لذلك، إذا كان المستخدم فارغًا، 251 00:19:40,704 --> 00:19:45,830 فسنرسل رمز الحالة كـ 401 مما يعني 252 00:19:45,830 --> 00:19:53,975 غير مصرح به ثم سنرسل معلومات نجاح كاذبة، 253 00:19:53,975 --> 00:19:57,405 ومن ثم لن نقوم بتمرير الرمز المميز مرة أخرى، 254 00:19:57,405 --> 00:20:00,795 سنقوم بتمرير رسالة الحالة مرة أخرى. 255 00:20:00,795 --> 00:20:03,135 لذلك، هنا سوف نقول 256 00:20:03,135 --> 00:20:12,670 «تسجيل الدخول غير ناجحة» ثم المعلومات الثالثة، 257 00:20:12,670 --> 00:20:18,070 ونحن سوف تمر هذه المعلومات أن الكائن الذي تلقيناه هنا 258 00:20:18,070 --> 00:20:25,635 كجزء ثالث في رسالة الرد التي نرسل مرة أخرى من الخادم لدينا هنا. 259 00:20:25,635 --> 00:20:28,935 لذلك، سيتم تعيين علامة النجاح إلى false، 260 00:20:28,935 --> 00:20:32,385 سيتم تعيين الحالة تسجيل الدخول غير ناجحة وسيتم تمرير 261 00:20:32,385 --> 00:20:36,725 معلومات الخطأ التي يتم تمريرها في المعلومات مرة أخرى. 262 00:20:36,725 --> 00:20:39,855 الآن، لاحظ أن هذا الموقف سيحدث إذا كان 263 00:20:39,855 --> 00:20:43,125 اسم المستخدم وكلمة المرور غير صحيحة، 264 00:20:43,125 --> 00:20:48,600 وبالتالي هذا ليس خطأ بمعنى الخطأ ولكن حقيقة أن 265 00:20:48,600 --> 00:20:54,040 المصادقة لا يمكن العثور على المستخدم أو كلمة مرور المستخدم غير صحيحة. 266 00:20:54,040 --> 00:20:58,530 لذلك، سيتم ترميز هذه المعلومات في المعلومات التي تأتي، وحتى أنني سوف 267 00:20:58,530 --> 00:21:09,615 تمر مرة أخرى كخطأ إلى جانب العميل الخاص بي. 268 00:21:09,615 --> 00:21:15,355 يتم التعامل مع الجزء خلاف ذلك كما Req.Login. 269 00:21:15,355 --> 00:21:17,220 لذلك، إذا كان هذا ناجحا، 270 00:21:17,220 --> 00:21:22,710 passport.authenticate سنقوم بإضافة هذه الطريقة تسمى Req.login للمستخدم. 271 00:21:22,710 --> 00:21:24,340 لذلك، في هذه المرحلة، 272 00:21:24,340 --> 00:21:27,950 سنقوم ببساطة بتمرير كائن المستخدم الذي حصلنا عليه. 273 00:21:27,950 --> 00:21:31,055 حتى هنا، إذا وصلنا إلى هذه النقطة، 274 00:21:31,055 --> 00:21:36,195 ثم وهذا يعني أن كائن المستخدم ليست فارغة وأيضا لم يحدث خطأ، 275 00:21:36,195 --> 00:21:40,090 وهذا يعني أن المستخدم يمكن تسجيل الدخول. 276 00:21:41,080 --> 00:21:44,550 لذلك، سنقول خطأ، 277 00:21:48,960 --> 00:21:51,460 سنحاول تسجيل الدخول إلى المستخدم. 278 00:21:51,460 --> 00:21:58,000 لذلك، سوف نقول إذا كان خطأ 279 00:21:58,000 --> 00:22:05,345 وبعد ذلك سوف نمر مرة أخرى نفس النوع من معلومات الخطأ التي فعلناها هنا. 280 00:22:05,345 --> 00:22:09,840 حتى في هذه الحالة، إذا كان خطأ، 281 00:22:13,290 --> 00:22:19,430 ثم سنقوم بتمرير رمز الحالة كما 401 وسنقول النجاح 282 00:22:19,430 --> 00:22:25,125 هو خطأ وحالة تسجيل الدخول غير ناجحة، 283 00:22:25,125 --> 00:22:28,340 ثم معلومات الخطأ، 284 00:22:29,280 --> 00:22:31,840 بدلا من المعلومات، 285 00:22:31,840 --> 00:22:42,380 ونحن سوف تمر في «تعذر تسجيل الدخول المستخدم». 286 00:22:42,380 --> 00:22:48,960 لذلك، هذه هي الرسالة التي سنمررها مرة أخرى هنا إذا حدث الخطأ. 287 00:22:48,960 --> 00:22:53,200 وإلا، سنكون أسفل هنا. 288 00:22:53,200 --> 00:22:55,960 لذلك، في هذه المرحلة، 289 00:22:55,960 --> 00:22:59,440 سنكون قادرين على توليد الرمز المميز. 290 00:22:59,440 --> 00:23:02,495 لذا، إذا وصلنا إلى هذه النقطة، 291 00:23:02,495 --> 00:23:06,370 فهذا يعني أن المستخدم قد قام بتسجيل الدخول بنجاح، 292 00:23:06,370 --> 00:23:08,430 وبالتالي يمكننا الآن إنشاء الرمز المميز. 293 00:23:08,430 --> 00:23:12,705 لذلك، سنقوم بإنشاء الرمز المميز استنادًا إلى معرف المستخدم، 294 00:23:12,705 --> 00:23:18,350 ثم سنقوم بتمرير الرمز المميز مرة أخرى إلى المستخدم. 295 00:23:18,350 --> 00:23:21,635 لذلك، هنا، سوف نقول رمز فار، 296 00:23:21,635 --> 00:23:30,730 وبعد ذلك يمكننا أن نقول res.StatusCode هو 200 ثم نجاح res.json صحيح، 297 00:23:30,730 --> 00:23:33,600 لذلك، مما يعني أن المستخدم قام بتسجيل الدخول بنجاح. 298 00:23:33,600 --> 00:23:38,490 لذلك، فإن الحالة ستكون تسجيل الدخول ناجحة. 299 00:23:38,490 --> 00:23:40,605 ثم، الجزء الثالث، 300 00:23:40,605 --> 00:23:42,360 بدلا من الخطأ، 301 00:23:42,360 --> 00:23:46,200 وسوف تمرير الرمز مرة أخرى إلى المستخدم. 302 00:23:46,200 --> 00:23:48,760 لذلك، سوف نقول رمزية، 303 00:23:51,100 --> 00:23:54,675 وهذا الرمز الذي حصلنا عليه للتو في وقت سابق. 304 00:23:54,675 --> 00:24:01,030 لذلك، سيتم تمرير هذا الرمز المميز كخاصية رمزية لرسالة الرد. 305 00:24:01,030 --> 00:24:04,560 لذلك، هنا، لاحظ أن يتم تعيين النجاح إلى true، لذلك، 306 00:24:04,560 --> 00:24:08,340 مما يعني أن المستخدم تسجيل الدخول بنجاح، 307 00:24:08,340 --> 00:24:12,290 وبالتالي يمكن للمستخدم المضي قدما في هذه المرحلة. 308 00:24:12,290 --> 00:24:19,050 يجب القيام بذلك داخل Req.Login هنا. 309 00:24:19,820 --> 00:24:22,970 لذلك، في هذه المرحلة، 310 00:24:22,970 --> 00:24:27,180 سنقوم بإغلاق Req.Login. 311 00:24:27,180 --> 00:24:33,735 لذلك، لاحظ أن هذا هو داخل هذا req.Login هنا. 312 00:24:33,735 --> 00:24:37,320 لذلك، في هناك، ونحن سوف تمر هذه الثلاثة مرة أخرى. 313 00:24:37,320 --> 00:24:41,370 لذلك، اسمحوا لي فقط المسافة البادئة هذه الأسطر الثلاثة في. 314 00:24:41,720 --> 00:24:48,850 لذا، هذه هي الطريقة التي سنتعامل بها مع طريقة تسجيل المستخدم. 315 00:24:48,850 --> 00:24:52,230 لذلك، مرة أخرى، مراجعة هذا الرمز مرة أخرى. 316 00:24:52,230 --> 00:24:53,950 لذلك، سنقوم بعمل وظيفة جهاز التوجيه، 317 00:24:53,950 --> 00:24:56,815 ولكن بدلاً من القيام بمصادقة جواز السفر هناك، 318 00:24:56,815 --> 00:24:58,960 سنقول req، res 319 00:24:58,960 --> 00:25:01,240 ، التالي، ثم في الداخل هنا، 320 00:25:01,240 --> 00:25:04,285 سنقوم بإجراء مصادقة جواز سفر للمحلي، 321 00:25:04,285 --> 00:25:06,560 وسوف تمر هذه المصادقة مرة أخرى. 322 00:25:06,560 --> 00:25:09,250 لذلك، يمكننا توفير وظيفة رد اتصال لذلك، 323 00:25:09,250 --> 00:25:11,810 وستعود وظيفة رد الاتصال هذه إما الخطأ، أو 324 00:25:11,810 --> 00:25:14,730 المستخدم، أو المعلومات هنا. 325 00:25:14,730 --> 00:25:16,300 لذلك، إذا كان خطأ، 326 00:25:16,300 --> 00:25:20,735 ونحن سوف تسمح فقط معالج الخطأ صريحة لرعاية ذلك. 327 00:25:20,735 --> 00:25:22,730 إذا كان المستخدم فارغًا، 328 00:25:22,730 --> 00:25:26,940 فهذا يعني أن تسجيل دخول المستخدم لم يكن ناجحًا، 329 00:25:26,940 --> 00:25:29,730 وسيكون السبب في ذلك في المعلومات. 330 00:25:29,730 --> 00:25:36,870 لذلك، سيتم تمرير ذلك كخطأ المعلومات في رسالة الرد هنا. 331 00:25:36,870 --> 00:25:38,790 إذا وصلنا إلى هذه النقطة، 332 00:25:38,790 --> 00:25:43,555 ثم يتم التحقق من المستخدم بنجاح. 333 00:25:43,555 --> 00:25:45,400 لذلك، ثم سنقوم بتسجيل الدخول للمستخدم. 334 00:25:45,400 --> 00:25:47,630 لذا، مصادقة جواز السفر، 335 00:25:47,630 --> 00:25:53,385 سنضيف في هذه الطريقة تسمى تسجيل الدخول إلى req، رسالة الطلب. 336 00:25:53,385 --> 00:25:56,770 لذلك، يمكننا استدعاء تسجيل الدخول مع المستخدم. 337 00:25:56,770 --> 00:25:59,355 إذا كان هذا إرجاع خطأ، 338 00:25:59,355 --> 00:26:03,105 ثم سنقوم بإرجاع الخطأ هنا بشكل مناسب. 339 00:26:03,105 --> 00:26:08,590 إذا لم يكن الأمر كذلك، فسنكون قد وصلنا إلى النقطة التي يتم فيها مصادقة المستخدم بنجاح. 340 00:26:08,590 --> 00:26:12,630 لذلك، يمكننا إنشاء JSON Web Token هنا ثم إرجاع رمز 341 00:26:12,630 --> 00:26:18,315 JSON Web Token إلى المستخدم للتأكد من تسجيل دخول المستخدم بنجاح. 342 00:26:18,315 --> 00:26:21,545 إذن، هذه هي مجموعة الخطوات التي سنستخدمها هنا. 343 00:26:21,545 --> 00:26:25,735 الآن، السبب في أنني أفعل طريقة أكثر تفصيلاً للتعامل معها هو 344 00:26:25,735 --> 00:26:30,035 أنني أريد التمييز بين الوضع الذي 345 00:26:30,035 --> 00:26:34,170 يحدث فيه خطأ حقيقي أثناء عملية المصادقة بدلاً من الوضع الذي 346 00:26:34,170 --> 00:26:39,095 يكون فيه اسم المستخدم غير صالح أو كلمة المرور غير صالحة. 347 00:26:39,095 --> 00:26:42,860 لذلك، سيتم التعامل مع هاتين الحالتين من خلال هذا الوضع، 348 00:26:42,860 --> 00:26:46,550 حيث المعلومات سوف تحمل المعلومات مرة أخرى لنا. 349 00:26:46,550 --> 00:26:48,900 لذلك، هذا ليس خطأ في حد ذاته، 350 00:26:48,900 --> 00:26:52,090 ولكن هذا هو الوضع حيث المستخدم 351 00:26:52,090 --> 00:26:55,710 ليس مستخدمًا صالحًا أو كلمة مرور المستخدم غير صالحة. 352 00:26:55,710 --> 00:27:01,070 لذا، هذه هي الطريقة التي سنتعامل بها مع عملية تسجيل الدخول الخاصة بالمستخدم. 353 00:27:01,070 --> 00:27:03,660 بالإضافة إلى ذلك، سأضيف 354 00:27:03,660 --> 00:27:14,825 طريقة واحدة أخرى هنا تسمى CheckJwtToken. 355 00:27:14,825 --> 00:27:21,100 من الممكن تمامًا أنه في حين قام العميل بتسجيل الدخول والحصول على رمز JSON Web Token، في 356 00:27:21,100 --> 00:27:24,855 وقت لاحق، قد تنتهي صلاحية JSON Web Token. 357 00:27:24,855 --> 00:27:32,840 لذا، إذا حاول المستخدم الوصول من جانب العميل باستخدام رمز مميز منتهي الصلاحية 358 00:27:32,840 --> 00:27:35,610 إلى الخادم، فلن يتمكن الخادم من مصادقة المستخدم. 359 00:27:35,610 --> 00:27:37,780 لذلك، على فترات دورية، 360 00:27:37,780 --> 00:27:42,180 قد نرغب في التحقق للتأكد من أن رمز JSON Web Token لا يزال صالحًا. 361 00:27:42,180 --> 00:27:44,975 لذلك، هذا هو السبب في أنني بما في ذلك هذا، 362 00:27:44,975 --> 00:27:49,620 نقطة نهاية أخرى تسمى CheckJwtToken. 363 00:27:49,620 --> 00:27:53,155 لذا، إذا قمت بالوصول إلى CheckJwtToken عن طريق 364 00:27:53,155 --> 00:27:58,700 تضمين الرمز المميز في رأس التفويض، 365 00:27:58,700 --> 00:28:02,490 فستعود هذه المكالمة إلى true أو false 366 00:28:02,490 --> 00:28:06,535 للإشارة إليك إلى ما إذا كان JSON Web Token لا يزال صالحًا أم لا. 367 00:28:06,535 --> 00:28:10,930 إذا لم يكن صالحًا، فيمكن لجانب العميل بدء تسجيل دخول آخر 368 00:28:10,930 --> 00:28:15,945 للمستخدم للحصول على JSON Web Token الجديد إذا لزم الأمر. 369 00:28:15,945 --> 00:28:17,285 لذلك، للقيام بذلك، 370 00:28:17,285 --> 00:28:27,109 سنقول Cors.CorsWithOptions و req، 371 00:28:27,109 --> 00:28:31,385 الدقة هنا كما هو متوقع. 372 00:28:31,385 --> 00:28:35,670 هنا، سنقول 373 00:28:39,820 --> 00:28:49,360 جواز السفر مصادقة jwt 374 00:28:49,360 --> 00:28:57,150 والجلسة: false، 375 00:29:00,020 --> 00:29:07,270 وهذا من شأنه أن يعود err، المستخدم، المعلومات. 376 00:29:09,020 --> 00:29:13,770 لذلك، تذكر كيف نستخدم مصادقة جواز السفر في وقت سابق. 377 00:29:13,770 --> 00:29:17,195 لذلك، نحن ندعو جوت مع جلسة كاذبة هنا. 378 00:29:17,195 --> 00:29:21,745 لذلك، في وقت سابق هنا، نقول جواز السفر المصادقة المحلية. 379 00:29:21,745 --> 00:29:23,535 لذلك، هذا هو للمصادقة المحلية. 380 00:29:23,535 --> 00:29:27,330 لذلك، هذا هو لمصادقة JSON Web Token. 381 00:29:27,330 --> 00:29:29,430 لذلك، عندما نسمي ذلك، 382 00:29:29,430 --> 00:29:33,435 فنظرًا لأن ذلك سيتحقق من رمز JSON Web Token، لذا سنقول 383 00:29:33,435 --> 00:29:40,335 ، إذا أرجع الخطأ التالي، 384 00:29:40,335 --> 00:29:44,895 ثم دع معالج الخطأ السريع يعتني بهذا الوضع. 385 00:29:44,895 --> 00:29:50,469 ثم، سنقول، إن لم يكن المستخدم، 386 00:29:53,330 --> 00:30:00,330 إذا كان المستخدم غير موجود، ثم وبالمثل آخر. 387 00:30:00,330 --> 00:30:03,510 لذا، مما يعني أنه إذا تم 388 00:30:03,510 --> 00:30:07,810 العثور على كائن المستخدم من JSON Web Token ثم تم تحميله على 389 00:30:07,810 --> 00:30:11,400 req.user، فهذا يعني أن المستخدم مستخدم صالح، 390 00:30:11,400 --> 00:30:13,485 وبالتالي يمكن السماح له بالمضي قدما. 391 00:30:13,485 --> 00:30:20,330 خلاف ذلك، سنقول أن المستخدم غير موجود. 392 00:30:20,330 --> 00:30:24,995 لذلك، نحن بحاجة إلى إبلاغ أن JSON Web Token قد انتهت صلاحيتها. 393 00:30:24,995 --> 00:30:26,180 لذلك، في هذه المرحلة، 394 00:30:26,180 --> 00:30:29,090 سنرسل دقة 395 00:30:29,090 --> 00:30:36,545 مع رمز الحالة 401. 396 00:30:36,545 --> 00:30:47,130 لذلك، غير مصرح به، سيثيادر، نوع المحتوى، 397 00:30:49,900 --> 00:30:56,280 التطبيق/جسون، وبعد ذلك سنعود الدقة. 398 00:30:58,680 --> 00:31:13,750 سيقول Res.json حالة JWT 399 00:31:13,750 --> 00:31:17,090 غير صالحة، وبعد ذلك، 400 00:31:17,730 --> 00:31:23,690 سنقوم بإرجاع علامة تسمى سقوط النجاح، وبعد ذلك، 401 00:31:23,880 --> 00:31:29,080 سنقوم بإرجاع المعلومات التي نحصل عليها إذا 402 00:31:29,080 --> 00:31:34,460 لم يتم مصادقة المستخدم كخطأ في هذه المرحلة. 403 00:31:36,420 --> 00:31:40,480 خلاف ذلك، وهذا يعني أننا وصلنا إلى هذه النقطة، 404 00:31:40,480 --> 00:31:43,220 ثم المستخدم هو مستخدم صالح. 405 00:31:43,220 --> 00:31:44,850 لذلك، في هذه الحالة، 406 00:31:44,850 --> 00:31:47,230 اسمحوا لي فقط نسخ هذا الرمز هنا، 407 00:31:47,230 --> 00:31:54,070 ونحن سوف ترسل رمز الحالة من 200 ثم res.json، 408 00:31:54,070 --> 00:32:02,720 وسوف ترسل جوت صالحة وناجحة كونها صحيحة. 409 00:32:02,940 --> 00:32:09,820 الجزء الثالث، سوف نرسل معلومات المستخدم. 410 00:32:09,820 --> 00:32:16,000 وبهذه الطريقة، عندما يتم استدعاء نقطة النهاية هذه باستخدام طريقة get، 411 00:32:16,000 --> 00:32:19,170 فسيتحقق هذا مما إذا كان الرمز المميز صالحًا أم لا. 412 00:32:19,170 --> 00:32:20,220 إذا كان الرمز المميز صالحًا، 413 00:32:20,220 --> 00:32:24,020 فستتلقى هذا الرد ومن علامة النجاح في الرد، 414 00:32:24,020 --> 00:32:27,770 يمكنك التحقق لمعرفة ما إذا كان jsonwebtoken صالحًا أم لا. 415 00:32:27,770 --> 00:32:32,155 هذا مفيد على جانب العميل. 416 00:32:32,155 --> 00:32:37,825 الآن، هذا جواز السفر المصادقة هنا يجب أن يتم توفيره 417 00:32:37,825 --> 00:32:43,790 مع req و res كمعلمتين هنا. 418 00:32:43,790 --> 00:32:47,630 لذا، هذه هي الطريقة التي نسميها جواز السفر المصادقة. 419 00:32:47,630 --> 00:32:49,355 لذا، لاحظ أنه كلما اتصلت 420 00:32:49,355 --> 00:32:52,840 بمصادقة جواز السفر وتتوقع وظيفة رد الاتصال هذه هنا، 421 00:32:52,840 --> 00:33:01,825 تحتاج إلى إلحاق هذه النقطة req.res بمصادقة جواز السفر في الخلف هنا. 422 00:33:01,825 --> 00:33:03,890 في خادم واجهة برمجة التطبيقات الخاص بنا، 423 00:33:03,890 --> 00:33:07,490 قمنا بتنفيذ تعليقاتنا بطريقة 424 00:33:07,490 --> 00:33:12,245 شكلت التعليقات مستندات فرعية داخل وثيقة ديش، 425 00:33:12,245 --> 00:33:16,540 لذلك يشترون كل طبق مغلق مجموعة التعليقات الخاصة به. 426 00:33:16,540 --> 00:33:19,520 ولكن الطريقة التي نفذنا بها عميل React هو 427 00:33:19,520 --> 00:33:22,965 أن التعليقات تبقى مستقلة عن الأطباق، 428 00:33:22,965 --> 00:33:27,680 والتعليقات نفسها تحمل معرف الطبق المقابل. 429 00:33:27,680 --> 00:33:30,400 الآن، هذه طريقتان مختلفتان 430 00:33:30,400 --> 00:33:34,445 لتنفيذ جانب الخادم بالإضافة إلى جانب العميل. 431 00:33:34,445 --> 00:33:39,685 في تطبيق Angular الذي يتم تنفيذه في تخصصنا Angular، 432 00:33:39,685 --> 00:33:43,470 استخدمنا طريقة المستند الفرعي 433 00:33:43,470 --> 00:33:47,560 للتعامل مع التعليقات في تطبيق عميل Angular الخاص بنا. 434 00:33:47,560 --> 00:33:50,050 لذا، تم 435 00:33:50,050 --> 00:33:54,090 تنفيذ خادم واجهة برمجة التطبيقات الباقي بطريقة كانت أكثر ملاءمة للعميل Angular. 436 00:33:54,090 --> 00:34:00,600 ولكن بالنسبة لعملاء React نظرًا لأننا أبقينا التعليقات مستقلة 437 00:34:00,600 --> 00:34:03,985 عن الأطباق، ثم استخدم معرف الطبق داخل التعليق، 438 00:34:03,985 --> 00:34:09,300 لذلك نحتاج إلى إعادة هيكلة خادم واجهة برمجة التطبيقات 439 00:34:09,300 --> 00:34:16,835 الخاص بنا، بحيث يكون لدينا نقطة نهاية تعليق منفصلة مستقلة عن نقطة نهاية الأطباق. 440 00:34:16,835 --> 00:34:22,310 لذلك، نحن بحاجة إلى إعادة هيكلة التعليمات البرمجية لدينا في الخادم 441 00:34:22,310 --> 00:34:29,140 لتقديم /التعليقات ريست أبي نقطة النهاية في هذه المرحلة. 442 00:34:29,140 --> 00:34:30,600 لذلك، للقيام بذلك، 443 00:34:30,600 --> 00:34:37,540 دعونا نمضي قدما وتنفيذ نموذج جديد يسمى comment.js. 444 00:34:37,540 --> 00:34:39,260 لذلك، الذهاب إلى النماذج، 445 00:34:39,260 --> 00:34:45,790 اسمحوا لي تنفيذ ملف جديد اسمه comments.js. 446 00:34:47,220 --> 00:34:50,015 في ملف comments.js، 447 00:34:50,015 --> 00:34:56,110 سنقوم بنقل التعليقات من ملف dishes.js 448 00:34:56,110 --> 00:35:02,660 إلى ملف comments.js ثم إزالته تمامًا من ملف. dishes.js 449 00:35:02,660 --> 00:35:03,900 ولكن قبل أن نفعل ذلك، 450 00:35:03,900 --> 00:35:08,770 نحن بحاجة إلى نسخ النمس والمخطط من هنا، 451 00:35:08,770 --> 00:35:13,860 لذلك اسمحوا لي فقط نسخ هذا من dishes.js إلى comment.js. 452 00:35:13,860 --> 00:35:16,590 بعد ذلك، الذهاب إلى dishes.js، 453 00:35:16,590 --> 00:35:21,040 اسمحوا لي أن قطع هذا التعليق تماما من هنا، 454 00:35:21,040 --> 00:35:28,300 لأننا سوف يكون لها هذا بشكل منفصل في نموذج التعليقات هنا. 455 00:35:28,300 --> 00:35:33,070 لذلك، دعونا نقل ذلك إلى نموذج التعليقات ثم لصقه هنا. 456 00:35:33,070 --> 00:35:35,050 ولكن بالطبع هذه ليست كاملة، 457 00:35:35,050 --> 00:35:37,870 ونحن في طريقنا إلى تحديث التعليقات قليلا. 458 00:35:37,870 --> 00:35:39,300 ولكن قبل أن نفعل ذلك، 459 00:35:39,300 --> 00:35:43,455 والعودة إلى ملف dishes.js وفي ملف الأطباق، 460 00:35:43,455 --> 00:35:47,925 ونحن سوف إزالة التعليقات من ديششيما، 461 00:35:47,925 --> 00:35:51,510 لأننا في طريقنا إلى تخزين المحتوى بشكل منفصل عن 462 00:35:51,510 --> 00:35:55,550 الأطباق في هذا الإصدار من خادمنا. 463 00:35:55,550 --> 00:36:00,450 لذلك، هذه هي الطريقة التي سنقوم بتحديث نموذج الأطباق هنا. 464 00:36:00,450 --> 00:36:08,180 لذلك، قمنا بإزالة التعليقات تماما من نموذج الأطباق هنا. 465 00:36:08,180 --> 00:36:10,270 الذهاب إلى نموذج التعليقات، 466 00:36:10,270 --> 00:36:15,355 لذلك نرى الآن أن لدينا التعليقات التي تم تنفيذها هنا. 467 00:36:15,355 --> 00:36:19,525 ولكن بالإضافة إلى ذلك، في التعليقاتSchema، 468 00:36:19,525 --> 00:36:23,330 نحتاج الآن إلى الإشارة بوضوح إلى 469 00:36:23,330 --> 00:36:28,885 الطبق المحدد الذي يكون هذا التعليق التعليق هو التعليق المقابل. 470 00:36:28,885 --> 00:36:30,700 الآن، هذا هو المكان الذي 471 00:36:30,700 --> 00:36:37,435 لدينا السكان النمس 472 00:36:37,435 --> 00:36:41,580 والطريقة التي نخزن بها الكائنات الهويات تأتي لإنقاذنا. 473 00:36:41,580 --> 00:36:45,860 لذلك، سنقوم بتحديث التعليقات قائلا سيكون لدينا التقييم، 474 00:36:45,860 --> 00:36:47,800 والتعليق، والمؤلف هنا. 475 00:36:47,800 --> 00:36:49,110 بالإضافة إلى المؤلف، 476 00:36:49,110 --> 00:36:56,080 وسوف نقدم حقل واحد آخر يسمى الطبق هنا الذي هو من 477 00:36:56,080 --> 00:37:05,540 نوع: mongoose.مخطط types. Objectid، 478 00:37:06,390 --> 00:37:19,870 وهكذا هذا سوف يشير إلى طبق هنا. 479 00:37:19,870 --> 00:37:29,060 لذلك، سيكون هذا إشارة كائن إلى نموذج الطبق هنا، 480 00:37:29,060 --> 00:37:32,255 وهكذا مع هذا التعديل الآن 481 00:37:32,255 --> 00:37:36,640 سوف تحتوي تعليقاتنا على حقل التصنيف، حقل التعليق، 482 00:37:36,640 --> 00:37:42,355 المؤلف الذي هو مرة أخرى إشارة إلى المستخدم المقابل، 483 00:37:42,355 --> 00:37:47,660 ثم حقل الطبق الذي هو إشارة إلى طبق هنا. 484 00:37:47,660 --> 00:37:50,060 لذلك، مما يعني أننا سنحتاج الآن إلى 485 00:37:50,060 --> 00:37:53,640 ملء التعليقات مع كل من المؤلف ومجال الطبق. 486 00:37:53,640 --> 00:37:55,565 بمجرد الانتهاء من 487 00:37:55,565 --> 00:38:01,585 ذلك، فإننا سوف نقول var التعليقات 488 00:38:01,585 --> 00:38:09,910 mongoose.model وسنسمي هذا «التعليق»، 489 00:38:09,910 --> 00:38:16,765 ومن ثم يستخدم هذا التعليقات التي حددناها للتو هنا، 490 00:38:16,765 --> 00:38:21,970 وبعد ذلك نحن بحاجة إلى تصدير هذا من هنا، 491 00:38:21,970 --> 00:38:25,280 والتعليقات.model من هنا. 492 00:38:25,280 --> 00:38:28,395 لذلك، الآن بعد أن قدمنا التعليقات.model، 493 00:38:28,395 --> 00:38:35,045 ثم سنمضي قدما ثم نقدم جهاز توجيه جديد يسمى المعلق. 494 00:38:35,045 --> 00:38:37,060 لذلك، لإدخال موجه التعليق، 495 00:38:37,060 --> 00:38:39,630 دعونا نذهب إلى المسارات هنا، 496 00:38:39,630 --> 00:38:45,990 ومن ثم إنشاء ملف جديد باسم commentRouter.js. 497 00:38:47,090 --> 00:38:52,415 في commentRouter.js، اسمحوا لي بنسخ بعض الأشياء 498 00:38:52,415 --> 00:38:59,890 من DishRouter. 499 00:38:59,890 --> 00:39:07,720 لذلك، سيكون لدينا هذه التعليقات هنا، 500 00:39:07,720 --> 00:39:14,865 لذلك اسمحوا لي أن نسخ على هذه الأشياء من وأيضا، 501 00:39:14,865 --> 00:39:21,070 بينما أنا في ذلك اسمحوا لي فقط نسخ هذه أيضا حتى تلك النقطة، 502 00:39:21,070 --> 00:39:24,625 وبعد ذلك سوف تحديث ذلك قليلا في وقت لاحق. 503 00:39:24,625 --> 00:39:26,680 لذلك، الذهاب إلى التعليق، 504 00:39:26,680 --> 00:39:28,040 نحن بحاجة إلى كل هذه الأجزاء، 505 00:39:28,040 --> 00:39:33,640 لذلك سنقول كوم، إكسبريس، بوديبارسر، النمس، 506 00:39:33,640 --> 00:39:37,735 المصادقة، كورس، وبعد ذلك سنقوم 507 00:39:37,735 --> 00:39:46,490 باستيراد تعليقات من النماذج/التعليقات. 508 00:39:49,950 --> 00:40:00,460 ثم سنقوم استدعاء هذا كما التعليق الذي هو express.Router هنا. 509 00:40:02,060 --> 00:40:11,950 ثم سنقول CommentRouter استخدام بوديبارسر، 510 00:40:11,950 --> 00:40:17,915 وبعد ذلك سيصبح هذا الآن مسار التعليق. 511 00:40:17,915 --> 00:40:22,030 الآن، نحن بحاجة للذهاب إلى ديشروتر ومن ثم 512 00:40:22,030 --> 00:40:27,200 إزالة جميع الأجزاء التي تشير إلى التعليقات هنا. 513 00:40:27,200 --> 00:40:34,330 لذلك، اسمحوا لي فقط قطع هذا الجزء وبعد ذلك سوف نقوم بإعادة استخدام هذه ل المعلقين لدينا. 514 00:40:34,330 --> 00:40:38,200 لذلك، لم تعد هناك حاجة إلى كل هذه في DishRouter. 515 00:40:38,200 --> 00:40:42,080 لذلك، أنا ذاهب لإزالة كل هذا من DishRouter هنا، 516 00:40:42,080 --> 00:40:43,770 لذلك اسمحوا لي أن قطعها، 517 00:40:43,770 --> 00:40:48,715 كل ما يتعلق مسار التعليقات من DishRouter، 518 00:40:48,715 --> 00:40:50,770 ثم سنذهب إلى التعليق، 519 00:40:50,770 --> 00:40:54,405 ثم اسمحوا لي المضي قدما ولصق ذلك في مكان هنا، 520 00:40:54,405 --> 00:40:57,100 ثم سنقوم بتحرير ذلك هنا. 521 00:40:57,100 --> 00:41:02,660 ثم بعد ذلك، نحن بحاجة إلى تصدير المعلقين. 522 00:41:05,160 --> 00:41:08,205 لذلك، سيتم تصدير المعلقين بالنسبة لنا. 523 00:41:08,205 --> 00:41:12,060 ولكن بالطبع، هذا الرمز ليس دقيقًا تمامًا. 524 00:41:12,060 --> 00:41:14,995 لذلك، نحن بحاجة إلى المضي قدما وإصلاح هذا الرمز هنا. 525 00:41:14,995 --> 00:41:16,585 لذلك، بالنسبة لهذا الرمز، 526 00:41:16,585 --> 00:41:20,180 ندرك الآن أن هذا ليس مسار DishRouter، 527 00:41:20,180 --> 00:41:21,785 بدلاً من ذلك يجب أن يكون 528 00:41:21,785 --> 00:41:27,700 نقطة/النهاية لأننا 529 00:41:27,700 --> 00:41:33,685 سنقوم بتركيب هذا في/التعليقات نقطة النهاية هنا. 530 00:41:33,685 --> 00:41:35,685 لذلك، سنقول CommentRouter، 531 00:41:35,685 --> 00:41:39,859 ثم الخيارات CorsWithOptions ( 532 00:41:39,859 --> 00:41:42,550 req، الدقة) التي لا تزال على هذا النحو هناك، 533 00:41:42,550 --> 00:41:48,429 ثم الحصول على cors.cors ثم req.res، 534 00:41:48,429 --> 00:41:52,460 وبعد ذلك هذا واحد سوف تصبح تعليقات. 535 00:41:53,880 --> 00:41:58,430 ( فيندبيد)، (ريك) 536 00:42:00,600 --> 00:42:05,330 لذلك، سيكون هذا التعليقات. البحث 537 00:42:07,050 --> 00:42:17,080 و req.query هنا. 538 00:42:17,080 --> 00:42:20,920 لذلك، عندما يتم العثور على التعليقات 539 00:42:20,920 --> 00:42:22,974 ، ثم، في هذه المرحلة، 540 00:42:22,974 --> 00:42:25,940 سنقوم بملء المؤلف، 541 00:42:26,880 --> 00:42:30,430 بالفعل هناك، وملء هنا. 542 00:42:30,430 --> 00:42:33,380 لذلك، أنا فقط ذاهب لإزالة هذه التعليقات.المؤلف، وبعد ذلك، 543 00:42:33,380 --> 00:42:37,410 سنقوم ببساطة ملء المؤلف هنا. 544 00:42:37,410 --> 00:42:44,425 ثم، وهذا من شأنه أن يعطينا تعليقات هنا. 545 00:42:44,425 --> 00:42:49,310 ثم، سنقول، وهذا يمكن تبسيطها بشكل كبير. 546 00:42:49,310 --> 00:42:53,835 لذلك، خطأ الصيد هناك على أي حال. 547 00:42:53,835 --> 00:43:00,805 لذا، عندما يأتي التعليق، سيعود ببساطة. 548 00:43:00,805 --> 00:43:03,910 آسف، هذا يجب أن يكون. 549 00:43:03,910 --> 00:43:06,525 لذا، إذا كان للحصول على، 550 00:43:06,525 --> 00:43:09,305 عندما نحصل على التعليقات 551 00:43:09,305 --> 00:43:13,760 والتعليقات.Find req.query، .populate المؤلف هنا 552 00:43:13,760 --> 00:43:18,010 ، وبعد ذلك، سوف نقول،. ثم التعليقات، 553 00:43:18,010 --> 00:43:21,619 وبعد ذلك، سنقول، Res.StatusCode 200، 554 00:43:21,619 --> 00:43:27,605 setheader، وبعد ذلك، سنقوم بإرجاع التعليقات من هنا، 555 00:43:27,605 --> 00:43:30,850 تعليقات res.json من هنا. 556 00:43:30,850 --> 00:43:36,970 الآن، أنا لا ملء الأطباق هنا لأنني لا أحتاج صراحة إلى 557 00:43:36,970 --> 00:43:45,300 الأطباق بالطريقة التي أستخدم بها هذه المعلومات في عميل رد الفعل الخاص بي. 558 00:43:45,300 --> 00:43:46,840 أنا فقط بحاجة إلى معرف الطبق، 559 00:43:46,840 --> 00:43:49,085 ومعرف الطبق موجود بالفعل هناك، 560 00:43:49,085 --> 00:43:55,310 وهذا جيد بما فيه الكفاية بالنسبة لي لاستخدام هذه البيانات في عميل رد الفعل الخاص بي. 561 00:43:55,310 --> 00:43:57,685 لذلك، أنا ذاهب إلى ترك الأمر على هذا النحو هناك. 562 00:43:57,685 --> 00:43:59,530 سأقوم فقط بملء 563 00:43:59,530 --> 00:44:02,910 معلومات المؤلف هناك لأننا بحاجة إلى معلومات المؤلف الكاملة 564 00:44:02,910 --> 00:44:08,930 كلما قمنا بتقديم عنصر تعليق في عميل الرد الخاص بنا. 565 00:44:08,930 --> 00:44:12,655 لذلك، سيتم تحديث الحصول على مثل هذا هنا. 566 00:44:12,655 --> 00:44:22,015 بالنسبة للوظيفة CorsWithOptions، 567 00:44:22,015 --> 00:44:26,070 سنقول، Authenticate.VerifyUser req، الدقة، التالي. 568 00:44:26,070 --> 00:44:29,540 من الواضح، من أجل نشر تعليق، 569 00:44:29,540 --> 00:44:38,315 تحتاج إلى أن يكون المؤلف مستخدمًا صحيحًا تم تسجيل دخوله. 570 00:44:38,315 --> 00:44:42,910 عندها فقط، ستسمح للمستخدم بنشر تعليق. 571 00:44:42,910 --> 00:44:49,020 ثم، يأتي التعليق نفسه في نص رسالة الطلب الواردة. 572 00:44:49,020 --> 00:44:51,810 لذا، أولاً، سنتحقق من الجسم 573 00:44:51,810 --> 00:44:58,865 للتأكد من تضمين التعليق في الجسم هنا. 574 00:44:58,865 --> 00:45:03,730 لذلك، هنا، أنا ذاهب لإزالة كل هذه الأجزاء، وبعد ذلك، 575 00:45:03,730 --> 00:45:06,100 تبسيطها أكثر، وبعد ذلك، 576 00:45:06,100 --> 00:45:09,430 سنقوم بتنفيذ هذا بشكل صحيح هناك. 577 00:45:09,430 --> 00:45:17,755 لذا، في هذه المرحلة، سنقول، 578 00:45:17,755 --> 00:45:27,465 إذا req.body لا يساوي فارغة، 579 00:45:27,465 --> 00:45:35,030 مما يعني أن هناك تعليق مغلق داخل الجسم. 580 00:45:37,380 --> 00:45:45,025 لذلك، اسمحوا لي أن قطع هذا ونقل هذا إلى إذا كان الجزء هنا، 581 00:45:45,025 --> 00:45:47,155 وبعد ذلك، ونحن سوف تحرير ذلك هنا. 582 00:45:47,155 --> 00:45:52,245 لذلك، إذا كان الجسم غير موجود، 583 00:45:52,245 --> 00:45:56,140 ثم سوف يسبب خطأ. 584 00:45:56,140 --> 00:46:01,220 لذلك، سنقول، خطأ جديد خطأ، 585 00:46:01,500 --> 00:46:08,965 لم يتم العثور على تعليق في نص الطلب. 586 00:46:08,965 --> 00:46:12,440 لذلك، سنرفع هذا الخطأ هنا. 587 00:46:12,450 --> 00:46:16,425 حالة الخطأ هي 404. 588 00:46:16,425 --> 00:46:20,385 ثم، سنقول، العودة الخطأ التالي. 589 00:46:20,385 --> 00:46:26,560 لذلك، دعونا نتعامل مع جزء الخطأ هنا إذا كان الجسم 590 00:46:26,560 --> 00:46:33,280 لا يحتوي على معلومات التعليق المناسبة. 591 00:46:33,280 --> 00:46:35,450 إذا كان يحتوي، ثم، بطبيعة الحال، 592 00:46:35,450 --> 00:46:38,170 ما سنفعله بعد ذلك هو، 593 00:46:38,170 --> 00:46:48,310 سنقول، req.body.author هو req.user. _id 594 00:46:50,420 --> 00:46:55,610 السبب في قيامنا بذلك هو أننا نتذكر أنه إذا كان 595 00:46:55,610 --> 00:46:59,950 مستخدمًا مسجلاً وقام المستخدم بتسجيل الدخول، 596 00:46:59,950 --> 00:47:03,050 فسيحتوي req.user على معلومات المستخدم. 597 00:47:03,050 --> 00:47:07,260 لذلك، أنا فقط بحاجة إلى معرف المستخدم الذي قام بتسجيل الدخول حاليا. 598 00:47:07,260 --> 00:47:10,310 لذا، سنقول، req.user. _id، وبعد ذلك، 599 00:47:10,310 --> 00:47:14,645 سنقوم بتعيين req.body.author إلى req.user. 600 00:47:14,645 --> 00:47:20,070 الآن، سيضمن المستخدم التحقق تلقائيًا أنه إذا قمت بالهبوط في هذه المرحلة، 601 00:47:20,070 --> 00:47:25,710 فمن الواضح أنه سيكون لديك مستخدم قام بتسجيل الدخول بشكل صحيح. 602 00:47:25,710 --> 00:47:28,605 وإلا، فإن ذلك قد تسبب بالفعل في المشكلة هناك. 603 00:47:28,605 --> 00:47:30,260 لذلك، عندما تصل في هذه المرحلة، 604 00:47:30,260 --> 00:47:37,660 سيكون لديك مستخدم صالح قام بتسجيل الدخول بالفعل إلى النظام هناك. 605 00:47:37,660 --> 00:47:43,460 لذا، هذا هو المكان الذي ستتمكن منه الآن. 606 00:47:43,460 --> 00:47:46,040 لذا، ما نقوم به هو أن حقل المؤلف، 607 00:47:46,040 --> 00:47:50,625 ونحن نضعه بشكل صريح في معرف المستخدم هنا بحيث 608 00:47:50,625 --> 00:47:57,490 يحتوي req.body على الأجزاء المتبقية من التعليق. 609 00:47:57,490 --> 00:48:01,315 لذلك، كما تدرك، يحتوي التعليق على التصنيف، 610 00:48:01,315 --> 00:48:04,540 والتعليق نفسه، والمؤلف، وحقول الطبق. 611 00:48:04,540 --> 00:48:14,730 لذلك، يجب أن يتم ملء الأجزاء المتبقية من قبل المستخدم. 612 00:48:14,730 --> 00:48:17,775 يجب بالفعل ملء التصنيف والتعليق ومعلومات الطبق 613 00:48:17,775 --> 00:48:20,840 في نص رسالة الطلب الواردة. 614 00:48:20,840 --> 00:48:23,460 يتم ترك جزء المؤلف شاغلاً هناك، 615 00:48:23,460 --> 00:48:28,380 والذي سنقوم بإدراجه بشكل صريح في هذه المرحلة في الجسم هنا. 616 00:48:28,380 --> 00:48:32,515 لذلك، الآن، سيحتوي req.body على معلومات التعليق بالكامل. 617 00:48:32,515 --> 00:48:34,440 لذلك، في هذه المرحلة، 618 00:48:34,440 --> 00:48:43,400 بدلا من القيام بذلك، وسوف نقول، والتعليقات. إنشاء. 619 00:48:44,550 --> 00:48:49,940 باستخدام req.body، سنقوم بإنشاء التعليقات هنا. 620 00:48:50,010 --> 00:48:53,304 بعد ذلك، سيعود هذا 621 00:48:53,304 --> 00:48:58,735 التعليق المقابل للتعليق الذي قمنا بإدراجه هنا للتو. 622 00:48:58,735 --> 00:49:00,755 الآن، مرة واحدة قد عاد التعليق، 623 00:49:00,755 --> 00:49:07,050 ثم يجب أن نفعل التعليقات. findbyID. 624 00:49:07,050 --> 00:49:09,680 الآن، السبب في أننا بحاجة إلى القيام بذلك هو أننا بحاجة 625 00:49:09,680 --> 00:49:13,070 إلى ملء معلومات المؤلف هنا. 626 00:49:13,780 --> 00:49:18,144 لذلك، سنقول، تعليقات فيندبيد. _id، 627 00:49:18,144 --> 00:49:26,155 وبعد ذلك، سنقوم بملء معلومات المؤلف في التعليق نفسه. 628 00:49:26,155 --> 00:49:34,610 ثم، سنقول، ثم التعليق. 629 00:49:36,570 --> 00:49:41,115 الآن، من الواضح، هنا، ستجد أن التعليق سيكون 630 00:49:41,115 --> 00:49:44,880 موجودًا لأننا قمنا للتو بإدراج هذا التعليق في مكانه هناك. 631 00:49:44,880 --> 00:49:54,470 لذلك، هنا، سوف نعود ببساطة، Res.StatusCode هو 200، 632 00:49:54,900 --> 00:50:10,040 Res.Setheader هو نوع المحتوى، التطبيق/json. 633 00:50:14,610 --> 00:50:18,430 التعليق نفسه سيقول، res.json، ثم قم 634 00:50:18,430 --> 00:50:21,745 بإرجاع التعليق في هذه المرحلة. 635 00:50:21,745 --> 00:50:26,255 لذا، هذه هي الطريقة التي سنتعامل بها مع 636 00:50:26,255 --> 00:50:30,805 إدراج تعليق جديد في جانب العميل لدينا هنا. 637 00:50:30,805 --> 00:50:33,925 بالنسبة للوضع، كما تدرك، 638 00:50:33,925 --> 00:50:38,360 لن تكون قادرًا على وضع النقاط/التعليقات/النهاية. 639 00:50:38,360 --> 00:50:47,610 لذلك، سنقول، عملية بوت غير معتمدة على/التعليقات/نقطة النهاية. 640 00:50:52,050 --> 00:50:56,180 هذا هو المغزى هذه هي الرسالة التي ستعود 641 00:50:56,180 --> 00:50:58,570 لذلك، StatusCode هو 403، 642 00:50:58,570 --> 00:51:02,610 وبعد ذلك، عملية PUT غير معتمدة على/التعليقات/. 643 00:51:02,610 --> 00:51:05,260 الآن، عندما نقوم بحذف، 644 00:51:13,230 --> 00:51:22,840 اسمحوا لي فقط قطع هذا من هنا، وبعد ذلك، سنقول، 645 00:51:30,440 --> 00:51:32,835 التعليقات. إزالة. 646 00:51:32,835 --> 00:51:37,710 مكتوبة فارغة. لذلك، عند القيام بحذف على نقطة النهاية تعليقات شرطة مائلة، 647 00:51:37,710 --> 00:51:40,990 ستقوم بإزالة جميع التعليقات من النظام الخاص بك. 648 00:51:40,990 --> 00:51:43,680 لذلك، هذه عملية خطيرة جدا، ولذا، 649 00:51:43,680 --> 00:51:48,990 يجب أن لا تفعل ذلك بشكل طبيعي. 650 00:51:48,990 --> 00:51:53,860 لذلك، سنسمح فقط للمشرف بإجراء مثل هذه العملية. 651 00:51:53,860 --> 00:51:59,410 لذلك، سنقوم بإزالة جميع التعليقات من هناك. 652 00:51:59,410 --> 00:52:01,940 لذلك، عندما تحصل على الرد، 653 00:52:01,940 --> 00:52:07,700 ثم سنقول Res.StatusCode 200. 654 00:52:07,700 --> 00:52:11,080 لذلك، اسمحوا لي فقط نسخ هذه الأجزاء هنا، 655 00:52:12,090 --> 00:52:18,130 ومن ثم تأتي ولصقها هنا. 656 00:52:18,130 --> 00:52:21,330 لذلك، سنقول، التعليقات. إزالة. 657 00:52:21,330 --> 00:52:30,480 ثم الاستجابة Res.StatusCode 200 تطبيق json ثم res.json (استجابة) هنا. 658 00:52:30,480 --> 00:52:33,100 لذا، هذه هي الطريقة التي نتعامل بها مع الحذف. 659 00:52:33,100 --> 00:52:37,280 حذف العملية على نقطة نهاية تعليقات الشرطة المائلة. 660 00:52:37,280 --> 00:52:43,135 الآن، المسار التالي هو موجه التعليق. 661 00:52:43,135 --> 00:52:49,490 لذلك، هنا سوف نقول CommentRouter.Route 662 00:52:49,490 --> 00:52:56,820 ونقطة النهاية هنا سيكون شرطة مائلة CommentId. 663 00:53:01,190 --> 00:53:05,580 لذلك، هنا سوف تبقى الخيارات على هذا النحو. 664 00:53:05,580 --> 00:53:09,760 ثم للحصول على جهاز التوجيه الحالي، 665 00:53:09,760 --> 00:53:20,455 للحصول على سنقول، التعليقات. findbyID (req.params. 666 00:53:20,455 --> 00:53:25,040 هذا سيكون موضع الثناء. 667 00:53:25,380 --> 00:53:31,029 لذلك، بمجرد أن نجد التعليق المحدد، 668 00:53:31,029 --> 00:53:37,525 فإننا سوف ملء فقط المؤلف من هناك. 669 00:53:37,525 --> 00:53:39,985 ثم بمجرد ملء المؤلف، 670 00:53:39,985 --> 00:53:45,830 ثم سنقول، ثم التعليق. 671 00:53:47,880 --> 00:53:51,310 الآن، كل هذا الجزء غير ضروري هنا، 672 00:53:51,310 --> 00:53:54,440 لذلك أنا ذاهب فقط لحذف الجزء. 673 00:53:54,480 --> 00:54:00,985 هذا أيضا ليس الشيء المناسب هنا. 674 00:54:00,985 --> 00:54:04,540 لذلك، اسمحوا لي إعادة تسمية رمز. 675 00:54:04,540 --> 00:54:08,990 لذلك، سنقول للحصول على التعليقات. FindbyID، 676 00:54:11,550 --> 00:54:15,385 ثم ملء المؤلف، 677 00:54:15,385 --> 00:54:20,365 ثم التعليق، res.StatusCode هو 200، Setheader. 678 00:54:20,365 --> 00:54:22,435 ثم الباقي هو جسون. 679 00:54:22,435 --> 00:54:29,960 سنقوم ببساطة بإعادة التعليقات هنا. 680 00:54:39,240 --> 00:54:46,750 لذلك، سنقوم بإرجاع التعليق في هذه المرحلة، res.json (تعليق). 681 00:54:46,750 --> 00:54:49,340 ستجد التعليق المحدد، 682 00:54:49,340 --> 00:54:52,415 ثم تعيد هذا التعليق للنشر. 683 00:54:52,415 --> 00:54:55,185 بالنسبة لما بعد العملية، كما تدرك، 684 00:54:55,185 --> 00:54:56,900 لا 685 00:54:56,900 --> 00:55:06,740 يُسمح بما بعد العملية على التعليقات CommentId. 686 00:55:10,080 --> 00:55:13,805 لذا، هذه هي الرسالة التي سنرسل، 687 00:55:13,805 --> 00:55:19,110 عملية POST غير معتمدة على التعليقات المائلة CommentId. 688 00:55:19,110 --> 00:55:23,640 لذا، هذه هي الرسالة التي سنقولها للوضع. 689 00:55:23,640 --> 00:55:33,730 الآن، لوضع، ونحن سوف نقول التعليقات. العثور على حيث معرف (Req.params.commentid). 690 00:55:34,890 --> 00:55:39,230 لذلك، سنجد التعليق هناك 691 00:55:40,890 --> 00:55:48,070 ، وهناك تعليق، لذلك لوضع. 692 00:55:48,070 --> 00:55:50,805 لذلك، سنجد التعليق هناك، 693 00:55:50,805 --> 00:55:53,400 ثم سنقول للتعليقات. 694 00:55:53,400 --> 00:55:55,305 لذا، إذا وجدنا التعليق، 695 00:55:55,305 --> 00:56:07,080 إذا لم يكن التعليق فارغًا، 696 00:56:07,080 --> 00:56:19,455 فسنتحقق أيضًا مما إذا كان التعليق. 697 00:56:19,455 --> 00:56:32,625 إذا لم يكن كذلك، فإن التعليق.arthur يساوي (req.user. _id). 698 00:56:32,625 --> 00:56:38,095 لذلك، نحن نتبادل التحقق للتأكد من 699 00:56:38,095 --> 00:56:43,755 أن التعليقات.المؤلف هو نفس المستخدم الحالي. 700 00:56:43,755 --> 00:56:50,950 فقط المستخدم الحالي الذي تم تسجيل الدخول - إذا كان المستخدم هو نفسه كاتب التعليقات، 701 00:56:50,950 --> 00:56:53,760 ثم سيتم السماح للمستخدم لتحديث. 702 00:56:53,760 --> 00:56:57,190 لذلك، وهذا هو أول شيء أننا سوف تحقق. 703 00:56:57,190 --> 00:57:01,900 لذلك، التعليقات، ثم التعليقات.author.equall rec.user. 704 00:57:01,900 --> 00:57:07,860 إذا لم يكن الأمر كذلك، فستقول أنك غير مأذون له بتحديث هذا التعليق. 705 00:57:07,860 --> 00:57:10,859 كما تشاه.403، 706 00:57:10,859 --> 00:57:13,090 ثم قم بإرجاع الخطأ التالي هنا. 707 00:57:13,090 --> 00:57:16,705 لذلك، سنقوم بإنشاء الخطأ هناك. 708 00:57:16,705 --> 00:57:21,800 ثم بعد ذلك، ثم سنقول 709 00:57:29,910 --> 00:57:36,860 req.body.author، req.user. 710 00:57:40,010 --> 00:57:42,215 هذا مهم 711 00:57:42,215 --> 00:57:45,580 الآن، هذين ليست ضرورية هنا، 712 00:57:45,580 --> 00:57:51,385 لأننا نقوم بحفظ التعليق مباشرة. 713 00:57:51,385 --> 00:58:05,980 ثم حبوب منع الحمل، وسنقول التعليقات.findbyidandupdate، 714 00:58:05,980 --> 00:58:14,965 وreq.params.Commentid. 715 00:58:14,965 --> 00:58:18,395 لذلك، سنجد هذا التعليق المحدد، 716 00:58:18,395 --> 00:58:21,925 لأننا قد تم تزويدنا بالفعل معرف التعليق. 717 00:58:21,925 --> 00:58:27,205 لذلك، سنقوم بالتعليقات findByid Req.params.Commentid. 718 00:58:27,205 --> 00:58:30,260 ثم سنقول بعد ذلك (تعليق). 719 00:58:32,730 --> 00:58:38,705 عند توفير Req.params.Commentid، 720 00:58:38,705 --> 00:58:42,275 سيكون علينا توفير المعلمة الثانية بشكل صريح، 721 00:58:42,275 --> 00:58:45,825 وهو ما نريد تغييره. 722 00:58:45,825 --> 00:58:52,285 لذلك، سنقول مجموعة $: req.body. 723 00:58:52,285 --> 00:58:54,970 لذا، فإن المعلمة الثانية، بشكل أساسي، 724 00:58:54,970 --> 00:58:58,740 تخبرك بأي جزء تقوم بتغييره. 725 00:58:58,740 --> 00:59:03,710 الآن، بما أننا قد تم تزويدنا الجسم الذي يحتوي على التعليق المحدث، 726 00:59:03,710 --> 00:59:09,140 سنقوم فقط بتحديث التعليق بأكمله نفسه. 727 00:59:09,510 --> 00:59:18,205 ثم الجزء الآخر الذي سنطلبه هو جديد: صحيح. 728 00:59:18,205 --> 00:59:23,240 لذلك، سيضمن هذا أن التعليق المحدث سيتم إرجاعه 729 00:59:23,240 --> 00:59:29,815 في دن هذه المكالمة إلى التعليقات. findbyidandupdate. 730 00:59:29,815 --> 00:59:32,565 لذلك، سوف نقول ثم التعليقات. 731 00:59:32,565 --> 00:59:35,214 عندما يتم إرجاع هذا التعليق، 732 00:59:35,214 --> 00:59:38,440 ثم سنقول التعليقات. findbyID (تعليق. _id). 733 00:59:46,200 --> 00:59:51,460 ثم ملء المؤلف هناك. 734 00:59:51,460 --> 00:59:53,785 سنقوم بملء المؤلف هناك، 735 00:59:53,785 --> 00:59:58,490 وبعد ذلك سنقول ثم التعليق. 736 00:59:58,700 --> 01:00:09,680 لذلك، ترى أننا سوف تحصل على التعليق ومن ثم إرجاع التعليق في هذه المرحلة. 737 01:00:09,680 --> 01:00:13,095 لذلك، هذه هي الطريقة التي سنقوم بتحديث التعليق. 738 01:00:13,095 --> 01:00:17,395 لذا، هذا هو الوضع الذي لا يكون فيه التعليق فارغًا. 739 01:00:17,395 --> 01:00:20,625 لذلك، هذا إذا كان البيان للتعليق ليس فارغًا. 740 01:00:20,625 --> 01:00:23,785 لذلك، وإلا إذا كان جزء، 741 01:00:23,785 --> 01:00:29,020 والآن هذا لا ينطبق، 742 01:00:29,020 --> 01:00:33,325 لذلك سنقول آخر، خطأ. 743 01:00:33,325 --> 01:00:35,470 الخطأ في هذه الحالة. 744 01:00:35,470 --> 01:00:37,825 لذلك، إذا كان التعليق فارغًا، 745 01:00:37,825 --> 01:00:40,850 فهذا يعني أننا لم نجد التعليق هناك، 746 01:00:40,850 --> 01:00:43,650 لذلك لا يمكنك تعديل تعليق غير موجود. 747 01:00:43,650 --> 01:00:44,805 لذلك سنقول خطأ، 748 01:00:44,805 --> 01:00:54,700 لم يتم العثور على تعليق خطأ جديد Req.params.commentID وبعد ذلك سنقوم بإرجاع الخطأ. 749 01:00:54,700 --> 01:01:01,255 لذلك، هذه هي الطريقة التي سنتعامل بها مع جزء من تعليقنا هنا، 750 01:01:01,255 --> 01:01:04,099 ثم في النهاية الحذف. 751 01:01:06,120 --> 01:01:11,130 للحذف، مرة أخرى سيكون لدينا للعثور أولا 752 01:01:11,130 --> 01:01:12,900 التعليقات. findbyid (Req.params.commentid) 753 01:01:12,900 --> 01:01:25,720 ثم التعليق. 754 01:01:25,720 --> 01:01:28,150 لذا، سنبحث عن التعليق. 755 01:01:28,150 --> 01:01:34,160 لذا، سنتحقق أولاً مما إذا كان التعليق لا يساوي القيمة الفارغة. 756 01:01:36,180 --> 01:01:39,955 من المهم التحقق من ذلك هنا. 757 01:01:39,955 --> 01:01:50,990 ثم، الجزء التالي الذي سنتحقق منه هو إذا كان التعليق.author يساوي req.user. 758 01:01:58,830 --> 01:02:03,400 نحن نتأكد من أن هذا المستخدم الذي يحاول حذف 759 01:02:03,400 --> 01:02:08,060 هذا التعليق هو بالضبط نفس المستخدم الذي أدرج التعليق في المقام الأول. 760 01:02:08,060 --> 01:02:10,750 إذا لم يكن كذلك، لذلك إذا كان هذا هو الوضع، 761 01:02:10,750 --> 01:02:13,920 ثم سترى «أنت غير مأذون لحذف هذا التعليق!» 762 01:02:13,920 --> 01:02:16,365 ثم أعد الحالة هناك. 763 01:02:16,365 --> 01:02:20,920 ثم أسفل هنا، 764 01:02:20,920 --> 01:02:41,310 سنقول التعليقات. findbyidandRemove هنا. 765 01:02:41,310 --> 01:02:48,750 لذلك، سنقول التعليقات. findbyidandRemove (Req.params.commentid)، 766 01:02:48,750 --> 01:02:54,035 ثم سنحصل على بعض الرد من التعليق. 767 01:02:54,035 --> 01:02:55,630 لذلك، في هذه المرحلة، 768 01:02:55,630 --> 01:02:59,830 سنقول ببساطة، Res.StatusCode. 769 01:02:59,830 --> 01:03:05,365 لذلك سنقول التعليقات. findbyidandRemove ثم الاستجابة. 770 01:03:05,365 --> 01:03:07,210 إذا تمت إزالته بشكل صحيح، 771 01:03:07,210 --> 01:03:10,915 فسنقول 200 ثم res.json 772 01:03:10,915 --> 01:03:17,260 الاستجابة هنا وسنقوم أيضًا بالقبض على الخطأ في هذه المرحلة. 773 01:03:17,260 --> 01:03:25,195 لذلك، اسمحوا لي فقط نسخ ذلك هنا وبعد ذلك سوف تشمل الصيد من الخطأ في هذه المرحلة. 774 01:03:25,195 --> 01:03:28,895 إذاً، هذا أول شيء سنتحقق منه 775 01:03:28,895 --> 01:03:33,500 سنضمن أن التعليق لا يساوي القيمة الفارغة. 776 01:03:33,630 --> 01:03:38,360 خلاف ذلك، لذلك هذا هو الجزء الآخر. 777 01:03:39,810 --> 01:03:44,170 لذلك، هذا هو الجزء الآخر من إذا كان خطأ آخر 778 01:03:44,170 --> 01:03:48,040 تعليق جديد req.params.commentid لم يتم العثور عليه ثم 779 01:03:48,040 --> 01:03:56,220 404 وإرسال جزء آخر بالنسبة لنا ومن ثم الجزء ثم التعامل بشكل مناسب. 780 01:03:56,220 --> 01:04:01,460 لذلك، هذه هي التغييرات التي نجريها لجهاز التوجيه التعليق هنا. 781 01:04:01,460 --> 01:04:05,025 لذلك، نحن نتعامل مع وظيفة الحصول على وضع وحذف 782 01:04:05,025 --> 01:04:10,330 لتعليقات شرطة مائلة ونقطة شرطة مائلة لتأثير CommentId. 783 01:04:10,330 --> 01:04:12,495 لذلك بمجرد الانتهاء من هذا، 784 01:04:12,495 --> 01:04:17,500 ثم نحن بحاجة إلى تضمين هذا في ملف app.js. 785 01:04:17,500 --> 01:04:27,345 لذلك، سوف نذهب إلى ملف app.js وبعد ذلك سنقول 786 01:04:27,345 --> 01:04:30,070 فار التعليق 787 01:04:31,130 --> 01:04:42,280 تتطلب المساربات/التعليق. 788 01:04:42,280 --> 01:04:45,960 لذلك، لدينا جهاز توجيه التعليق هنا وبعد ذلك سوف نذهب 789 01:04:45,960 --> 01:04:49,390 إلى ملف app.js أسفل هنا 790 01:04:49,390 --> 01:04:54,610 وبعد ذلك سوف نقول app.use 791 01:04:55,040 --> 01:05:04,695 تعليقات شرطة مائلة، CommentRouter هنا. 792 01:05:04,695 --> 01:05:07,365 هذا كل شيء حتى الآن، 793 01:05:07,365 --> 01:05:09,390 موجه التعليق الخاص بي جاهز. 794 01:05:09,390 --> 01:05:12,935 لذلك، دعونا المضي قدما وحفظ جميع التغييرات. 795 01:05:12,935 --> 01:05:19,020 ثم يتم تحديث الخادم لدينا الآن 796 01:05:19,020 --> 01:05:24,420 من أجل التعامل مع جميع الطلبات من عملائنا React هنا. 797 01:05:24,420 --> 01:05:27,800 الآن، إذا كنت تريد أن تفعل الطريقة البديلة، وهذا هو، 798 01:05:27,800 --> 01:05:34,120 لديك تعليقاتك كوثائق فرعية من الطبق الخاص بك ومن ثم تريد التعامل مع ذلك، 799 01:05:34,120 --> 01:05:37,680 ثم سوف تحتاج إلى تحديث العميل رد فعل 800 01:05:37,680 --> 01:05:42,185 لتكون قادرة على استخدام التعليقات من داخل كل طبق بشكل مناسب. 801 01:05:42,185 --> 01:05:44,830 هذا سيترك كممارسة لك 802 01:05:44,830 --> 01:05:48,920 فكر في كيفية تصميم عميل رد الفعل الخاص بك بحيث 803 01:05:48,920 --> 01:05:53,465 يعمل بشكل جيد للغاية مع الإصدار السابق من 804 01:05:53,465 --> 01:06:03,735 الخادم الذي كان لديه تعليقات كوثائق فرعية من الأطباق الخاصة بك أنفسهم. 805 01:06:03,735 --> 01:06:07,065 الآن، ستكون هذه طريقة مثيرة للاهتمام لتنفيذها. 806 01:06:07,065 --> 01:06:10,480 بالطبع، الأمر أكثر تعقيدًا قليلاً من الطريقة التي 807 01:06:10,480 --> 01:06:14,965 نفذنا بها عميل React حيث أبقينا التعليقات مستقلة عن 808 01:06:14,965 --> 01:06:20,840 الأطباق ولكن بعد ذلك يكون العمل الإضافي هو مسؤولية 809 01:06:20,840 --> 01:06:22,910 جانب العميل لأنك تحتاج إلى تحديد 810 01:06:22,910 --> 01:06:26,765 التعليقات المناسبة عند عرض طبق معين. 811 01:06:26,765 --> 01:06:30,370 تحتاج إلى تحديد التعليقات من جميع التعليقات هنا. 812 01:06:30,370 --> 01:06:35,170 لذا، هذا عمل إضافي يقوم به عميل React الخاص بنا بسبب 813 01:06:35,170 --> 01:06:40,680 حقيقة أننا فصلنا التعليقات عن الأطباق نفسها. 814 01:06:40,680 --> 01:06:46,165 وبالمثل، إذا كنت تستطيع إعادة تصميم العميل الزاوي الخاص بك لتكون قادرة 815 01:06:46,165 --> 01:06:51,775 على التعامل مع الوضع حيث يتم الاحتفاظ التعليقات مستقلة عن الأطباق الخاصة بك. 816 01:06:51,775 --> 01:06:56,020 الآن، هذه هي جميع التمارين التي يمكنك القيام بها من أجل معرفة كيف يمكنك 817 01:06:56,020 --> 01:07:01,210 توسيع تطبيقات العميل الخاصة بك للتعامل مع أي نوع من الخوادم، وهما 818 01:07:01,210 --> 01:07:04,430 نوعان مختلفان من الخوادم هناك. 819 01:07:04,860 --> 01:07:11,480 لذلك، مع هذا، ونحن استكمال التحديث إلى الخادم لدينا هنا. 820 01:07:11,480 --> 01:07:15,040 لذلك، مع هذا، قمنا بتحديث كل شيء على جانب الخادم. 821 01:07:15,040 --> 01:07:17,890 لذلك، دعونا حفظ جميع التغييرات على جانب الخادم. 822 01:07:17,890 --> 01:07:26,755 حتى الآن، الخادم الخاص بنا جاهز للتعامل مع الطلبات الواردة من عميل React الخاص بنا. 823 01:07:26,755 --> 01:07:29,340 مع هذا، نكمل هذا التمرين. 824 01:07:29,340 --> 01:07:33,300 في هذا التمرين، قمنا الآن بإعداد الخادم السريع الخاص بنا 825 01:07:33,300 --> 01:07:38,985 للتعامل مع الطلبات الواردة من عميل React الخاص بنا. 826 01:07:38,985 --> 01:07:43,190 في التمرين التالي، سننظر إلى العميل المتفاعل بمزيد من التفصيل 827 01:07:43,190 --> 01:07:48,000 لفهم كيفية التواصل مع هذا الخادم الإضافي. 828 01:07:48,000 --> 01:07:50,640 هذا هو الوقت المناسب بالنسبة لك للقيام 829 01:07:50,640 --> 01:07:55,880 بتغطية git مع رسالة دمج العميل والخادم.