1
00:00:00,000 --> 00:00:08,095
الآن بعد أن أكملنا تحديث جانب الخادم،

2
00:00:08,095 --> 00:00:10,770
حان الوقت للانتقال إلى العميل الزاوي.

3
00:00:10,770 --> 00:00:13,830
لراحتك، لقد قدمت لك

4
00:00:13,830 --> 00:00:17,700
مستودع GitHub الذي يحتوي على الإصدار النهائي من

5
00:00:17,700 --> 00:00:20,840
عميل Angular القادر على التواصل مع

6
00:00:20,840 --> 00:00:26,805
خادم REST API الخاص بنا ثم عرض وجهات النظر المختلفة لعميلنا.

7
00:00:26,805 --> 00:00:29,690
لذلك، لقد اتخذت تطبيق Angular الذي قمنا

8
00:00:29,690 --> 00:00:32,895
بتطويره في الدورة الثانية من هذا التخصص،

9
00:00:32,895 --> 00:00:34,380
ومن ثم تعديله.

10
00:00:34,380 --> 00:00:39,680
ونحن سوف تأخذ جولة قصيرة من خلال رمز في وقت لاحق قليلا.

11
00:00:39,680 --> 00:00:44,005
الآن، ستقوم باستنساخ مستودع Git إلى جهاز الكمبيوتر الخاص بك،

12
00:00:44,005 --> 00:00:47,525
ثم بدء تشغيل عميل Angular الخاص بك،

13
00:00:47,525 --> 00:00:50,820
ثم رؤيته يتواصل مع جانب الخادم الخاص بنا.

14
00:00:50,820 --> 00:00:54,555
دعونا نرى التفاصيل التالية.

15
00:00:54,555 --> 00:00:57,885
للبدء في هذا التمرين،

16
00:00:57,885 --> 00:01:01,345
في المحطة الطرفية أو نافذة الأوامر،

17
00:01:01,345 --> 00:01:04,070
انتقل إلى موقعك المناسب ثم في

18
00:01:04,070 --> 00:01:06,685
موجه نوع git clone

19
00:01:06,685 --> 00:01:21,615
https://github.com/jmuppala/conFusion-Angular6.git.

20
00:01:21,615 --> 00:01:28,705
ثم، دع تطبيق Angular يتم استنساخه إلى جهاز الكمبيوتر الخاص بك.

21
00:01:28,705 --> 00:01:30,495
بمجرد اكتمال الاستنساخ،

22
00:01:30,495 --> 00:01:39,340
انتقل إلى مجلد Confusion-angular6

23
00:01:39,340 --> 00:01:43,620
الذي تم إنشاؤه للتو عند استنساخ مستودع git هذا.

24
00:01:43,620 --> 00:01:48,845
ثم ستلاحظ على الفور أن هناك مجموعة من الملفات بالفعل هناك.

25
00:01:48,845 --> 00:01:56,700
الآن، في موجه، اكتب npm install،

26
00:01:56,700 --> 00:02:00,500
من أجل تثبيت جميع وحدات العقدة

27
00:02:00,500 --> 00:02:04,460
التي يعتمد عليها هذا التطبيق Angular.

28
00:02:04,460 --> 00:02:09,415
لذلك، مرة واحدة وحدات عقدة أو كل تثبيت،

29
00:02:09,415 --> 00:02:18,095
ثم يمكننا بدء لدينا نغ خدمة لتجميع وخدمة ما يصل لدينا تطبيق الزاوي.

30
00:02:18,095 --> 00:02:21,765
بمجرد تثبيت كل شيء عن طريق تثبيت npm

31
00:02:21,765 --> 00:02:27,080
، تأكد من أن خادم MongoDB

32
00:02:27,080 --> 00:02:32,365
الخاص بك يعمل ويعمل وكذلك خادم REST API الخاص بك يعمل أيضًا.

33
00:02:32,365 --> 00:02:35,165
خلاف ذلك، لن يعمل عميل Angular الخاص بك.

34
00:02:35,165 --> 00:02:39,720
لذلك، الآن بعد أن قمت بتثبيت عميل Angular الخاص بك على جهاز الكمبيوتر الخاص بك،

35
00:02:39,720 --> 00:02:43,815
في نوع موجه ng خدمة

36
00:02:43,815 --> 00:02:50,755
وسيتم تجميع تطبيق Angular الخاص بك وتقديمه بواسطة ng خدمة في فترة قصيرة.

37
00:02:50,755 --> 00:02:54,725
بمجرد تجميع تطبيق Angular الخاص بك بنجاح،

38
00:02:54,725 --> 00:02:59,345
انتقل إلى متصفح وافتح تطبيق Angular الخاص بك في المتصفح.

39
00:02:59,345 --> 00:03:01,025
الذهاب إلى المتصفح،

40
00:03:01,025 --> 00:03:06,665
في شريط العناوين،

41
00:03:06,665 --> 00:03:12,050
اسمحوا لي أن اكتب في localhost: 4200

42
00:03:12,050 --> 00:03:14,345
وسترى أن تطبيق Angular الخاص بك

43
00:03:14,345 --> 00:03:17,930
يبدأ ويظهر على الشاشة هنا.

44
00:03:17,930 --> 00:03:21,170
ستلاحظ على الفور أن تطبيق Angular الخاص بك

45
00:03:21,170 --> 00:03:24,500
قادر على جلب البيانات من الخادم ثم تقديم

46
00:03:24,500 --> 00:03:28,115
الأجزاء المختلفة من تطبيق Angular الخاص بك تمامًا مثل ما

47
00:03:28,115 --> 00:03:33,040
فعلته في نهاية دورة Angular الخاصة بك.

48
00:03:33,080 --> 00:03:35,605
عندما تذهب للحديث عن المجلد،

49
00:03:35,605 --> 00:03:42,730
سترى أيضًا أن الصفحة حول تعرض أيضًا المعلومات على هذا النحو.

50
00:03:42,730 --> 00:03:45,970
في القائمة، ترى العناصر في القائمة التي يتم

51
00:03:45,970 --> 00:03:49,475
عرضها تماما كما رأينا مع تطبيق Angular.

52
00:03:49,475 --> 00:03:51,595
الآن، بالإضافة إلى ذلك، لقد أضفت في

53
00:03:51,595 --> 00:03:56,320
صفحة واحدة أخرى إلى تطبيق صفحة واحدة يسمى المفضلة،

54
00:03:56,320 --> 00:04:02,590
والتي لا يمكنك الانتقال إليها لأنه لم يتم تسجيل دخول أي مستخدم إلى النظام.

55
00:04:02,590 --> 00:04:05,960
لذلك، ترى أنه ليس لدي أي مستخدم تسجيل الدخول إلى النظام.

56
00:04:05,960 --> 00:04:09,120
لذلك، هذا هو السبب في عدم وجود نقطة في الإشارة إلى المفضلة،

57
00:04:09,120 --> 00:04:10,845
لأنك لا تعرف أي مستخدم،

58
00:04:10,845 --> 00:04:12,990
كمفضلة، يجب أن تظهر هنا.

59
00:04:12,990 --> 00:04:15,580
صفحة الاتصال كالمعتاد.

60
00:04:15,580 --> 00:04:17,345
الآن، دعونا تسجيل الدخول.

61
00:04:17,345 --> 00:04:19,235
لتسجيل الدخول إلى تطبيقنا،

62
00:04:19,235 --> 00:04:25,665
سنضغط على زر تسجيل الدخول ثم سترى أن مربع حوار تسجيل الدخول للملوثات العضوية الثابتة.

63
00:04:25,665 --> 00:04:32,620
ثم، اسمحوا لي أن تسجيل الدخول كواحد من المستخدمين المسجلين،

64
00:04:32,620 --> 00:04:37,295
والتي قمنا بتسجيلها كجزء من هذه الدورة في وقت سابق.

65
00:04:37,295 --> 00:04:39,100
لذلك، بمجرد تسجيل الدخول،

66
00:04:39,100 --> 00:04:41,840
ستلاحظ على الفور أنه،

67
00:04:41,840 --> 00:04:44,150
إلى الزاوية اليمنى،

68
00:04:44,150 --> 00:04:47,410
سترى زر تسجيل الدخول قد تحول الآن إلى

69
00:04:47,410 --> 00:04:51,730
تسجيل الخروج ويشار إلى اسم المستخدم هنا.

70
00:04:51,730 --> 00:04:54,500
لذا، من قام بتسجيل الدخول يشار إليه هنا.

71
00:04:54,500 --> 00:04:56,110
يمكنك أيضا، من حيث المبدأ،

72
00:04:56,110 --> 00:05:00,925
استبدال هذا مع صورة المستخدم.

73
00:05:00,925 --> 00:05:03,715
الآن، لذلك تحتاج إلى إجراء المزيد من التعديلات

74
00:05:03,715 --> 00:05:07,790
على كل من العميل والخادم من أجل دعم عرض الصورة هنا.

75
00:05:07,790 --> 00:05:10,570
ولكن، في الوقت الحالي، أنا فقط تظهر لك كيف

76
00:05:10,570 --> 00:05:14,260
يمكننا بسهولة عرض معلومات المستخدم هنا.

77
00:05:14,260 --> 00:05:17,200
لذلك، يتطلب هذا تعديلًا

78
00:05:17,200 --> 00:05:20,335
طفيفًا على رأس المكون حيث سأتمكن من استرداد

79
00:05:20,335 --> 00:05:23,410
اسم المستخدم من خدمة

80
00:05:23,410 --> 00:05:27,060
تسمى خدمة OAuth التي سنتحدث عنها في فترة قصيرة.

81
00:05:27,060 --> 00:05:29,420
لذلك، بمجرد تسجيل دخول المستخدم،

82
00:05:29,420 --> 00:05:31,955
ثم إذا قمت الآن بالنقر فوق المفضلة،

83
00:05:31,955 --> 00:05:35,360
ستلاحظ أنه لا يوجد شيء في المفضلة للمستخدم.

84
00:05:35,360 --> 00:05:40,815
من الواضح، لأن المستخدم لم يختار بعد أي المفضلة.

85
00:05:40,815 --> 00:05:44,675
لذلك، دعونا نذهب الآن إلى القائمة ثم في القائمة،

86
00:05:44,675 --> 00:05:52,980
اسمحوا لي أن حدد عنصر واحد ومن ثم أنها سوف تضيف هذا الطبق إلى المفضلة لدينا.

87
00:05:52,980 --> 00:05:55,230
لذلك، النزول أدناه هنا،

88
00:05:55,230 --> 00:05:58,415
ترى رمز القلب هناك،

89
00:05:58,415 --> 00:06:02,655
انقر على ذلك وسترى أن هذا سيتم إضافته إلى المفضلة.

90
00:06:02,655 --> 00:06:06,620
ويشار إلى حقيقة أن هذا قد تمت إضافته إلى المفضلة من خلال

91
00:06:06,620 --> 00:06:12,790
التغيير في الرمز هنا من قلب شاغر إلى قلب مملوء.

92
00:06:12,790 --> 00:06:15,790
الآن، إذا ذهبت إلى أي طبق آخر،

93
00:06:15,790 --> 00:06:19,080
ستلاحظ أن هذا له قلب شاغر،

94
00:06:19,080 --> 00:06:22,795
مما يعني أن هذا ليس بعد من بين المفضلة لدينا.

95
00:06:22,795 --> 00:06:25,070
لذلك، اسمحوا لي أن أضيف في عنصر واحد آخر إلى

96
00:06:25,070 --> 00:06:29,990
المفضلة ومن ثم دعونا إضافة عنصر ثالث إلى المفضلة أيضا.

97
00:06:29,990 --> 00:06:37,455
لذلك، الآن، سترى أنه إذا ذهبت الآن إلى المفضلة،

98
00:06:37,455 --> 00:06:42,560
سترى مجموعة من المفضلة التي يتم عرضها هنا.

99
00:06:42,560 --> 00:06:46,610
لذا، رَأيتَ بأنّني فقط أضفتُ هذه الصحون الثلاثة إلى المفضّلةِ.

100
00:06:46,610 --> 00:06:48,820
لذلك، يتم عرض هذه هنا.

101
00:06:48,820 --> 00:06:57,100
لذلك، يتم تتبع هذا باستخدام نقطة النهاية المفضلة على جانب الخادم،

102
00:06:57,100 --> 00:06:59,870
والتي قمت بتطبيقها كجزء من المهمة الأخيرة.

103
00:06:59,870 --> 00:07:05,554
لذا، إذا قمت بهذا التعيين بشكل صحيح، فيجب أن يعمل هذا الجزء كما هو متوقع.

104
00:07:05,554 --> 00:07:09,310
الآن، يمكننا أيضا تعديل المفضلة.

105
00:07:09,310 --> 00:07:11,320
لذلك، على سبيل المثال، في الزاوية اليمنى هنا،

106
00:07:11,320 --> 00:07:14,165
ترى هذا تبديل الحذف هنا.

107
00:07:14,165 --> 00:07:16,320
لذلك، اسمحوا لي أن تشغيل ذلك.

108
00:07:16,320 --> 00:07:17,730
لذلك، عند تشغيله،

109
00:07:17,730 --> 00:07:22,025
سترى على الفور ثلاثة الصلبان الحمراء

110
00:07:22,025 --> 00:07:27,630
تظهر في الجزء السفلي من هذه العناصر الثلاثة في المفضلة.

111
00:07:27,630 --> 00:07:29,905
عندما أنقر عليه، ثم تختفي.

112
00:07:29,905 --> 00:07:36,750
لذلك، هذه طريقة واحدة لتشغيل أزرار الحذف على المفضلة لديك ثم.

113
00:07:36,750 --> 00:07:40,965
لذلك، اسمحوا لي أن المضي قدما وحذف أحد العناصر من المفضلة.

114
00:07:40,965 --> 00:07:42,515
لذلك، عند النقر على هذا الزر،

115
00:07:42,515 --> 00:07:47,540
ستلاحظ على الفور أن هذا العنصر يتم حذفه من المفضلة،

116
00:07:47,540 --> 00:07:50,405
ويختفي على الفور

117
00:07:50,405 --> 00:07:54,780
ويتم تحديث المفضلة وسترى القيمة الناتجة التي يتم عرضها هنا.

118
00:07:54,780 --> 00:07:56,115
وفي الوقت نفسه،

119
00:07:56,115 --> 00:07:58,530
يتم إيقاف تشغيل تبديل الحذف هذا،

120
00:07:58,530 --> 00:08:01,250
بحيث أزرار الحذف لم تعد مرئية.

121
00:08:01,250 --> 00:08:07,610
يمكنني دائما تشغيل أزرار الحذف مرة أخرى عن طريق النقر على تشغيل وإيقاف هنا.

122
00:08:07,610 --> 00:08:11,210
لذلك، لاحظ أنه سيتم عرض المفضلة فقط

123
00:08:11,210 --> 00:08:15,790
للمستخدمين الذين قاموا بتسجيل الدخول إلى النظام.

124
00:08:15,790 --> 00:08:21,260
لذلك، تلاحظ على الفور مجموعة من التغييرات التي تم

125
00:08:21,260 --> 00:08:23,540
إجراؤها على العميل الزاوي من أجل

126
00:08:23,540 --> 00:08:26,930
دعم بعض هذه الميزات الإضافية التي تراها هنا.

127
00:08:26,930 --> 00:08:31,190
رأيت أيضًا ميزة تسجيل الدخول والخروج مدعومة هنا.

128
00:08:31,190 --> 00:08:33,000
لذلك، عند النقر على زر تسجيل الخروج،

129
00:08:33,000 --> 00:08:35,930
لاحظت على الفور أن المستخدم يحصل على تسجيل الخروج

130
00:08:35,930 --> 00:08:39,800
ويختفي اسم المستخدم من هناك،

131
00:08:39,800 --> 00:08:44,250
وبالتالي يتم تشغيل الزر أيضا إلى زر تسجيل الدخول.

132
00:08:44,560 --> 00:08:49,760
لذا، مع هذا، تلاحظ كيف تم

133
00:08:49,760 --> 00:08:54,880
تحديث عميل Angular الخاص بي للاستفادة من خادم REST API الجديد

134
00:08:54,880 --> 00:08:59,100
من أجل دعم المفضلة التي يتم حفظها وعلى جانب الخادم

135
00:08:59,100 --> 00:09:04,930
ثم تنعكس تلقائيًا في تطبيق العميل الخاص بي كما هو موضح هنا.

136
00:09:04,930 --> 00:09:08,305
دعونا نلقي جولة قصيرة من خلال

137
00:09:08,305 --> 00:09:14,160
رمز Angular الذي قمت بتوفيره لك في مستودع GitHub،

138
00:09:14,160 --> 00:09:17,710
ونرى أيضًا كيف قمنا بتعديل أجزاء من الشفرة من

139
00:09:17,710 --> 00:09:21,655
أجل تنفيذ تطبيق Angular المحدث.

140
00:09:21,655 --> 00:09:24,310
ستلاحظ أن هناك خدمة جديدة

141
00:09:24,310 --> 00:09:27,130
قمت بتقديمها هنا تسمى خدمة المصادقة.

142
00:09:27,130 --> 00:09:29,295
تعتني خدمة المصادقة

143
00:09:29,295 --> 00:09:35,985
بجميع الإجراءات المتعلقة بالمصادقة لتطبيق Angular.

144
00:09:35,985 --> 00:09:37,715
لذلك، ضمن خدمة المصادقة،

145
00:09:37,715 --> 00:09:40,760
ستلاحظ على الفور أن لدي

146
00:09:40,760 --> 00:09:45,545
مجموعة من المعلومات التي قمت بتكوينها هنا.

147
00:09:45,545 --> 00:09:47,985
نظرًا لأنك تعرف Angular بالفعل،

148
00:09:47,985 --> 00:09:52,535
يجب أن تكون قادرًا على معالجة كل ما هو مكتوب هنا بسهولة.

149
00:09:52,535 --> 00:09:57,355
لاحظ على وجه الخصوص أنه داخل خدمة المصادقة نفسها،

150
00:09:57,355 --> 00:09:59,240
أقوم بتخزين معلومات مثل،

151
00:09:59,240 --> 00:10:00,815
على سبيل المثال، TokenKey،

152
00:10:00,815 --> 00:10:06,985
وهو مفتاح التخزين المحلي حيث أقوم بتخزين JSON Web Token،

153
00:10:06,985 --> 00:10:11,500
وكذلك بعض المتغيرات الإضافية

154
00:10:11,500 --> 00:10:16,310
هنا حيث أتتبع اسم المستخدم وأين أنا ،

155
00:10:16,310 --> 00:10:21,955
وكذلك تتبع رمز JSON Web Token هنا.

156
00:10:21,955 --> 00:10:28,540
الآن، دعونا نبدأ بالنظر إلى عندما يقوم المستخدم بتسجيل الدخول.

157
00:10:28,540 --> 00:10:30,290
لذلك، عندما يقوم المستخدم بتسجيل الدخول،

158
00:10:30,290 --> 00:10:37,135
سيتم استدعاء هذه الوظيفة التي تسمى تسجيل الدخول في خدمة المصادقة لدينا هنا،

159
00:10:37,135 --> 00:10:40,350
وعندما يتم استدعاء تسجيل الدخول في خدمة المصادقة،

160
00:10:40,350 --> 00:10:44,730
سيتم تمرير هذا في معلمة تسمى المستخدم الذي يحتوي على

161
00:10:44,730 --> 00:10:49,665
اسم المستخدم وكلمة المرور كجزء من كائن جافا سكريبت المستخدم.

162
00:10:49,665 --> 00:10:57,890
لذلك، في هذه المرحلة، أفعل مشاركة هتب إلى باسيورل بالإضافة إلى المستخدمين/تسجيل الدخول.

163
00:10:57,890 --> 00:11:00,320
لاحظ أيضًا أنه هنا،

164
00:11:00,320 --> 00:11:06,030
أقوم بتوفير AuthResponse كمؤهل هنا.

165
00:11:06,030 --> 00:11:09,945
إن AuthResponse ليس سوى واجهة قمت بتطبيقها هنا،

166
00:11:09,945 --> 00:11:11,350
في الأعلى هنا.

167
00:11:11,350 --> 00:11:14,295
لذا، تحدد هذه الواجهة بشكل أساسي

168
00:11:14,295 --> 00:11:16,860
المعلومات التي ستعود

169
00:11:16,860 --> 00:11:19,670
كرد المصادقة الخاص بي من جانب الخادم،

170
00:11:19,670 --> 00:11:22,690
وهيكل بيانات JSON التي

171
00:11:22,690 --> 00:11:25,690
تعود من جانب الخادم وكائنات JavaScript المقابلة.

172
00:11:25,690 --> 00:11:28,865
لذلك، لاحظت أنه عندما قمنا بتحديث الخادم،

173
00:11:28,865 --> 00:11:32,370
تأكدنا من أن الخادم يقوم بإرسال الحالة

174
00:11:32,370 --> 00:11:37,035
والنجاح والعلامة والرمز المميز في فهرس السلسلة.

175
00:11:37,035 --> 00:11:42,000
لذلك، يتم الحصول على تلك المعلومات هنا.

176
00:11:42,000 --> 00:11:44,240
الآن، عندما أقوم بعمل مشاركة على ذلك،

177
00:11:44,240 --> 00:11:52,975
أقوم بتمرير اسم المستخدم وكلمة المرور إلى المشاركة على نقطة النهاية هذه /المستخدمين/تسجيل الدخول.

178
00:11:52,975 --> 00:11:58,375
عندما يعود الرد من الاستجابة،

179
00:11:58,375 --> 00:12:03,490
فإن رسالة الاستجابة نفسها سوف تحتوي، كما رأينا،

180
00:12:03,490 --> 00:12:06,525
على النجاح، حقل الرمز المميز

181
00:12:06,525 --> 00:12:09,885
، وكذلك رسالة الحالة هنا.

182
00:12:09,885 --> 00:12:11,950
لذا، من رسالة الاستجابة،

183
00:12:11,950 --> 00:12:16,960
أقوم باستخراج الرمز المميز ثم تمريره إلى هذه الوظيفة التي أقوم بتطبيقها هنا،

184
00:12:16,960 --> 00:12:20,415
الوظيفة المحلية هنا، تسمى StoreUserCedencies.

185
00:12:20,415 --> 00:12:30,295
لذلك، سيتم إرجاع ذلك إلى طلبي وسيتم تخزينها في جانب العميل الخاص بي،

186
00:12:30,295 --> 00:12:32,220
في التخزين المحلي.

187
00:12:32,220 --> 00:12:34,545
ثم، من هذه الوظيفة،

188
00:12:34,545 --> 00:12:37,870
أعيد هذه المعلومات مرة أخرى إلى

189
00:12:37,870 --> 00:12:43,160
وظيفة الاستدعاء من حيث بدأت عملية تسجيل الدخول.

190
00:12:43,160 --> 00:12:51,610
لذا، بهذه الطريقة، سأشير إلى مكون تسجيل الدخول الخاص بي أن تسجيل الدخول كان ناجحًا،

191
00:12:51,610 --> 00:12:56,345
ثم سأقوم أيضًا بتمرير اسم المستخدم إلى مكون تسجيل الدخول الخاص بي،

192
00:12:56,345 --> 00:12:59,680
والذي سيقوم بعد ذلك بتمرير تلك المعلومات

193
00:12:59,680 --> 00:13:03,860
إلى مكون الرأس، ويستخدم مكون الرأس ذلك لتعكس اسم المستخدم

194
00:13:03,860 --> 00:13:08,830
على في الجزء العلوي هناك،

195
00:13:08,830 --> 00:13:11,145
وأيضا نحن التقاط الخطأ هنا.

196
00:13:11,145 --> 00:13:16,390
لذلك، هذا هو تنفيذ بسيط جدا لكيفية قيامنا بتسجيل الدخول.

197
00:13:16,390 --> 00:13:17,840
عند القيام بتسجيل الخروج،

198
00:13:17,840 --> 00:13:20,735
لاحظ ما أفعله عندما يقوم المستخدم باستدعاء تسجيل الخروج.

199
00:13:20,735 --> 00:13:22,070
عندما يقوم المستخدم باستدعاء الخروج،

200
00:13:22,070 --> 00:13:24,560
أقوم ببساطة بتدمير بيانات اعتماد المستخدم،

201
00:13:24,560 --> 00:13:26,845
والذي يتضمن التخلص من رمز

202
00:13:26,845 --> 00:13:33,085
JSON Web Token الذي حصلت عليه عند تسجيل الدخول إلى طلبي.

203
00:13:33,085 --> 00:13:37,010
ثم،

204
00:13:37,010 --> 00:13:40,920
يتم تسجيل بعض وظائف المساعد الإضافية التي قمت بتطبيقها هنا تسمى GetUsername في و GetToken،

205
00:13:40,920 --> 00:13:45,370
والتي ستكون مفيدة من تطبيقاتي

206
00:13:45,370 --> 00:13:50,140
الأخرى والمكونات والخدمات الأخرى.

207
00:13:50,140 --> 00:13:57,375
لذلك، الآن دعونا ننظر إلى بعض وظائف المساعد التي قمنا بتنفيذها هنا.

208
00:13:57,375 --> 00:14:04,685
لذلك، سيقوم LoadUserCredencies باسترداد بيانات الاعتماد من التخزين المحلي.

209
00:14:04,685 --> 00:14:10,800
لذلك، لاحظت أن هنا أنا استدعاء لوكالستوراج ومن ثم أقول جيتيتم.

210
00:14:10,800 --> 00:14:12,750
لذلك، يستخدم LocalStorage هنا

211
00:14:12,750 --> 00:14:17,305
التخزين المحلي لمتصفح الويب المدعوم من قبل متصفحات الويب القياسية،

212
00:14:17,305 --> 00:14:19,140
وتخزين المعلومات هناك،

213
00:14:19,140 --> 00:14:21,620
ومن ثم يتم استرداد هذه المعلومات هناك.

214
00:14:21,620 --> 00:14:23,830
ثم، من هناك، معلومات الاعتماد،

215
00:14:23,830 --> 00:14:25,745
إذا كانت صالحة،

216
00:14:25,745 --> 00:14:27,950
ثم سيتم إعداد بيانات الاعتماد هذه هنا.

217
00:14:27,950 --> 00:14:32,735
لذلك، سيتم تهيئة جميع هذه المتغيرات التي قمت بتعريفها هنا مع

218
00:14:32,735 --> 00:14:38,965
المعلومات المناسبة بعد استردادها من LocalStorage.

219
00:14:38,965 --> 00:14:42,560
الآن، وبالمثل، يتم استدعاء وظيفة StoreUserCedencies

220
00:14:42,560 --> 00:14:46,285
التي قمت بتطبيقها هنا من طريقة تسجيل الدخول.

221
00:14:46,285 --> 00:14:50,165
عندما يتم تمرير هذه المعلومات في،

222
00:14:50,165 --> 00:14:52,290
يتم تمرير معلومات الاعتماد في،

223
00:14:52,290 --> 00:14:57,665
يتم تخزين هذه المعلومات في التخزين المحلي في هذه المرحلة مع هذا المفتاح.

224
00:14:57,665 --> 00:15:00,825
ثم، يقوم UsecRedentials بشكل أساسي

225
00:15:00,825 --> 00:15:05,510
بإعداد جميع المتغيرات التي لدي في خدمة المصادقة.

226
00:15:05,510 --> 00:15:07,285
لذلك، فإنه يقوم بإعداد الرمز المميز،

227
00:15:07,285 --> 00:15:09,225
فإنه يقوم بإعداد اسم المستخدم،

228
00:15:09,225 --> 00:15:14,270
ثم يقوم بإعداد وظيفة IsAuthenticated هنا.

229
00:15:14,270 --> 00:15:17,590
لذلك، لاحظ أن اسم المستخدم نفسه هنا،

230
00:15:17,590 --> 00:15:20,865
لقد أعلنت أنه موضوع،

231
00:15:20,865 --> 00:15:23,595
وهو ليس سوى ملاحظة هنا.

232
00:15:23,595 --> 00:15:27,410
لذلك، هذا هو السبب عندما أقول،

233
00:15:27,410 --> 00:15:30,705
سيندوسرنر هنا، أقول بيانات الاعتماد اسم المستخدم.

234
00:15:30,705 --> 00:15:34,780
لذا، تم تنفيذ هذا SendUsername في الأعلى هنا،

235
00:15:34,780 --> 00:15:40,080
لاحظ أن هذا هو المكان الذي يتم فيه إرسال القيمة القابلة للملاحظة مرة أخرى.

236
00:15:40,080 --> 00:15:43,305
لذلك، هذا هو السبب في أنني أقول هذا اسم المستخدم بعد ذلك.

237
00:15:43,305 --> 00:15:45,370
لذلك، يمكن ملاحظتها.

238
00:15:45,370 --> 00:15:49,630
سيتم إرسال الاسم الذي يتم توفيره

239
00:15:49,630 --> 00:15:55,130
كمعلمة إلى كل من قام بتسجيل نفسه لمراقبة هذا يمكن ملاحظته.

240
00:15:55,130 --> 00:15:59,070
لذلك هذا يمكن ملاحظته، أنا ذاهب لمراقبة هذا من

241
00:15:59,070 --> 00:16:03,980
مكون رأس بلدي وبهذه الطريقة كلما تغير اسم المستخدم،

242
00:16:03,980 --> 00:16:09,870
إما من غير معرفة إلى اسم مستخدم معين أو العكس،

243
00:16:09,870 --> 00:16:13,040
ثم يمكنني تحديث شريط الأدوات الخاص بي في

244
00:16:13,040 --> 00:16:17,670
مكون الرأس لتعكس ما إذا كان المستخدم قد تم تسجيل الدخول أو تسجيل الخروج.

245
00:16:17,670 --> 00:16:21,770
بحيث يتم إعداد ذلك باستخدام هذا أوسيكردنتينالز.

246
00:16:21,770 --> 00:16:29,010
الآن يقوم DestroyUserCedentials بتعيين رمز المصادقة إلى غير محدد.

247
00:16:29,010 --> 00:16:34,320
يقوم بمسح اسم المستخدم ثم يقوم بتعيين IsAuthenticated إلى false ثم

248
00:16:34,320 --> 00:16:37,560
يزيل هذه المعلومات من متجري المحلي

249
00:16:37,560 --> 00:16:40,930
لذلك يتم التخلص من jsonwebtoken في هذا الجزء.

250
00:16:40,930 --> 00:16:43,330
لذلك هذا هو كيف تحب المستخدم.

251
00:16:43,330 --> 00:16:47,150
لذلك بمجرد فقدان jsonwebtoken، لم يعد بإمكان المستخدم

252
00:16:47,150 --> 00:16:49,850
مصادقة نفسه أو نفسها

253
00:16:49,850 --> 00:16:53,305
على جانب الخادم لأن الرمز المميز لم يعد متاحًا لنا.

254
00:16:53,305 --> 00:16:58,340
لذلك هذه هي الطريقة التي ننفذ بها وظيفة الخروج داخل تطبيقنا.

255
00:16:58,340 --> 00:17:01,030
لذا خذ بعض الوقت للذهاب من خلال

256
00:17:01,030 --> 00:17:05,350
auth.service هنا لمعرفة كيف قمت بتنفيذ الوظائف المختلفة.

257
00:17:05,350 --> 00:17:06,865
الآن، بحلول هذا الوقت،

258
00:17:06,865 --> 00:17:13,190
أنا متأكد من أنك على دراية كبيرة بكيفية تنفيذ تطبيقات Angular،

259
00:17:13,190 --> 00:17:17,960
لذلك لا ينبغي أن يكون من الصعب عليك فهم كيفية تنفيذ هذا الرمز.

260
00:17:17,960 --> 00:17:24,575
الآن وظيفة واحدة أخرى أود أن ألفت انتباهكم إليها هي رمز JWT الاختيار، هنا.

261
00:17:24,575 --> 00:17:29,040
يمكن استدعاء هذه الوظيفة في أي نقطة للتحقق

262
00:17:29,040 --> 00:17:33,360
والتأكد من أن رمز ويب JSON الخاص بنا لا يزال صالحًا.

263
00:17:33,360 --> 00:17:40,500
لذلك هذا هو المكان الذي أرسل فيه طلب الحصول على المستخدمين شرطة مائلة تحقق JWT الرمز المميز.

264
00:17:40,500 --> 00:17:49,450
أذكر أننا نفذنا هذا الطريق على جانب الخادم في user.js و.

265
00:17:49,450 --> 00:17:55,385
لذلك من هناك سنكون قادرين على التحقق مما إذا كان jsonwebtoken لا يزال صالحًا أم لا.

266
00:17:55,385 --> 00:17:57,855
إذا كان jsonwebtoken غير صالح،

267
00:17:57,855 --> 00:17:59,170
فسنقوم

268
00:17:59,170 --> 00:18:03,045
بتدمير بيانات اعتماد المستخدم ثم نتوقع من المستخدم تسجيل الدخول مرة أخرى.

269
00:18:03,045 --> 00:18:06,550
إذا كان jsonwebtoken صالحًا، فلا بأس

270
00:18:06,550 --> 00:18:10,375
ويمكننا المضي قدمًا في السماح للمستخدم

271
00:18:10,375 --> 00:18:14,540
بالتعرف على أننا قمنا بتسجيل الدخول. لذلك حتى إذا قمت بإغلاق

272
00:18:14,540 --> 00:18:18,665
المتصفح الخاص بك ثم إعادة فتح المتصفح ثم إعادة فتح تطبيق Angular الخاص بك،

273
00:18:18,665 --> 00:18:26,625
إذا قمت بتسجيل الدخول في وقت سابق تم حفظ jsonwebtoken في التخزين المحلي،

274
00:18:26,625 --> 00:18:28,930
ويمكن استرجاعها من هناك ومن ثم

275
00:18:28,930 --> 00:18:33,740
سيتم استعادة حالة تسجيل الدخول الخاصة بك داخل تطبيق Angular الخاص بك.

276
00:18:33,740 --> 00:18:36,420
إذا انتهت صلاحية رمز ويب json،

277
00:18:36,420 --> 00:18:38,635
فلن يُسمح لنا بتسجيل الدخول.

278
00:18:38,635 --> 00:18:44,280
لذلك في كل مرة تقوم فيها بتحديث تطبيق Angular الخاص بك في متصفحك أو

279
00:18:44,280 --> 00:18:47,290
إعادة تحميل تطبيق Angular الخاص بك في متصفحك، ستقوم

280
00:18:47,290 --> 00:18:50,550
بالتحقق من jsonwebtoken للتأكد من أنه لا يزال صالحًا.

281
00:18:50,550 --> 00:18:53,095
إذا لم يكن صالحًا، فسيتم

282
00:18:53,095 --> 00:18:56,200
مسح المستخدم وبالتالي سيتعين عليك تسجيل الدخول مرة أخرى.

283
00:18:56,200 --> 00:19:00,370
إذا لم يكن الأمر كذلك، فسيتم استرداد معلومات المستخدم الذي قام بتسجيل الدخول

284
00:19:00,370 --> 00:19:05,020
من LocalStorage ثم تهيئتها داخل تطبيق Angular الخاص بي.

285
00:19:05,020 --> 00:19:09,765
بشكل دوري، إذا كان الخادم

286
00:19:09,765 --> 00:19:15,575
يستجيب في أي وقت برسالة 401 غير مصرح بها،

287
00:19:15,575 --> 00:19:16,880
حتى في هذه المرحلة،

288
00:19:16,880 --> 00:19:22,045
سنقوم مرة أخرى بالتراجع لمعرفة أن jsonwebtoken صالح ومن ثم السماح بذلك.

289
00:19:22,045 --> 00:19:26,960
سنفعل ذلك باستخدام شيء يسمى اعتراضات هتب.

290
00:19:26,960 --> 00:19:30,630
اسمحوا لي أن تأخذ جولة في ذلك الجزء من التعليمات البرمجية،

291
00:19:30,630 --> 00:19:35,180
ومن ثم شرح لكم كيف يعمل المعترضون في فترة قصيرة.

292
00:19:35,180 --> 00:19:38,635
حتى الآن بالإضافة إلى AuthService،

293
00:19:38,635 --> 00:19:45,545
في مجلد الخدمات نفسه سترى هذا الملف يسمى ملف AuthInterceptors.ts.

294
00:19:45,545 --> 00:19:51,285
لذا افتح هذا وسترى أنه هنا قمت بتنفيذ اعتراضات Http.

295
00:19:51,285 --> 00:19:54,435
الآن ما تفعله أجهزة اعتراض Http هذه،

296
00:19:54,435 --> 00:20:00,780
يتم دعم هذا مع عميل Http الذي يأتي كجزء من Angular 4.4.

297
00:20:00,780 --> 00:20:04,080
ما يفعله اعتراض http هو أنه يمكنهم اعتراض

298
00:20:04,080 --> 00:20:06,180
رسائل الطلبات الصادرة إجراء

299
00:20:06,180 --> 00:20:09,695
تعديلات على رسالة الطلب قبل إرسالها.

300
00:20:09,695 --> 00:20:13,530
وبالمثل، يمكنهم اعتراض رسائل الاستجابة الواردة ثم تعديل

301
00:20:13,530 --> 00:20:15,660
رسالة الاستجابة الواردة قبل

302
00:20:15,660 --> 00:20:18,970
تسليم الاستجابة إلى تطبيق Angular.

303
00:20:18,970 --> 00:20:22,920
إذن من خلال الإعتراض، كيف يعمل هذا المُعترض؟

304
00:20:22,920 --> 00:20:25,625
لذلك لجعل هذا العمل اعتراض،

305
00:20:25,625 --> 00:20:28,620
ونحن تنفيذ، كما ترون،

306
00:20:28,620 --> 00:20:37,285
فئة تسمى هتبنتر سيبتور من خلال توسيع هتبنتر سيبتور.

307
00:20:37,285 --> 00:20:39,805
حتى هنا لقد نفذت أوثينتيرسيبتور.

308
00:20:39,805 --> 00:20:42,175
إذن ماذا يفعل هذا AuthInterceptor؟

309
00:20:42,175 --> 00:20:47,660
هذا AuthInterCeptor هو أساسا التقاط الطلبات الصادرة.

310
00:20:47,660 --> 00:20:51,785
لذلك لالتقاط طلب صادر يمكنك استدعاء هذه الوظيفة تسمى اعتراض

311
00:20:51,785 --> 00:20:56,700
ومن ثم هذا سوف تعطيك الوصول إلى الطلب والقادم.

312
00:20:56,700 --> 00:21:00,550
حتى تتمكن من سلسلة في

313
00:21:00,550 --> 00:21:05,080
مجموعة من اعتراضات واحد وراء الآخر إذا اخترت ذلك،

314
00:21:05,080 --> 00:21:11,050
حتى يتمكنوا من معالجة الطلبات الصادرة واحدا تلو الآخر إذا اخترت ذلك.

315
00:21:11,050 --> 00:21:20,260
ما يفعله هذا الاعتراض هو أنه يمنحك الوصول إلى رسالة طلب Http.

316
00:21:20,260 --> 00:21:23,300
لذلك عندما أحصل على الوصول إلى رسالة طلب هتب،

317
00:21:23,300 --> 00:21:27,810
ستلاحظ أن هنا أنا حقن خدمة المصادقة.

318
00:21:27,810 --> 00:21:33,870
الآن على عكس الطريقة التي كنا حقن الخدمات في المكونات،

319
00:21:33,870 --> 00:21:37,295
وهنا أنا تظهر استخدام حاقن.

320
00:21:37,295 --> 00:21:39,995
الحاقن هو جزء من رمز الزاوي.

321
00:21:39,995 --> 00:21:44,080
لذلك باستخدام حاقن يمكنك حقن الخدمات أو

322
00:21:44,080 --> 00:21:50,020
المكونات الأخرى في خدمات أو مكونات أخرى.

323
00:21:50,020 --> 00:21:57,495
حتى هنا ترى أنني حقن خدمة المصادقة هنا باستخدام هذا.

324
00:21:57,495 --> 00:22:04,690
الآن سبب آخر هو أنه إذا قمت بحقن الخدمة مباشرة في منشئ بلدي،

325
00:22:04,690 --> 00:22:11,545
فإنه سيتم تطوير تبعية دائرية بين المعترض و AuthService،

326
00:22:11,545 --> 00:22:15,200
وهذا سيؤدي إلى عدم عمل التعليمات البرمجية الخاصة بك.

327
00:22:15,200 --> 00:22:18,190
لذلك هذا هو العمل حول المشاكل.

328
00:22:18,190 --> 00:22:21,430
حتى أن اعتراضك - لأنني بحاجة إلى

329
00:22:21,430 --> 00:22:25,810
أوثسرفيس، من أجل الحصول على عقد من الرمز المميز من

330
00:22:25,810 --> 00:22:31,680
أوثسيرفيس و أوثسرفيس بدوره يعتمد على هذا اعتراض لذلك

331
00:22:31,680 --> 00:22:38,760
لهذا السبب من أجل كسر حلقة أنا صراحة حقن أوثسرفيس في هذه الحالة.

332
00:22:38,760 --> 00:22:42,630
الآن هذا شيء قد أحسب من خلال التجربة

333
00:22:42,630 --> 00:22:47,080
والخطأ ذهبت في البداية إلى الأمام وحقن ببساطة

334
00:22:47,080 --> 00:22:49,600
الخدمات الفردية إلى المنشئ ثم وجدت أن

335
00:22:49,600 --> 00:22:54,270
Angular لم يكن يقوم بتجميع التعليمات البرمجية ثم اكتشفت أن

336
00:22:54,270 --> 00:23:01,510
هناك خطأ هناك ثم بعد إجراء بعض بحث Google

337
00:23:01,510 --> 00:23:05,330
أن هذه طريقة بديلة للتعامل مع

338
00:23:05,330 --> 00:23:09,620
نفس الشيء وهذا يعمل بشكل أفضل بكثير لتطبيقنا.

339
00:23:09,620 --> 00:23:13,560
لذلك بمجرد حقن AuthService من الخدمة أحصل على

340
00:23:13,560 --> 00:23:17,555
عقد من الرمز المميز ثم لاحظ ما أفعله هنا.

341
00:23:17,555 --> 00:23:23,200
هنا أقول استنساخ كونست المصادقة ريك استنساخ.

342
00:23:23,200 --> 00:23:29,380
لذلك سنقوم باستنساخ الطلب ومن ثم سنقوم بإعداد في الرؤوس.

343
00:23:29,380 --> 00:23:32,110
لذلك سنقول رؤوس req تعيين

344
00:23:32,110 --> 00:23:35,240
التفويض ثم لاحظ ما أقوم

345
00:23:35,240 --> 00:23:38,005
بإعداد رأس التفويض ليكون، حامل.

346
00:23:38,005 --> 00:23:42,100
زائد أوثتوكين.

347
00:23:42,100 --> 00:23:47,360
لذلك في رأس التفويض أقوم بإعداد حامل و AuthToken هنا.

348
00:23:47,360 --> 00:23:49,550
إذن هذه هي الطريقة التي أقوم بها بإعداد

349
00:23:49,550 --> 00:23:53,080
رأس التفويض في

350
00:23:53,080 --> 00:23:57,465
رسالة الطلب الصادرة في تطبيق Angular الخاص بي. لذا هناك

351
00:23:57,465 --> 00:24:01,660
وبهذه الطريقة تأكدت من أن جميع الطلبات الصادرة سيتم

352
00:24:01,660 --> 00:24:06,645
إعداد رأس التفويض قبل تمريرها إلى جانب الخادم.

353
00:24:06,645 --> 00:24:12,775
وبعد ذلك، سنقوم ببساطة بتمريره إلى المعترض التالي، إذا كان موجودًا،

354
00:24:12,775 --> 00:24:15,140
أو إلى قائمة الانتظار الصادرة،

355
00:24:15,140 --> 00:24:19,935
بحيث يتم إرسال رسالة الطلب إلى جانب الخادم.

356
00:24:19,935 --> 00:24:24,830
وبالمثل، لدي اعتراض آخر قمت بتنفيذه هنا.

357
00:24:24,830 --> 00:24:30,260
يعترض هذا الاعتراض أي رسائل رد غير مصرح بها

358
00:24:30,260 --> 00:24:31,800
التي تعود من جانب الخادم.

359
00:24:31,800 --> 00:24:37,150
لذلك، إذا كان الخادم الردود مع 401 رسالة رد غير مصرح به.

360
00:24:37,150 --> 00:24:39,550
حتى في هذه المرحلة مرة أخرى، نفس الشيء،

361
00:24:39,550 --> 00:24:42,760
لقد قمت بإعداد أوثسيرفيس هنا،

362
00:24:42,760 --> 00:24:46,410
وبعد ذلك، داخل هنا ثم سأقول،

363
00:24:46,410 --> 00:24:49,060
لا التعامل مع إذا كان الخطأ.

364
00:24:49,060 --> 00:24:54,800
لذلك هذا هو المكان الذي سوف تحصل على عقد من هتبفنت هنا.

365
00:24:54,800 --> 00:25:04,580
و هتبفينت هو كائن مستوى أقل من الطلب،

366
00:25:04,580 --> 00:25:08,630
ولكن هذا يسمح لنا بالوصول إلى رسالة الرد الواردة،

367
00:25:08,630 --> 00:25:12,530
وبعد ذلك سوف نتحقق لمعرفة ما إذا كان هناك خطأ،

368
00:25:12,530 --> 00:25:17,235
وبعد ذلك إذا كان الخطأ هو مثيل استجابة خطأ هتب،

369
00:25:17,235 --> 00:25:20,770
وإذا كانت حالة الخطأ 401.

370
00:25:20,770 --> 00:25:28,220
مما يعني أنني قد اكتشفت للتو أن الخادم أرسل رسالة خطأ 401.

371
00:25:28,220 --> 00:25:32,305
لذلك مما يعني أن هناك بعض مشكلة التفويض على جانب الخادم.

372
00:25:32,305 --> 00:25:33,790
ثم في هذه المرحلة سوف تحقق

373
00:25:33,790 --> 00:25:37,620
من رمز ويب جسون للتأكد من أن رمز ويب جسون لا يزال صالحا.

374
00:25:37,620 --> 00:25:39,030
إذا لم يكن

375
00:25:39,030 --> 00:25:44,910
صالحًا، فسأتجاهل بيانات الاعتماد الخاصة بي وأتوقع من المستخدم تسجيل الدخول مرة أخرى.

376
00:25:44,910 --> 00:25:48,880
وبهذه الطريقة، سأتأكد من أنه إذا

377
00:25:48,880 --> 00:25:53,480
انتهت صلاحية رمز الويب الخاص بي json في عملية محاولة جلب البيانات،

378
00:25:53,480 --> 00:25:58,045
فسيظل ذلك يتم اعتراضه هنا لأنه إذا كان الخادم يستجيب بـ 401،

379
00:25:58,045 --> 00:26:00,280
فسوف أعترض ذلك ثم قم بمسح

380
00:26:00,280 --> 00:26:03,830
رمز الويب الخاص بي json وأتوقع من المستخدم تسجيل الدخول مرة أخرى.

381
00:26:03,830 --> 00:26:08,750
يمكننا أيضًا إعادة توجيه المستخدم إلى صفحة تسجيل الدخول إذا كنت تريد ذلك،

382
00:26:08,750 --> 00:26:12,330
ولكن مع تطبيق Angular، يكون الأمر أكثر تعقيدًا قليلاً

383
00:26:12,330 --> 00:26:16,275
للقيام بذلك ولم أكن أرغب في إرباكك عن طريق القيام بكل ذلك.

384
00:26:16,275 --> 00:26:19,385
بدلا من ذلك، أنا ببساطة تسجيل الخروج من

385
00:26:19,385 --> 00:26:22,500
المستخدم في هذه المرحلة ومن ثم تدمير بيانات اعتماد المستخدم،

386
00:26:22,500 --> 00:26:25,855
بحيث يتوقع من المستخدم تسجيل الدخول في هذه المرحلة.

387
00:26:25,855 --> 00:26:33,880
لذلك، معالجة بسيطة لكيفية حقن رأس التفويض في الطلب الصادر،

388
00:26:33,880 --> 00:26:38,850
وأيضا اعتراض أي 401 رسائل غير مصرح بها

389
00:26:38,850 --> 00:26:40,820
التي تعود من جانب الخادم.

390
00:26:40,820 --> 00:26:45,860
لذلك، ترى كيف يجب إجراء هذه التغييرات الإضافية على

391
00:26:45,860 --> 00:26:51,955
تطبيق Angular الخاص بك لجعله يعمل مع جانب الخادم الخاص بك.

392
00:26:51,955 --> 00:26:55,125
مع تعيين جزء المصادقة،

393
00:26:55,125 --> 00:26:58,200
إذا لم يكن لديك مصادقة وإذا كنت ستصل فقط إلى

394
00:26:58,200 --> 00:27:02,485
بقية نقاط نهاية واجهة برمجة التطبيقات والحصول على عمليات،

395
00:27:02,485 --> 00:27:05,240
فلا داعي للقلق حتى بشأن أي من هذه الأشياء.

396
00:27:05,240 --> 00:27:06,790
لا توجد مصادقة مطلوبة.

397
00:27:06,790 --> 00:27:09,140
يمكن جلب البيانات بسهولة جدا.

398
00:27:09,140 --> 00:27:10,590
ولكن بالنسبة لأي وظيفة،

399
00:27:10,590 --> 00:27:12,395
وضع وحذف العمليات،

400
00:27:12,395 --> 00:27:15,630
نحتاج إلى دعم كل هذه الميزات.

401
00:27:15,630 --> 00:27:21,375
لذلك هذا هو السبب في أنني نفذت جزء المصادقة في طلبي.

402
00:27:21,375 --> 00:27:23,995
كما أوضحت سابقًا،

403
00:27:23,995 --> 00:27:26,985
عندما لا يتم تسجيل دخول أي مستخدم،

404
00:27:26,985 --> 00:27:32,570
فلن نتمكن من الانتقال إلى نقطة النهاية المفضلة،

405
00:27:32,570 --> 00:27:35,035
ولكن عندما يتم تسجيل دخول المستخدم،

406
00:27:35,035 --> 00:27:40,420
سنكون قادرين على رؤية المفضلة للمستخدم المحدد.

407
00:27:40,420 --> 00:27:45,095
يتم تنفيذ ذلك باستخدام حراس الطريق في Angular.

408
00:27:45,095 --> 00:27:47,995
الآن لتنفيذ حراس الطريق هذه،

409
00:27:47,995 --> 00:27:52,080
لقد نفذت خدمة أخرى هنا تسمى AuthGuardService.

410
00:27:52,080 --> 00:27:54,170
لذلك في هذا AuthGuardService،

411
00:27:54,170 --> 00:27:57,970
قمنا بتنفيذ هذه الطريقة التي تسمى طريقة CanActivate والتي

412
00:27:57,970 --> 00:28:02,225
سنقوم بتصنيفها الفرعي من أجل تنفيذ ذلك.

413
00:28:02,225 --> 00:28:05,705
وفي طريقة CanActivate،

414
00:28:05,705 --> 00:28:08,550
سيعود التنفيذ منطقيًا،

415
00:28:08,550 --> 00:28:10,090
وفي هذه الحالة،

416
00:28:10,090 --> 00:28:15,630
ما نتحقق منه هو إذا تم تسجيل دخول هذا المستخدم،

417
00:28:15,630 --> 00:28:18,605
فسنسمح للمستخدم بالتنقل.

418
00:28:18,605 --> 00:28:25,480
وإلا، سوف تنقل المستخدم إلى نقطة النهاية الرئيسية.

419
00:28:25,480 --> 00:28:31,175
لذلك هذه هي الطريقة التي يتم بها تنفيذ حارس الطريق في هذه الحالة.

420
00:28:31,175 --> 00:28:33,955
الآن، للاستفادة من حارس الطريق هذا،

421
00:28:33,955 --> 00:28:41,780
سنذهب لنرى كيف يتم تحديث الطرق للاستفادة من حراس الطريق.

422
00:28:41,780 --> 00:28:44,520
حتى في ملف routes.ts،

423
00:28:44,520 --> 00:28:50,435
يمكنك أن ترى أنه بالنسبة لمكون المفضلة،

424
00:28:50,435 --> 00:28:54,510
نرى أننا نحدد المسار كمفضلة والمكون كـ

425
00:28:54,510 --> 00:28:58,620
favoritesComponent ثم نحدد هذا الحقل الآخر

426
00:28:58,620 --> 00:29:07,785
يسمى CanActivative الذي حددنا AuthGuard كمعلمة هنا،

427
00:29:07,785 --> 00:29:12,445
وهذا AuthGuard ليست سوى خدمة AuthGuard التي قمنا بتنفيذها،

428
00:29:12,445 --> 00:29:14,825
والتي يتم استيرادها هنا.

429
00:29:14,825 --> 00:29:20,405
لذا بهذه الطريقة عندما يتم تقييم AuthGuard إلى false،

430
00:29:20,405 --> 00:29:24,755
فلن يُسمح لك بالانتقال إلى المكون المفضل،

431
00:29:24,755 --> 00:29:28,105
بدلاً من ذلك، سيتم إعادة توجيهك إلى المنزل،

432
00:29:28,105 --> 00:29:36,245
ولكن عندما يتم تسجيل دخول المستخدم، فمن الواضح أن AuthGuard سيقيم إلى true

433
00:29:36,245 --> 00:29:37,390
، وفي هذه الحالة،

434
00:29:37,390 --> 00:29:41,665
ستتمكن من للانتقال إلى مسار المفضلة هناك.

435
00:29:41,665 --> 00:29:49,700
الآن أيضا وبالمثل هناك تعديلات طفيفة على المكونات المتبقية في هناك،

436
00:29:49,700 --> 00:29:52,200
والتي تسمح لك للتعامل مع

437
00:29:52,200 --> 00:29:57,365
تعقيدات كيفية العميل والخادم الخاص بك سوف نتحدث مع بعضها البعض. على

438
00:29:57,365 --> 00:30:02,555
وجه الخصوص، لاحظ كيف تم تحديث مكون الرأس

439
00:30:02,555 --> 00:30:08,195
لتعكس حالة تسجيل الدخول للمستخدم في شريط الأدوات في الأعلى.

440
00:30:08,195 --> 00:30:11,500
هذا هو مرة أخرى تغيير آخر مثير للاهتمام

441
00:30:11,500 --> 00:30:15,710
قمت به إلى مكون الرأس في طلبنا.

442
00:30:15,710 --> 00:30:20,220
لذا سأترك ذلك كممارسة لك لمعرفة كيف تم تنفيذ ذلك.

443
00:30:20,220 --> 00:30:22,160
رمز بسيط جدا هناك.

444
00:30:22,160 --> 00:30:24,660
يجب أن يكون من السهل عليك أن تكتشف ذلك

445
00:30:24,660 --> 00:30:28,020
لذلك مع كل هذه التغييرات، الآن،

446
00:30:28,020 --> 00:30:32,095
العميل الزاوي قادر على التفاعل مع الخادم الخاص بي.

447
00:30:32,095 --> 00:30:36,540
اسمحوا لي أن تظهر لك مرة أخرى كيف يمكننا نشر بعض التعليقات على الخادم،

448
00:30:36,540 --> 00:30:41,995
ومن ثم نرى التعليق ينعكس على الفور في الطبق.

449
00:30:41,995 --> 00:30:45,325
لذلك، مرة أخرى العودة إلى طلبنا،

450
00:30:45,325 --> 00:30:50,050
يمكننا الآن الذهاب إلى القائمة ومن ثم سحب ما يصل أي طبق هنا،

451
00:30:50,050 --> 00:30:52,740
ويمكنني نشر التعليقات على الطبق هنا،

452
00:30:52,740 --> 00:30:59,600
لذلك أود أن إعداد على الفور تصنيف هنا،

453
00:30:59,600 --> 00:31:02,540
وقيمة تعليقي هنا.

454
00:31:03,540 --> 00:31:06,700
لاحظ أنني لا

455
00:31:06,700 --> 00:31:15,735
أدخل اسم المستخدم الخاص بي أو اسم المؤلف الخاص بي هنا في النموذج هنا.

456
00:31:15,735 --> 00:31:18,470
الآن بالطبع، من أجل تقديم تعليق،

457
00:31:18,470 --> 00:31:19,590
تحتاج إلى تسجيل الدخول.

458
00:31:19,590 --> 00:31:24,520
حتى إذا لم يتم تسجيل الدخول في هذا التعليق لن يتم قبوله من قبل الخادم الخاص بي.

459
00:31:24,520 --> 00:31:26,935
لذلك اسمحوا لي أولا تسجيل نفسي في.

460
00:31:26,935 --> 00:31:32,890
حتى أتمكن من تسجيل الدخول هنا.

461
00:31:32,890 --> 00:31:34,220
وفي اللحظة التي أقوم فيها بتسجيل الدخول،

462
00:31:34,220 --> 00:31:39,255
تلاحظ على الفور أنه يتم تحديث شريط أدوات الرأس للإشارة إلى حالتي.

463
00:31:39,255 --> 00:31:41,375
الآن يمكنني نشر هذا التعليق.

464
00:31:41,375 --> 00:31:43,990
وستلاحظ أنه عند نشر التعليق،

465
00:31:43,990 --> 00:31:46,440
يتم إضافة التعليق إلى قائمة التعليقات،

466
00:31:46,440 --> 00:31:50,575
وتلاحظ أيضًا أن حقل المؤلف يتم ملؤه تلقائيًا هنا.

467
00:31:50,575 --> 00:31:54,040
لأن هذه هي الطريقة التي نقوم بها بإعداد جانب الخادم الخاص بنا.

468
00:31:54,040 --> 00:31:55,570
في حقل التعليقات،

469
00:31:55,570 --> 00:31:58,880
قمنا بإعداد مستخدمنا

470
00:31:58,880 --> 00:32:05,890
كمرجع إلى معلومات المستخدم

471
00:32:05,890 --> 00:32:09,755
التي نقوم بتخزينها في جانب الخادم الخاص بنا، وبما أننا نستخدم ملء،

472
00:32:09,755 --> 00:32:11,585
Mongoose Populate على جانب الخادم،

473
00:32:11,585 --> 00:32:14,080
يتم ملء معلومات المستخدم تلقائيًا

474
00:32:14,080 --> 00:32:16,715
في التعليقات الواردة من الخادم الجانب.

475
00:32:16,715 --> 00:32:21,130
لذا، هذه هي الطريقة التي تلاحظ بها كيف يمكنني الاستفادة

476
00:32:21,130 --> 00:32:25,615
من ما يقدمه الخادم بالفعل بالنسبة لي لملء التفاصيل تلقائيًا.

477
00:32:25,615 --> 00:32:31,180
لذلك، تغييرات طفيفة مرة أخرى حتى

478
00:32:31,180 --> 00:32:38,880
في صفحة تفاصيل الطبق لتعكس استخدام دعم التعليقات على جانب الخادم.

479
00:32:38,880 --> 00:32:43,769
مع هذا أكمل التوضيح السريع

480
00:32:43,769 --> 00:32:49,575
للعميل Angular الذي قمنا بتنفيذه كجزء من هذا التمرين.

481
00:32:49,575 --> 00:32:55,990
وآمل أن تذهب من خلال تفاصيل التعليمات البرمجية في العميل الزاوي أيضا،

482
00:32:55,990 --> 00:32:59,410
ومن ثم تعكس مرة أخرى على ما تعلمته في الدورة الزاوي ونرى

483
00:32:59,410 --> 00:33:03,105
كيف تمكننا التعديلات من تنفيذ

484
00:33:03,105 --> 00:33:06,350
في عميل الزاوي المعدل الذي أصبح الآن

485
00:33:06,350 --> 00:33:09,705
قادرا على التواصل مع الخادم و ثم دعم جميع الميزات

486
00:33:09,705 --> 00:33:17,310
التي كنا نعتزم تنفيذها في الأصل كجزء من كل من العميل وجانب الخادم.