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
предоставил в виде zip-файла в ресурсах упражнения под названием 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
если мы запустили команду yarn start,

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
в файле Promorouter для запроса получения, который мы получаем

48
00:03:32,360 --> 00:03:37,610
здесь, вместо того, чтобы делать промо-поиск с пустым объектом JavaScript,

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 с пустым объектом JavaScript вместо того, чтобы

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
Итак, зайдите в эти блюда. Find в методе get здесь,

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
Во-первых, позвольте мне обратить ваше внимание на метод get для Favoriterouter.route:dishid.

72
00:05:11,520 --> 00:05:17,405
Теперь я собираюсь использовать этот метод get, чтобы просто проверить, что

73
00:05:17,405 --> 00:05:25,460
конкретное блюдо с идентификатором блюда уже является любимым для пользователя.

74
00:05:25,460 --> 00:05:29,130
Итак, вместо того, чтобы просто говорить getoperation.suppored,

75
00:05:29,130 --> 00:05:36,165
я просто собираюсь использовать присутствие этой операции get, а затем мы скажем,

76
00:05:36,165 --> 00:05:47,500
favorites.findone, и мы скажем user: req.user. _id.

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, Content-Type,

87
00:07:17,230 --> 00:07:36,735
application/json, а затем мы вернем утверждение существует false.

88
00:07:36,735 --> 00:07:44,215
То, что мы указываем здесь, это то, что если они получают делается до этой конечной точки с идентификатором блюда,

89
00:07:44,215 --> 00:07:52,835
это существует флаг здесь будет установлен в истину, если это блюдо является частью моих любимых.

90
00:07:52,835 --> 00:07:55,290
Если это блюдо не является частью моего избранного,

91
00:07:55,290 --> 00:07:58,100
я установлю там флаг false.

92
00:07:58,100 --> 00:08:01,190
Итак, здесь вы видите, что, поскольку у меня нет фаворитов,

93
00:08:01,190 --> 00:08:04,770
поэтому существует автоматически false на данный момент.

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
списке его или ее избранного, поэтому он будет возвращать существует false здесь.

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 существует true.

111
00:09:36,670 --> 00:09:43,825
Таким образом, когда пользователь выполняет операцию get на этой конечной точке с

112
00:09:43,825 --> 00:09:52,015
/favorites/dishid, где идентификатор блюда поставляется в

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
Если ни один из фаворитов не существует для этого пользователя, то мы вернем существующее false.

116
00:10:05,775 --> 00:10:08,120
Аналогично, если фавориты существует

117
00:10:08,120 --> 00:10:12,320
, но это конкретное блюдо не существует в избранном, то мы вернем false, в

118
00:10:12,320 --> 00:10:13,910
противном случае мы вернем true.

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
нам нужно будет сделать переменную b, сохранить изменения.

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
мы просто сделали pasport.authenticate

185
00:15:07,470 --> 00:15:12,930
local здесь и мы проверили для оставшихся значений здесь.

186
00:15:12,930 --> 00:15:15,215
Теперь этот pasport.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
мы не будем делать паспорт.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
res и следующий здесь.

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
нет ошибки и третий параметр, называемый info,

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
подлинной ошибки, которая возникает в паспорте.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
и не только, что, когда мы вызываем этот паспорт.authenticate,

227
00:18:06,810 --> 00:18:10,220
нам также нужно передать в req

228
00:18:10,220 --> 00:18:15,080
, res, далее как три параметра к нему.

229
00:18:15,080 --> 00:18:20,130
Итак, это структура, когда вам нужно вызвать pasport.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
то пользователь здесь будет установлен в null в этом случае.

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
несанкционированный, а затем мы отправим обратно информацию об успехе false,

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
статус будет установлен Login Unsuccess, а

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:04,590
передам обратно как ошибку на мою клиентскую сторону.

268
00:21:04,590 --> 00:21:09,615
В противном случае часть

269
00:21:09,615 --> 00:21:15,355
обрабатывается как req.login.

270
00:21:15,355 --> 00:21:17,220
Итак, если это успешно,

271
00:21:17,220 --> 00:21:22,710
passport.authenticate мы добавим этот метод req.login пользователю.

272
00:21:22,710 --> 00:21:24,340
Таким образом, на данный момент,

273
00:21:24,340 --> 00:21:27,950
мы просто передадим в объект пользователя, который мы получили.

274
00:21:27,950 --> 00:21:31,055
Итак, если мы достигли этой точки,

275
00:21:31,055 --> 00:21:36,195
то это означает, что объект пользователя не является нулевым и также не произошло ошибки,

276
00:21:36,195 --> 00:21:40,090
так что это означает, что пользователь может войти в систему.

277
00:21:41,080 --> 00:21:44,550
Итак, мы скажем err,

278
00:21:48,960 --> 00:21:51,460
мы попытаемся войти в систему пользователя.

279
00:21:51,460 --> 00:21:58,000
Итак, мы скажем, если ошибка, а

280
00:21:58,000 --> 00:22:05,345
затем мы передадим обратно ту же информацию об ошибках, что мы сделали здесь.

281
00:22:05,345 --> 00:22:09,840
Так что в этом случае, если ошибка,

282
00:22:13,290 --> 00:22:19,430
то мы передадим код состояния как 401 и мы скажем, успех

283
00:22:19,430 --> 00:22:25,125
является ложным и статус как Логин Неуспешно,

284
00:22:25,125 --> 00:22:28,340
а затем информацию об ошибке,

285
00:22:29,280 --> 00:22:31,840
вместо информации,

286
00:22:31,840 --> 00:22:42,380
мы передадим в «Не удалось войти в систему пользователя».

287
00:22:42,380 --> 00:22:48,960
Таким образом, это сообщение, которое мы передадим обратно здесь, если произойдет ошибка.

288
00:22:48,960 --> 00:22:53,200
В противном случае, мы были бы внизу.

289
00:22:53,200 --> 00:22:55,960
Таким образом, на данный момент

290
00:22:55,960 --> 00:22:59,440
мы сможем сгенерировать токен.

291
00:22:59,440 --> 00:23:02,495
Итак, если мы дошли до этого момента, это

292
00:23:02,495 --> 00:23:06,370
означает, что пользователь успешно вошел в систему,

293
00:23:06,370 --> 00:23:08,430
и поэтому теперь мы можем сгенерировать токен.

294
00:23:08,430 --> 00:23:12,705
Итак, мы будем генерировать токен на основе идентификатора пользователя,

295
00:23:12,705 --> 00:23:18,350
а затем мы передадим токен обратно пользователю.

296
00:23:18,350 --> 00:23:21,635
Итак, здесь мы скажем токен var,

297
00:23:21,635 --> 00:23:30,730
а затем мы можем сказать res.statusCode 200, а затем res.json успех true,

298
00:23:30,730 --> 00:23:33,600
поэтому, что означает, что пользователь успешно вошел в систему.

299
00:23:33,600 --> 00:23:38,490
Таким образом, статус будет успешным.

300
00:23:38,490 --> 00:23:40,605
Затем третья часть,

301
00:23:40,605 --> 00:23:42,360
вместо ошибки,

302
00:23:42,360 --> 00:23:46,200
я передам токен обратно пользователю.

303
00:23:46,200 --> 00:23:48,760
Итак, мы скажем токен,

304
00:23:51,100 --> 00:23:54,675
этот токен, который мы только что получили ранее.

305
00:23:54,675 --> 00:24:01,030
Таким образом, этот токен будет передан в качестве свойства токена ответного сообщения.

306
00:24:01,030 --> 00:24:04,560
Итак, здесь, обратите внимание, что успех установлен в true, поэтому,

307
00:24:04,560 --> 00:24:08,340
что означает, что пользователь успешно вошел в систему,

308
00:24:08,340 --> 00:24:12,290
и поэтому пользователь может продолжить дальше на этом этапе.

309
00:24:12,290 --> 00:24:19,050
Это должно быть сделано внутри req.Login здесь.

310
00:24:19,820 --> 00:24:22,970
Итак, на этом этапе

311
00:24:22,970 --> 00:24:27,180
мы закроем req.Login.

312
00:24:27,180 --> 00:24:33,735
Итак, обратите внимание, что это внутри этого req.Login здесь.

313
00:24:33,735 --> 00:24:37,320
Итак, там, мы передадим эти трое назад.

314
00:24:37,320 --> 00:24:41,370
Итак, позвольте мне просто отстукнуть эти три строки.

315
00:24:41,720 --> 00:24:48,850
Таким образом, мы будем обрабатывать метод регистрации пользователя.

316
00:24:48,850 --> 00:24:52,230
Итак, опять же, просмотрев этот код еще раз.

317
00:24:52,230 --> 00:24:53,950
Итак, мы сделаем сообщение маршрутизатора,

318
00:24:53,950 --> 00:24:56,815
но вместо того, чтобы аутентифицировать паспорт прямо там,

319
00:24:56,815 --> 00:24:58,960
мы скажем req, res

320
00:24:58,960 --> 00:25:01,240
, next, а затем внутри,

321
00:25:01,240 --> 00:25:04,285
мы проведем аутентификацию для локального,

322
00:25:04,285 --> 00:25:06,560
и эта аутентификация пройдет обратно.

323
00:25:06,560 --> 00:25:09,250
Таким образом, мы можем предоставить функцию обратного вызова,

324
00:25:09,250 --> 00:25:11,810
и эта функция обратного вызова вернет либо ошибку,

325
00:25:11,810 --> 00:25:14,730
пользователя, либо информацию здесь.

326
00:25:14,730 --> 00:25:16,300
Итак, если это ошибка,

327
00:25:16,300 --> 00:25:20,735
мы просто позволим обработчику экспресс-ошибок позаботиться об этом.

328
00:25:20,735 --> 00:25:22,730
Если пользователь имеет значение null,

329
00:25:22,730 --> 00:25:26,940
то это означает, что вход пользователя был неудачным,

330
00:25:26,940 --> 00:25:29,730
и причина этого будет в информации.

331
00:25:29,730 --> 00:25:36,870
Таким образом, это будет передаваться в качестве информационной ошибки в ответном сообщении здесь.

332
00:25:36,870 --> 00:25:38,790
Если мы подойдем к этому моменту,

333
00:25:38,790 --> 00:25:43,555
то пользователь успешно проверен.

334
00:25:43,555 --> 00:25:45,400
Итак, тогда мы войдем в систему пользователя.

335
00:25:45,400 --> 00:25:47,630
Итак, паспорт аутентифицировать,

336
00:25:47,630 --> 00:25:53,385
мы добавим в этот метод под названием login в req, сообщение запроса.

337
00:25:53,385 --> 00:25:56,770
Таким образом, мы можем вызвать логин с пользователем.

338
00:25:56,770 --> 00:25:59,355
Если это возвращает ошибку,

339
00:25:59,355 --> 00:26:03,105
то мы вернем ошибку здесь соответствующим образом.

340
00:26:03,105 --> 00:26:08,590
Если нет, то мы достигнем точки, где пользователь успешно аутентифицирован.

341
00:26:08,590 --> 00:26:12,630
Таким образом, мы можем сгенерировать JSON Web Token здесь, а затем вернуть

342
00:26:12,630 --> 00:26:18,315
JSON Web Token пользователю, чтобы подтвердить, что пользователь успешно вошел в систему.

343
00:26:18,315 --> 00:26:21,545
Итак, это набор шагов, которые мы будем использовать здесь.

344
00:26:21,545 --> 00:26:25,735
Теперь причина, по которой я делаю более сложный способ обработки, заключается в том, что

345
00:26:25,735 --> 00:26:30,035
я хочу различать ситуацию, когда

346
00:26:30,035 --> 00:26:34,170
происходит подлинная ошибка во время процесса аутентификации, в отличие от ситуации,

347
00:26:34,170 --> 00:26:39,095
когда имя пользователя недопустимо или пароль недействителен.

348
00:26:39,095 --> 00:26:42,860
Таким образом, эти два дела будут обрабатываться этой ситуацией,

349
00:26:42,860 --> 00:26:46,550
когда информация будет нести информацию обратно к нам.

350
00:26:46,550 --> 00:26:48,900
Таким образом, это не ошибка само по себе,

351
00:26:48,900 --> 00:26:52,090
но это ситуация, когда пользователь

352
00:26:52,090 --> 00:26:55,710
не является действительным пользователем или пароль пользователя недействителен.

353
00:26:55,710 --> 00:27:01,070
Таким образом, мы будем обрабатывать процесс входа пользователя в систему.

354
00:27:01,070 --> 00:27:03,660
Кроме того, я добавлю

355
00:27:03,660 --> 00:27:14,825
еще один метод здесь под названием CheckJwtToken.

356
00:27:14,825 --> 00:27:21,100
Вполне возможно, что, хотя клиент вошел в систему и получил веб-токен JSON

357
00:27:21,100 --> 00:27:24,855
, через некоторое время срок действия веб-токена JSON может истечь.

358
00:27:24,855 --> 00:27:32,840
Таким образом, если пользователь пытается получить доступ с клиентской стороны с истекшим токеном

359
00:27:32,840 --> 00:27:35,610
к серверу, сервер не сможет аутентифицировать пользователя.

360
00:27:35,610 --> 00:27:37,780
Таким образом, через периодические интервалы,

361
00:27:37,780 --> 00:27:42,180
мы можем захотеть перекрестную проверку, чтобы убедиться, что JSON Web Token по-прежнему действителен.

362
00:27:42,180 --> 00:27:44,975
Итак, именно по этой причине я включаю это,

363
00:27:44,975 --> 00:27:49,620
другую конечную точку под названием CheckJwtToken.

364
00:27:49,620 --> 00:27:53,155
Итак, если вы получите CheckJwtToken,

365
00:27:53,155 --> 00:27:58,700
включив токен в заголовок авторизации,

366
00:27:58,700 --> 00:28:02,490
то этот вызов вернет true или false,

367
00:28:02,490 --> 00:28:06,535
чтобы указать вам, остается ли JSON Web Token действительным или нет.

368
00:28:06,535 --> 00:28:10,930
Если он недействителен, то клиентская сторона может инициировать другой логин для

369
00:28:10,930 --> 00:28:15,945
пользователя, чтобы получить новый JSON Web Token, если это необходимо.

370
00:28:15,945 --> 00:28:17,285
Итак, чтобы сделать это,

371
00:28:17,285 --> 00:28:27,109
мы скажем Cors.CorsWithOptions и req,

372
00:28:27,109 --> 00:28:31,385
res здесь, как ожидалось.

373
00:28:31,385 --> 00:28:35,670
Здесь мы скажем,

374
00:28:39,820 --> 00:28:49,360
паспорт аутентифицировать jwt

375
00:28:49,360 --> 00:28:57,150
и session: false,

376
00:29:00,020 --> 00:29:07,270
и это вернет ошибку, пользователя, информацию.

377
00:29:09,020 --> 00:29:13,770
Итак, вспомните, как мы используем паспорт аутентифицировать ранее.

378
00:29:13,770 --> 00:29:17,195
Итак, мы вызываем JWT с сеансом false здесь.

379
00:29:17,195 --> 00:29:21,745
Итак, ранее здесь мы говорим, что паспорт аутентифицирует местный.

380
00:29:21,745 --> 00:29:23,535
Таким образом, это для локальной аутентификации.

381
00:29:23,535 --> 00:29:27,330
Таким образом, это для проверки подлинности JSON Web Token.

382
00:29:27,330 --> 00:29:29,430
Итак, когда мы вызываем это,

383
00:29:29,430 --> 00:29:33,435
то, поскольку это собирается проверить JSON Web Token, поэтому мы скажем,

384
00:29:33,435 --> 00:29:40,335
если ошибка вернет следующий ошибку,

385
00:29:40,335 --> 00:29:44,895
а затем пусть обработчик экспресс-ошибок позаботится об этой ситуации.

386
00:29:44,895 --> 00:29:50,469
Затем мы скажем, если не пользователь,

387
00:29:53,330 --> 00:30:00,330
если пользователь не существует, то аналогично иначе.

388
00:30:00,330 --> 00:30:03,510
Таким образом, это означает, что если объект пользователя был

389
00:30:03,510 --> 00:30:07,810
найден из JSON Web Token, а затем загружен в req.user,

390
00:30:07,810 --> 00:30:11,400
то это означает, что пользователь является действительным пользователем,

391
00:30:11,400 --> 00:30:13,485
и поэтому ему может быть разрешено продолжать.

392
00:30:13,485 --> 00:30:20,330
В противном случае, мы собираемся сказать, что пользователь не существует.

393
00:30:20,330 --> 00:30:24,995
Итак, нам нужно сообщить, что срок действия JSON Web Token истек.

394
00:30:24,995 --> 00:30:26,180
Итак, на данный момент

395
00:30:26,180 --> 00:30:29,090
мы отправим res

396
00:30:29,090 --> 00:30:36,545
с кодом состояния 401.

397
00:30:36,545 --> 00:30:47,130
Итак, несанкционированный, SetHeader, Content-Type,

398
00:30:49,900 --> 00:30:56,280
приложение/json, а затем мы вернем res.

399
00:30:58,680 --> 00:31:13,750
Res.json скажет статус JWT

400
00:31:13,750 --> 00:31:17,090
недействительным, а затем

401
00:31:17,730 --> 00:31:23,690
мы вернем флаг под названием success falls, а затем

402
00:31:23,880 --> 00:31:29,080
мы вернем информацию, которую мы получаем, если пользователь

403
00:31:29,080 --> 00:31:34,460
не аутентифицирован как ошибка на этом этапе.

404
00:31:36,420 --> 00:31:40,480
В противном случае, это означает, что мы достигли этой точки,

405
00:31:40,480 --> 00:31:43,220
то пользователь является действительным пользователем.

406
00:31:43,220 --> 00:31:44,850
Итак, в этом случае

407
00:31:44,850 --> 00:31:47,230
позвольте мне просто скопировать этот код здесь,

408
00:31:47,230 --> 00:31:54,070
мы отправим код состояния 200, а затем res.json,

409
00:31:54,070 --> 00:32:02,720
отправит JWT действительный и успешный, истинный.

410
00:32:02,940 --> 00:32:09,820
Третья часть, мы отправим информацию о пользователе.

411
00:32:09,820 --> 00:32:16,000
Таким образом, когда эта конечная точка вызывается с помощью метода get,

412
00:32:16,000 --> 00:32:19,170
это проверит, является ли токен действительным или нет.

413
00:32:19,170 --> 00:32:20,220
Если токен действителен,

414
00:32:20,220 --> 00:32:24,020
то вы получите этот ответ и из флага успеха в ответе,

415
00:32:24,020 --> 00:32:27,770
вы можете проверить, является ли jsonwebtoken действительным или нет.

416
00:32:27,770 --> 00:32:32,155
Это полезно на стороне клиента.

417
00:32:32,155 --> 00:32:37,825
Теперь, этот паспорт аутентифицировать здесь должен быть

418
00:32:37,825 --> 00:32:43,790
снабжен req и res в качестве двух параметров здесь.

419
00:32:43,790 --> 00:32:47,630
Так мы называем паспорт аутентифицированным.

420
00:32:47,630 --> 00:32:49,355
Итак, обратите внимание, что всякий раз, когда вы

421
00:32:49,355 --> 00:32:52,840
вызываете паспорт аутентифицировать и

422
00:32:52,840 --> 00:33:01,825
ожидаете, что эта функция обратного вызова здесь, вам нужно добавить к этому пункту req.res, чтобы паспорт аутентифицировался здесь.

423
00:33:01,825 --> 00:33:03,890
В нашем остальном API сервере

424
00:33:03,890 --> 00:33:07,490
мы реализовали наши комментарии таким образом, что комментарии

425
00:33:07,490 --> 00:33:12,245
формировали вложенные документы внутри документа dishe,

426
00:33:12,245 --> 00:33:16,540
поэтому они покупают каждое блюдо прилагают свой собственный набор комментариев.

427
00:33:16,540 --> 00:33:19,520
Но то, как мы реализовали наш клиент React, заключается

428
00:33:19,520 --> 00:33:22,965
в том, что комментарии хранятся независимо от блюд,

429
00:33:22,965 --> 00:33:27,680
а сами комментарии несли соответствующий идентификатор блюда.

430
00:33:27,680 --> 00:33:30,400
Теперь это два разных способа

431
00:33:30,400 --> 00:33:34,445
реализации на стороне сервера, а также на стороне клиента.

432
00:33:34,445 --> 00:33:39,685
В угловом приложении, которое мы реализованы в нашей угловой специализации,

433
00:33:39,685 --> 00:33:43,470
мы использовали метод поддокумента для

434
00:33:43,470 --> 00:33:47,560
обработки комментариев в нашем угловом клиентском приложении.

435
00:33:47,560 --> 00:33:50,050
Таким образом, оставшийся сервер API был

436
00:33:50,050 --> 00:33:54,090
реализован таким образом, что он был более подходящим для клиента Angular.

437
00:33:54,090 --> 00:34:00,600
Но для клиентов React, так как мы сохранили комментарии независимо от блюд,

438
00:34:00,600 --> 00:34:03,985
а затем используем идентификатор блюда внутри комментария,

439
00:34:03,985 --> 00:34:09,300
поэтому нам нужно реструктурировать наш сервер API отдыха,

440
00:34:09,300 --> 00:34:16,835
так что у нас есть отдельная конечная точка комментария, независимая от конечной точки блюд.

441
00:34:16,835 --> 00:34:22,310
Таким образом, нам нужно реструктурировать наш код на сервере,

442
00:34:22,310 --> 00:34:29,140
чтобы ввести конечную точку /comments REST API на этом этапе.

443
00:34:29,140 --> 00:34:30,600
Итак, чтобы сделать это,

444
00:34:30,600 --> 00:34:37,540
давайте продолжим и реализуем новую модель под названием comment.js.

445
00:34:37,540 --> 00:34:39,260
Итак, перейдя в модели,

446
00:34:39,260 --> 00:34:45,790
позвольте мне реализовать новый файл с именем comments.js.

447
00:34:47,220 --> 00:34:50,015
В файле comments.js

448
00:34:50,015 --> 00:34:56,110
мы собираемся переместить CommentSchema из

449
00:34:56,110 --> 00:35:02,660
файла dishes.js в файл comments.js, а затем удалить его полностью из файла dishes.js.

450
00:35:02,660 --> 00:35:03,900
Но прежде чем мы это сделаем,

451
00:35:03,900 --> 00:35:08,770
нам нужно скопировать мангуст и схему отсюда,

452
00:35:08,770 --> 00:35:13,860
поэтому позвольте мне просто скопировать это из dishes.js в comment.js.

453
00:35:13,860 --> 00:35:16,590
После этого, перейдя в dishes.js,

454
00:35:16,590 --> 00:35:21,040
позвольте мне полностью вырезать эту CommentSchema отсюда,

455
00:35:21,040 --> 00:35:28,300
потому что мы будем иметь это отдельно в модели комментариев здесь.

456
00:35:28,300 --> 00:35:33,070
Итак, давайте переместим это в модель комментариев, а затем вставьте его сюда.

457
00:35:33,070 --> 00:35:35,050
Но, конечно, это не полный,

458
00:35:35,050 --> 00:35:37,870
мы собираемся немного обновить CommentSchema.

459
00:35:37,870 --> 00:35:39,300
Но прежде чем мы это сделаем,

460
00:35:39,300 --> 00:35:43,455
вернитесь в файл dishes.js и в файле блюд,

461
00:35:43,455 --> 00:35:47,925
мы удалим комментарии из DishessChema,

462
00:35:47,925 --> 00:35:51,510
потому что мы будем хранить содержимое отдельно от

463
00:35:51,510 --> 00:35:55,550
блюд в этой версии нашего сервера.

464
00:35:55,550 --> 00:36:00,450
Итак, вот как мы обновим модель посуды здесь.

465
00:36:00,450 --> 00:36:08,180
Итак, мы полностью удалили комментарии из модели посуды здесь.

466
00:36:08,180 --> 00:36:10,270
Перейдя в модель комментариев,

467
00:36:10,270 --> 00:36:15,355
поэтому теперь мы видим, что у нас есть CommentSchema, реализованная здесь.

468
00:36:15,355 --> 00:36:19,525
Но кроме того, в комментариях SSCHEMA

469
00:36:19,525 --> 00:36:23,330
теперь нужно явно указать

470
00:36:23,330 --> 00:36:28,885
на конкретное блюдо, для которого этот комментарий является соответствующим комментарием.

471
00:36:28,885 --> 00:36:30,700
Вот где

472
00:36:30,700 --> 00:36:37,435
наше население мангуста и

473
00:36:37,435 --> 00:36:41,580
то, как мы храним идентификаторы объектов приходит нам на помощь.

474
00:36:41,580 --> 00:36:45,860
Итак, мы будем обновлять CommentSchema, говоря, что у нас будет рейтинг

475
00:36:45,860 --> 00:36:47,800
, комментарий и автор здесь.

476
00:36:47,800 --> 00:36:49,110
В дополнение к автору,

477
00:36:49,110 --> 00:36:56,080
мы представим еще одно поле, называемое как блюдо здесь, которое имеет

478
00:36:56,080 --> 00:37:05,540
тип: Mongoose.Schema Types.ObjectID,

479
00:37:06,390 --> 00:37:19,870
и поэтому это будет ссылаться на блюдо здесь.

480
00:37:19,870 --> 00:37:29,060
Таким образом, это будет объектная ссылка на модель тарелки здесь,

481
00:37:29,060 --> 00:37:32,255
и поэтому с этой модификацией теперь

482
00:37:32,255 --> 00:37:36,640
наши комментарии будут содержать поле рейтинга, поле комментария,

483
00:37:36,640 --> 00:37:42,355
автор, который снова является ссылкой на соответствующего пользователя,

484
00:37:42,355 --> 00:37:47,660
а затем поле тарелки, которое является ссылкой на соответствующий блюдо здесь.

485
00:37:47,660 --> 00:37:50,060
Итак, что означает, что теперь нам нужно будет

486
00:37:50,060 --> 00:37:53,640
заполнить комментарии как автором, так и полем блюда.

487
00:37:53,640 --> 00:37:55,565
Как только мы закончим это,

488
00:37:55,565 --> 00:38:01,585
то мы скажем var Comments

489
00:38:01,585 --> 00:38:09,910
mongoose.model, и мы назовем это «

490
00:38:09,910 --> 00:38:16,765
Comment», а затем это использует CommentSchema, что мы только что определили здесь,

491
00:38:16,765 --> 00:38:21,970
а затем нам нужно экспортировать это отсюда,

492
00:38:21,970 --> 00:38:25,280
comments.model отсюда.

493
00:38:25,280 --> 00:38:28,395
Итак, теперь, когда мы ввели comments.model,

494
00:38:28,395 --> 00:38:35,045
то мы продолжим, а затем представим новый маршрутизатор под названием CommentRouter.

495
00:38:35,045 --> 00:38:37,060
Итак, чтобы ввести маршрутизатор комментариев,

496
00:38:37,060 --> 00:38:39,630
давайте перейдем к маршрутам здесь,

497
00:38:39,630 --> 00:38:45,990
а затем создадим новый файл с именем commentRouter.js.

498
00:38:47,090 --> 00:38:52,415
В commentRouter.js позвольте мне скопировать несколько вещей

499
00:38:52,415 --> 00:38:59,890
из DishRouter.

500
00:38:59,890 --> 00:39:07,720
Итак, у нас будут эти комментарии здесь,

501
00:39:07,720 --> 00:39:14,865
поэтому позвольте мне скопировать эти вещи из, а также,

502
00:39:14,865 --> 00:39:21,070
пока я на нем, позвольте мне просто скопировать их также до этого момента,

503
00:39:21,070 --> 00:39:24,625
а затем я обновлю это немного позже.

504
00:39:24,625 --> 00:39:26,680
Итак, перейдя в CommentRouter,

505
00:39:26,680 --> 00:39:28,040
нам нужны все эти части,

506
00:39:28,040 --> 00:39:33,640
поэтому мы скажем Com, Express, BodyParser, mangoose

507
00:39:33,640 --> 00:39:37,735
, аутентифицировать, Cors, а затем мы

508
00:39:37,735 --> 00:39:46,490
будем импортировать комментарии из модели/комментариев.

509
00:39:49,950 --> 00:40:00,460
Тогда мы назовем это как комментарий Router, который является Express.Router здесь.

510
00:40:02,060 --> 00:40:11,950
Затем мы скажем, CommentRouter использует BodyParser,

511
00:40:11,950 --> 00:40:17,915
а затем это теперь станет маршрутом CommentRouter.

512
00:40:17,915 --> 00:40:22,030
Теперь нам нужно зайти в DishRouter, а затем

513
00:40:22,030 --> 00:40:27,200
удалить все части, которые относятся к комментариям здесь.

514
00:40:27,200 --> 00:40:34,330
Итак, позвольте мне просто вырезать эту часть, а затем мы повторно используем их для нашего комментария Router.

515
00:40:34,330 --> 00:40:38,200
Таким образом, все это больше не нужно в DishRouter.

516
00:40:38,200 --> 00:40:42,080
Итак, я собираюсь удалить все это из DishRouter здесь,

517
00:40:42,080 --> 00:40:43,770
так что позвольте мне вырезать их,

518
00:40:43,770 --> 00:40:48,715
все, что связано с маршрутом комментариев от DishRouter,

519
00:40:48,715 --> 00:40:50,770
затем мы войдем в CommentRouter,

520
00:40:50,770 --> 00:40:54,405
а затем позвольте мне пойти вперед и вставить это на место здесь,

521
00:40:54,405 --> 00:40:57,100
затем мы отредактируем это здесь.

522
00:40:57,100 --> 00:41:02,660
После этого нам нужно экспортировать CommentRouter.

523
00:41:05,160 --> 00:41:08,205
Итак, будет экспортировать CommentRouter для нас.

524
00:41:08,205 --> 00:41:12,060
Но, конечно, этот код не совсем точен.

525
00:41:12,060 --> 00:41:14,995
Итак, нам нужно идти дальше и исправить этот код здесь.

526
00:41:14,995 --> 00:41:16,585
Итак, для этого кода

527
00:41:16,585 --> 00:41:20,180
мы теперь понимаем, что это не маршрут DishRouter,

528
00:41:20,180 --> 00:41:21,785
вместо этого он должен быть

529
00:41:21,785 --> 00:41:27,700
/конечной точкой, потому что мы

530
00:41:27,700 --> 00:41:33,685
собираемся монтировать это в конечной точке /comments здесь.

531
00:41:33,685 --> 00:41:35,685
Итак, мы скажем CommentRouter,

532
00:41:35,685 --> 00:41:39,859
а затем параметры CorsWithOptions (req,

533
00:41:39,859 --> 00:41:42,550
res), которые остаются такими,

534
00:41:42,550 --> 00:41:48,429
а затем получить cors.cors, а затем req.res,

535
00:41:48,429 --> 00:41:52,460
а затем этот станет комментариями.

536
00:41:53,880 --> 00:41:58,430
Найди ID, req.

537
00:42:00,600 --> 00:42:05,330
Таким образом, это будут comments.Find

538
00:42:07,050 --> 00:42:17,080
и req.query здесь.

539
00:42:17,080 --> 00:42:20,920
Итак, когда комментарии будут найдены,

540
00:42:20,920 --> 00:42:22,974
то, в этот момент,

541
00:42:22,974 --> 00:42:25,940
мы будем заполнять автора,

542
00:42:26,880 --> 00:42:30,430
уже есть, заполнять здесь.

543
00:42:30,430 --> 00:42:33,380
Итак, я просто удалю этот comments.author, а затем

544
00:42:33,380 --> 00:42:37,410
мы просто заполним автора здесь.

545
00:42:37,410 --> 00:42:44,425
Тогда это даст нам комментарии здесь.

546
00:42:44,425 --> 00:42:49,310
Тогда, скажем, это можно значительно упростить.

547
00:42:49,310 --> 00:42:53,835
Таким образом, ошибка catch все равно есть.

548
00:42:53,835 --> 00:43:00,805
Итак, когда комментарий придет, он просто вернется.

549
00:43:00,805 --> 00:43:03,910
Извини, это должно быть.

550
00:43:03,910 --> 00:43:06,525
Итак, если для получения,

551
00:43:06,525 --> 00:43:09,305
когда мы получим комментарии,

552
00:43:09,305 --> 00:43:13,760
comments.Find req.query, .populate автора здесь

553
00:43:13,760 --> 00:43:21,619
, а затем, мы скажем,

554
00:43:21,619 --> 00:43:27,605
.then комментарии, а затем, мы скажем, res.statusCode 200, 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
Таким образом, get будет обновляться вот так.

566
00:44:12,655 --> 00:44:22,015
Для сообщения CorsWithOptions

567
00:44:22,015 --> 00:44:26,070
мы скажем, Authenticate.verifyUser req, res, далее.

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
Итак, позвольте мне сократить это и переместить это в часть if здесь,

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. _id.

600
00:47:14,645 --> 00:47:20,070
Теперь пользователь verify автоматически гарантирует, что если вы приземлитесь в этот момент,

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:11,510
Таким образом, остальные части должны были быть заполнены пользователем.

612
00:48:11,510 --> 00:48:14,730
Рейтинг, комментарий

613
00:48:14,730 --> 00:48:17,775
и информация о блюде уже должны быть заполнены

614
00:48:17,775 --> 00:48:20,840
в теле входящего сообщения запроса.

615
00:48:20,840 --> 00:48:23,460
Авторская часть оставлена там незаполненной,

616
00:48:23,460 --> 00:48:28,380
которую мы будем явно вставлять в этот момент в тело здесь.

617
00:48:28,380 --> 00:48:32,515
Итак, теперь req.body будет содержать всю информацию о комментариях.

618
00:48:32,515 --> 00:48:34,440
Итак, на данный момент,

619
00:48:34,440 --> 00:48:43,400
вместо того, чтобы делать это, скажем, comments.create.

620
00:48:44,550 --> 00:48:49,940
Используя req.body, мы создадим комментарии здесь.

621
00:48:50,010 --> 00:48:53,304
Затем это вернет

622
00:48:53,304 --> 00:48:58,735
комментарий, соответствующий комментарию, который мы только что вставили здесь.

623
00:48:58,735 --> 00:49:00,755
Теперь, как только комментарий вернулся,

624
00:49:00,755 --> 00:49:07,050
то мы должны сделать comments.findByID.

625
00:49:07,050 --> 00:49:09,680
Причина, по которой мы должны это сделать, заключается в том, что нам

626
00:49:09,680 --> 00:49:13,070
нужно заполнить здесь информацию об авторе.

627
00:49:13,780 --> 00:49:18,144
Итак, скажем, FindByID комментарии. _id,

628
00:49:18,144 --> 00:49:26,155
а затем, мы заполним информацию об авторе в сам комментарий.

629
00:49:26,155 --> 00:49:34,610
Тогда, скажем, потом комментируем.

630
00:49:36,570 --> 00:49:41,115
Теперь, очевидно, здесь вы обнаружите, что комментарий будет

631
00:49:41,115 --> 00:49:44,880
существовать, потому что мы только что вставили этот комментарий на место.

632
00:49:44,880 --> 00:49:54,470
Итак, здесь мы просто вернем, res.statusCode - 200,

633
00:49:54,900 --> 00:50:10,040
res.SetHeader - Content-Type, application/json.

634
00:50:14,610 --> 00:50:18,430
Сам комментарий скажет res.json, а затем

635
00:50:18,430 --> 00:50:21,745
вернет комментарий в этот момент.

636
00:50:21,745 --> 00:50:26,255
Таким образом, мы будем обрабатывать вставку

637
00:50:26,255 --> 00:50:30,805
нового комментария в нашу клиентскую сторону здесь.

638
00:50:30,805 --> 00:50:33,925
Для пута, как вы понимаете,

639
00:50:33,925 --> 00:50:38,360
вы не сможете сделать ставку на конечные точки /comments/.

640
00:50:38,360 --> 00:50:47,610
Итак, скажем, операция PUT не поддерживается в конечной точке /comments/.

641
00:50:52,050 --> 00:50:56,180
В этом и смысл. Это сообщение, которое ты вернёшь.

642
00:50:56,180 --> 00:50:58,570
Таким образом, StatusCode равен 403,

643
00:50:58,570 --> 00:51:02,610
а затем операция PUT не поддерживается /comments s/.

644
00:51:02,610 --> 00:51:05,260
Теперь, когда мы сделаем удаление,

645
00:51:13,230 --> 00:51:22,840
позвольте мне просто вырезать это отсюда, а затем, скажем,

646
00:51:30,440 --> 00:51:32,835
comments.Remove.

647
00:51:32,835 --> 00:51:37,710
написано пустым. Таким образом, когда вы делаете удаление в конечной точке комментариев косой черты,

648
00:51:37,710 --> 00:51:40,990
вы удалите все комментарии из вашей системы.

649
00:51:40,990 --> 00:51:43,680
Итак, это очень опасная операция, и поэтому

650
00:51:43,680 --> 00:51:48,990
вы не должны делать это нормально.

651
00:51:48,990 --> 00:51:53,860
Таким образом, мы разрешаем только администратору выполнять такую операцию.

652
00:51:53,860 --> 00:51:59,410
Итак, мы удалим все комментарии оттуда.

653
00:51:59,410 --> 00:52:01,940
Итак, когда вы получите ответ,

654
00:52:01,940 --> 00:52:07,700
мы скажем res.StatusCode 200.

655
00:52:07,700 --> 00:52:11,080
Так что, позвольте мне просто скопировать эти части здесь,

656
00:52:12,090 --> 00:52:18,130
а затем приехать и вставить их сюда.

657
00:52:18,130 --> 00:52:21,330
Итак, скажем, comments.remove.

658
00:52:21,330 --> 00:52:30,480
Затем ответ res.statusCode 200 приложение json, а затем res.json (ответ) здесь.

659
00:52:30,480 --> 00:52:33,100
Итак, вот как мы обрабатываем удаление.

660
00:52:33,100 --> 00:52:37,280
Операция удаления в конечной точке комментариев косой черты.

661
00:52:37,280 --> 00:52:43,135
Теперь следующим маршрутом является маршрутизатор комментариев.

662
00:52:43,135 --> 00:52:49,490
Итак, здесь мы скажем commentRouter.Route и

663
00:52:49,490 --> 00:52:56,820
конечной точкой здесь будет косая черта CommentID.

664
00:53:01,190 --> 00:53:05,580
Таким образом, здесь варианты останутся как таковые.

665
00:53:05,580 --> 00:53:09,760
Затем для получения на текущем маршрутизаторе,

666
00:53:09,760 --> 00:53:20,455
для получения мы скажем, comments.findByID (req.params.

667
00:53:20,455 --> 00:53:25,040
Это было бы CommentId.

668
00:53:25,380 --> 00:53:31,029
Итак, как только мы найдем конкретный комментарий,

669
00:53:31,029 --> 00:53:37,525
тогда мы заполним только автора оттуда.

670
00:53:37,525 --> 00:53:39,985
Затем, как только вы заполняете автора,

671
00:53:39,985 --> 00:53:45,830
тогда мы скажем, затем прокомментируем.

672
00:53:47,880 --> 00:53:51,310
Теперь, вся эта часть здесь не нужна,

673
00:53:51,310 --> 00:53:54,440
так что я просто удалю часть.

674
00:53:54,480 --> 00:54:00,985
Это также не подходящая вещь здесь.

675
00:54:00,985 --> 00:54:04,540
Итак, позвольте мне переименовать код.

676
00:54:04,540 --> 00:54:08,990
Итак, мы скажем для получения comments.findByID,

677
00:54:11,550 --> 00:54:15,385
затем заполните автора,

678
00:54:15,385 --> 00:54:20,365
затем прокомментируйте, res.StatusCode 200, SetHeader.

679
00:54:20,365 --> 00:54:22,435
Тогда остальные - JSON.

680
00:54:22,435 --> 00:54:29,960
Мы просто вернем комментарии здесь.

681
00:54:39,240 --> 00:54:46,750
Итак, мы будем возвращать комментарий в этот момент, res.json (comment).

682
00:54:46,750 --> 00:54:49,340
Вы найдете конкретный комментарий,

683
00:54:49,340 --> 00:54:52,415
а затем верните этот комментарий для сообщения.

684
00:54:52,415 --> 00:54:55,185
Для пост-операции, как вы понимаете,

685
00:54:55,185 --> 00:54:56,900
пост-операция не

686
00:54:56,900 --> 00:55:06,740
допускается в комментариях CommentID.

687
00:55:10,080 --> 00:55:13,805
Таким образом, это сообщение, которое мы отправим,

688
00:55:13,805 --> 00:55:19,110
операция POST не поддерживается в комментариях косой черты CommentID.

689
00:55:19,110 --> 00:55:23,640
Итак, это сообщение, которое мы скажем для пута.

690
00:55:23,640 --> 00:55:33,730
Теперь, для положить, мы скажем comments.Find где Id (req.params.commentid).

691
00:55:34,890 --> 00:55:39,230
Итак, мы найдем комментарий там,

692
00:55:40,890 --> 00:55:48,070
и там комментарий, так для пута.

693
00:55:48,070 --> 00:55:50,805
Итак, мы найдем комментарий там,

694
00:55:50,805 --> 00:55:53,400
а затем мы скажем для комментариев.

695
00:55:53,400 --> 00:55:55,305
Итак, если мы найдем комментарий,

696
00:55:55,305 --> 00:56:07,080
если комментарий не является нулевым,

697
00:56:07,080 --> 00:56:19,455
то мы также проверим, comment.author.

698
00:56:19,455 --> 00:56:32,625
Если нет, comment.arthur равно (req.user. _id).

699
00:56:32,625 --> 00:56:38,095
Итак, мы проводим перекрестную проверку, чтобы убедиться, что

700
00:56:38,095 --> 00:56:43,755
comments.author тот же, что и текущий пользователь.

701
00:56:43,755 --> 00:56:50,950
Только текущий пользователь, который вошел в систему - если пользователь тот же, что и автор комментариев,

702
00:56:50,950 --> 00:56:53,760
то пользователю будет разрешено обновлять.

703
00:56:53,760 --> 00:56:57,190
Итак, это первое, что мы проверим.

704
00:56:57,190 --> 00:57:01,900
Итак, комментарии, затем comments.author.equal rec.user. _id.

705
00:57:01,900 --> 00:57:07,860
Если нет, то вы скажете, что не уполномочены обновлять этот комментарий.

706
00:57:07,860 --> 00:57:10,859
Как вы видите .403,

707
00:57:10,859 --> 00:57:13,090
а затем верните следующую ошибку здесь.

708
00:57:13,090 --> 00:57:16,705
Таким образом, мы создадим ошибку там.

709
00:57:16,705 --> 00:57:21,800
Затем после этого мы скажем

710
00:57:29,910 --> 00:57:36,860
req.body.author, req.user. -

711
00:57:40,010 --> 00:57:42,215
Это важно.

712
00:57:42,215 --> 00:57:45,580
Теперь эти два не нужны здесь,

713
00:57:45,580 --> 00:57:51,385
потому что мы напрямую сохраняем комментарий.

714
00:57:51,385 --> 00:58:05,980
Затем таблетки, мы будем говорить comments.Findbyidandupdate,

715
00:58:05,980 --> 00:58:14,965
и req.params.commentid.

716
00:58:14,965 --> 00:58:18,395
Итак, мы найдем этот конкретный комментарий,

717
00:58:18,395 --> 00:58:21,925
потому что нам уже предоставлен идентификатор комментария.

718
00:58:21,925 --> 00:58:27,205
Итак, мы будем делать комментарии findByID req.params.commentid.

719
00:58:27,205 --> 00:58:30,260
Тогда мы скажем тогда (комментарий).

720
00:58:32,730 --> 00:58:38,705
Когда вы предоставляете req.params.commentID,

721
00:58:38,705 --> 00:58:42,275
мы должны явно указать второй параметр,

722
00:58:42,275 --> 00:58:45,825
который мы хотим изменить.

723
00:58:45,825 --> 00:58:52,285
Итак, скажем $ set: req.body.

724
00:58:52,285 --> 00:58:54,970
Итак, второй параметр, по существу,

725
00:58:54,970 --> 00:58:58,740
говорит вам, какую часть вы меняете.

726
00:58:58,740 --> 00:59:03,710
Теперь, так как нам было предоставлено тело, содержащее обновленный комментарий,

727
00:59:03,710 --> 00:59:09,140
мы просто собираемся обновить сам комментарий.

728
00:59:09,510 --> 00:59:18,205
Тогда другая часть, о которой мы попросим, новая: правда.

729
00:59:18,205 --> 00:59:23,240
Таким образом, это гарантирует, что обновленный комментарий будет возвращен

730
00:59:23,240 --> 00:59:29,815
в логове этого вызова comments.findbyidandUpdate.

731
00:59:29,815 --> 00:59:32,565
Итак, мы скажем тогда комментарии.

732
00:59:32,565 --> 00:59:35,214
Когда этот комментарий будет возвращен,

733
00:59:35,214 --> 00:59:38,440
мы скажем comments.findByID (комментарий. _id).

734
00:59:46,200 --> 00:59:51,460
Затем заполняйте автора там.

735
00:59:51,460 --> 00:59:53,785
Мы заполним автора там,

736
00:59:53,785 --> 00:59:58,490
а потом скажем, комментарий.

737
00:59:58,700 --> 01:00:09,680
Итак, вы видите, что мы получим комментарий, а затем вернем комментарий в этот момент.

738
01:00:09,680 --> 01:00:13,095
Итак, вот как мы будем обновлять комментарий.

739
01:00:13,095 --> 01:00:17,395
Таким образом, это ситуация, когда комментарий не является нулевым.

740
01:00:17,395 --> 01:00:20,625
Таким образом, это утверждение if для комментария не является нулевым.

741
01:00:20,625 --> 01:00:23,785
Итак, else если часть,

742
01:00:23,785 --> 01:00:29,020
теперь это не применимо,

743
01:00:29,020 --> 01:00:33,325
так что скажем иначе, ошибка.

744
01:00:33,325 --> 01:00:35,470
Ошибка в этом случае.

745
01:00:35,470 --> 01:00:37,825
Итак, если комментарий имеет значение null, это

746
01:00:37,825 --> 01:00:40,850
означает, что мы не нашли комментарий в нем,

747
01:00:40,850 --> 01:00:43,650
поэтому вы не можете изменить несуществующий комментарий.

748
01:00:43,650 --> 01:00:44,805
Таким образом, мы скажем err,

749
01:00:44,805 --> 01:00:54,700
новый комментарий об ошибке req.params.CommentID не найден, а затем мы вернем ошибку.

750
01:00:54,700 --> 01:01:01,255
Итак, вот как мы будем обрабатывать поставленную часть нашего комментария здесь,

751
01:01:01,255 --> 01:01:04,099
а затем, наконец, удаление.

752
01:01:06,120 --> 01:01:11,130
Для удаления снова мы должны сначала найти

753
01:01:11,130 --> 01:01:12,900
comments.findByID (req.params.commentID),

754
01:01:12,900 --> 01:01:25,720
а затем прокомментировать.

755
01:01:25,720 --> 01:01:28,150
Итак, мы будем искать комментарий.

756
01:01:28,150 --> 01:01:34,160
Итак, сначала проверим, не равен ли комментарий нулю.

757
01:01:36,180 --> 01:01:39,955
Это важно проверить здесь.

758
01:01:39,955 --> 01:01:50,990
Затем следующая часть, которую мы проверим, является ли comment.author равным req.user. _id.

759
01:01:58,830 --> 01:02:03,400
Мы убедитесь, что этот пользователь, который пытается удалить

760
01:02:03,400 --> 01:02:08,060
этот комментарий, является тем же пользователем, который вставил комментарий в первую очередь.

761
01:02:08,060 --> 01:02:10,750
Если нет, то если это ситуация,

762
01:02:10,750 --> 01:02:13,920
то вы увидите «Вы не уполномочены удалять этот комментарий!»

763
01:02:13,920 --> 01:02:16,365
А потом верните статус там.

764
01:02:16,365 --> 01:02:20,920
Затем внизу здесь

765
01:02:20,920 --> 01:02:41,310
мы скажем comments.FindByidandRemove здесь.

766
01:02:41,310 --> 01:02:48,750
Итак, мы скажем comments.findByidAndRemove (req.params.commentid),

767
01:02:48,750 --> 01:02:54,035
тогда мы получим некоторый ответ от комментария.

768
01:02:54,035 --> 01:02:55,630
Итак, на данный момент

769
01:02:55,630 --> 01:02:59,830
мы просто скажем, res.statusCode.

770
01:02:59,830 --> 01:03:05,365
Таким образом, мы скажем comments.findByidAndRemove, затем ответ.

771
01:03:05,365 --> 01:03:07,210
Если он правильно удален,

772
01:03:07,210 --> 01:03:10,915
мы скажем 200, а затем res.json

773
01:03:10,915 --> 01:03:17,260
ответ здесь, и мы также поймаем ошибку на этом этапе.

774
01:03:17,260 --> 01:03:25,195
Итак, позвольте мне просто скопировать это здесь, а затем мы включим уловы ошибки в данный момент.

775
01:03:25,195 --> 01:03:28,895
Итак, это первое, что мы проверим.

776
01:03:28,895 --> 01:03:33,500
Мы гарантируем, что комментарий не равен нулю.

777
01:03:33,630 --> 01:03:38,360
В противном случае, так что это другая часть.

778
01:03:39,810 --> 01:03:44,170
Таким образом, это еще часть ошибки if else

779
01:03:44,170 --> 01:03:48,040
новый комментарий req.params.commentID не найден, а затем

780
01:03:48,040 --> 01:03:56,220
404 и отправить часть else для нас, а затем часть будет обрабатываться соответствующим образом.

781
01:03:56,220 --> 01:04:01,460
Итак, это изменения, которые мы вносим для маршрутизатора комментариев здесь.

782
01:04:01,460 --> 01:04:05,025
Итак, мы обрабатываем сообщение get put и delete для

783
01:04:05,025 --> 01:04:10,330
комментариев косой черты и точки косой черты commentID воздействия.

784
01:04:10,330 --> 01:04:12,495
Поэтому, как только мы завершим это,

785
01:04:12,495 --> 01:04:17,500
нам нужно включить это в файл app.js.

786
01:04:17,500 --> 01:04:27,345
Итак, мы перейдем в файл app.js, а затем скажем,

787
01:04:27,345 --> 01:04:30,070
var commentRouter

788
01:04:31,130 --> 01:04:42,280
требует маршрутов/commentRouter.

789
01:04:42,280 --> 01:04:45,960
Итак, у нас есть маршрутизатор комментариев здесь, а затем мы

790
01:04:45,960 --> 01:04:49,390
спустимся в файл app.js ниже здесь, а

791
01:04:49,390 --> 01:04:54,610
затем мы скажем app.use

792
01:04:55,040 --> 01:05:04,695
косой черты комментарии, commentRouter здесь.

793
01:05:04,695 --> 01:05:07,365
Вот оно. Итак,

794
01:05:07,365 --> 01:05:09,390
мой маршрутизатор комментариев готов.

795
01:05:09,390 --> 01:05:12,935
Итак, давайте продолжим и сохраним все изменения.

796
01:05:12,935 --> 01:05:19,020
Затем наш сервер теперь обновляется,

797
01:05:19,020 --> 01:05:24,420
чтобы обрабатывать все запросы от наших клиентов React здесь.

798
01:05:24,420 --> 01:05:27,800
Теперь, если вы хотите сделать альтернативный способ, то есть

799
01:05:27,800 --> 01:05:34,120
у вас есть свои комментарии в качестве поддокументов вашего блюда, а затем вы хотите справиться с этим,

800
01:05:34,120 --> 01:05:37,680
вам нужно будет обновить клиент React,

801
01:05:37,680 --> 01:05:42,185
чтобы иметь возможность использовать комментарии из каждого блюда соответствующим образом.

802
01:05:42,185 --> 01:05:44,830
Это останется для вас в качестве упражнения.

803
01:05:44,830 --> 01:05:48,920
Подумайте о том, как вы бы спроектировали свой реагирующий клиент таким образом, чтобы он

804
01:05:48,920 --> 01:05:53,465
работал очень хорошо с более ранней версией

805
01:05:53,465 --> 01:06:03,735
сервера, который имел комментарии в качестве поддокументов ваших блюд.

806
01:06:03,735 --> 01:06:07,065
Теперь, это будет интересный способ его реализации.

807
01:06:07,065 --> 01:06:10,480
Конечно, это немного сложнее, чем то, как мы

808
01:06:10,480 --> 01:06:14,965
реализовали клиент React, где мы сохранили комментарии независимо от

809
01:06:14,965 --> 01:06:20,840
блюд, но затем дополнительная работа является ответственностью

810
01:06:20,840 --> 01:06:22,910
клиента, потому что вам нужно выбрать

811
01:06:22,910 --> 01:06:26,765
соответствующие комментарии, когда вы показываете специфическое блюдо.

812
01:06:26,765 --> 01:06:30,370
Вам нужно выбрать комментарии из всех комментариев здесь.

813
01:06:30,370 --> 01:06:35,170
Таким образом, это еще одна работа, которую делает наш клиент React из-за

814
01:06:35,170 --> 01:06:40,680
того, что мы отделяли комментарии от самих блюд.

815
01:06:40,680 --> 01:06:46,165
Аналогичным образом, если вы можете изменить дизайн вашего углового клиента, чтобы иметь возможность

816
01:06:46,165 --> 01:06:51,775
иметь дело с ситуацией, когда комментарии хранятся независимо от ваших блюд.

817
01:06:51,775 --> 01:06:56,020
Итак, это все упражнения, которые вы можете сделать, чтобы увидеть, как вы можете

818
01:06:56,020 --> 01:07:01,210
расширить свои клиентские приложения для обработки любого типа серверов,

819
01:07:01,210 --> 01:07:04,430
двух различных типов серверов там.

820
01:07:04,860 --> 01:07:11,480
Таким образом, с этим мы завершаем обновление на наш сервер здесь.

821
01:07:11,480 --> 01:07:15,040
Таким образом, с этим мы обновили все на стороне сервера.

822
01:07:15,040 --> 01:07:17,890
Итак, давайте сохраним все изменения на стороне сервера.

823
01:07:17,890 --> 01:07:26,755
Теперь наш сервер готов обрабатывать входящие запросы от нашего клиента React.

824
01:07:26,755 --> 01:07:29,340
С этим мы завершаем это упражнение.

825
01:07:29,340 --> 01:07:33,300
В этом упражнении мы подготовили наш экспресс-сервер

826
01:07:33,300 --> 01:07:38,985
для обработки входящих запросов от нашего клиента React.

827
01:07:38,985 --> 01:07:43,190
В следующем упражнении мы рассмотрим

828
01:07:43,190 --> 01:07:48,000
реагирующий клиент более подробно, чтобы понять, как он взаимодействует с этим дополнительным сервером.

829
01:07:48,000 --> 01:07:50,640
Это хорошее время для вас, чтобы сделать

830
01:07:50,640 --> 01:07:55,880
покрытие git с сообщением, интегрирующим клиент и сервер.