1
00:00:03,650 --> 00:00:08,385
Nós já tínhamos desenvolvido um servidor API REST completo

2
00:00:08,385 --> 00:00:12,485
usando Express e MongoDB como parte deste curso.

3
00:00:12,485 --> 00:00:16,965
Para que esse servidor possa se comunicar de forma significativa com nosso cliente,

4
00:00:16,965 --> 00:00:19,590
faremos alguns pequenos ajustes para que ele

5
00:00:19,590 --> 00:00:22,440
retorne o tipo certo de dados para que a

6
00:00:22,440 --> 00:00:24,780
implementação de nosso cliente possa trabalhar de

7
00:00:24,780 --> 00:00:28,935
forma mais eficiente com os dados retornados do nosso site de servidor.

8
00:00:28,935 --> 00:00:30,410
Então, para fazer isso,

9
00:00:30,410 --> 00:00:36,580
vamos trabalhar em alguns ajustes para o nosso site de servidor neste exercício.

10
00:00:36,580 --> 00:00:39,215
Antes de iniciar este exercício,

11
00:00:39,215 --> 00:00:42,410
estou assumindo que você não fez

12
00:00:42,410 --> 00:00:46,430
a lição anterior sobre a integração do cliente angular e

13
00:00:46,430 --> 00:00:55,395
do servidor porque você está fazendo essa lição vindo através da especialização React.

14
00:00:55,395 --> 00:01:01,190
Então, as alterações que eu vou fazer no servidor assumirão que

15
00:01:01,190 --> 00:01:07,430
a versão do servidor que você está modificando é antes da lição anterior.

16
00:01:07,430 --> 00:01:11,540
No caso de você ter feito essa lição sobre cliente angular,

17
00:01:11,540 --> 00:01:16,505
algumas das alterações que você fez para o seu servidor serão repetidas novamente

18
00:01:16,505 --> 00:01:22,495
neste exercício para que você possa ignorar essa parte das alterações.

19
00:01:22,495 --> 00:01:26,055
Vá ao nosso servidor no editor.

20
00:01:26,055 --> 00:01:29,125
Antes de começar a trabalhar no servidor,

21
00:01:29,125 --> 00:01:33,530
eu sugiro que você baixe todas as imagens que eu

22
00:01:33,530 --> 00:01:38,380
forneci como um arquivo zip nos recursos de exercício chamados images.zip.

23
00:01:38,380 --> 00:01:43,160
Descompacte o arquivo e, em seguida, obtenha todas as imagens de lá e, em seguida, copie essas imagens

24
00:01:43,160 --> 00:01:48,290
para a pasta de imagens públicas em nosso servidor.

25
00:01:48,290 --> 00:01:55,010
Então, você vê que aqui eu copiei todas as imagens para minha pasta de imagens públicas aqui

26
00:01:55,010 --> 00:01:58,160
já porque nosso servidor é aquele que vai

27
00:01:58,160 --> 00:02:02,275
servir todas essas imagens para nossa aplicação cliente.

28
00:02:02,275 --> 00:02:07,835
Em seguida, vamos para o CORS e ajustamos a lista branca aqui.

29
00:02:07,835 --> 00:02:11,565
Então, para o nosso aplicativo cliente React,

30
00:02:11,565 --> 00:02:15,275
se começamos com o comando yarn start,

31
00:02:15,275 --> 00:02:18,470
ele será executado no nome do seu computador:3001.

32
00:02:18,470 --> 00:02:22,040
Então, qualquer pedido vindo de nossa localização para

33
00:02:22,040 --> 00:02:25,760
o servidor levará isso como a origem lá.

34
00:02:25,760 --> 00:02:30,380
Então é por isso que vou adicionar isso à minha lista branca para que

35
00:02:30,380 --> 00:02:35,390
quaisquer problemas de CORS sejam resolvidos automaticamente.

36
00:02:35,390 --> 00:02:40,985
Então, indo para o arquivo cors.js na minha lista branca aqui,

37
00:02:40,985 --> 00:02:49,460
deixe-me adicionar no

38
00:02:49,460 --> 00:02:55,640
nome do computador http://my: 3001 e esta é

39
00:02:55,640 --> 00:02:58,610
a origem da qual meu cliente

40
00:02:58,610 --> 00:03:02,075
será originando as solicitações que vêm para este servidor.

41
00:03:02,075 --> 00:03:07,075
Assim, meu CORS não causaria problemas ao meu cliente.

42
00:03:07,075 --> 00:03:11,690
Em seguida, precisamos atualizar algumas das rotas para

43
00:03:11,690 --> 00:03:17,690
lidar com os parâmetros de consulta e também alguns pequenos outros ajustes.

44
00:03:17,690 --> 00:03:21,280
Deixe-me começar com o arquivo promoRouter.js.

45
00:03:21,280 --> 00:03:25,010
Isso é simples de ser atualizado.

46
00:03:25,010 --> 00:03:27,570
Então, indo para o arquivo promoRouter.js,

47
00:03:27,570 --> 00:03:32,360
no arquivo PromOrouter para a solicitação get que recebemos

48
00:03:32,360 --> 00:03:37,610
aqui em vez de fazer promoções encontrar com um objeto JavaScript vazio,

49
00:03:37,610 --> 00:03:47,320
aqui eu forneceria o req.query como o parâmetro para as promoções encontrar aqui, a

50
00:03:47,320 --> 00:03:49,680
mesma coisa com o roteador líder também.

51
00:03:49,680 --> 00:03:52,745
Então, deixe-me ir para o arquivo leaderRouter.js.

52
00:03:52,745 --> 00:03:54,815
No roteador líder também,

53
00:03:54,815 --> 00:04:00,545
aqui onde você encontra Leaders.Find com o objeto JavaScript vazio, em vez disso,

54
00:04:00,545 --> 00:04:06,685
substitua isso com o req.query para que os parâmetros de consulta sejam passados.

55
00:04:06,685 --> 00:04:14,260
Então, este é o lugar onde vamos passar no featured:true como o parâmetro de consulta aqui.

56
00:04:14,260 --> 00:04:16,945
Agora, tendo ajustado esses dois,

57
00:04:16,945 --> 00:04:19,340
vamos agora trabalhar no roteador prato.

58
00:04:19,340 --> 00:04:22,115
Então, vá para o arquivo dishRouter.js,

59
00:04:22,115 --> 00:04:26,310
mesmo no roteador prato também a mesma atualização aqui.

60
00:04:26,310 --> 00:04:31,200
Então, vá para este dishes.Find no método get aqui,

61
00:04:31,200 --> 00:04:33,945
altere isso para req.query.

62
00:04:33,945 --> 00:04:38,070
Então, com isso, minha atualização do roteador prato foi concluída.

63
00:04:38,070 --> 00:04:42,085
Então, agora atualizamos o roteador promocional, o líder

64
00:04:42,085 --> 00:04:43,850
e o roteador prato,

65
00:04:43,850 --> 00:04:48,050
então vamos passar para atualizar o roteador favorito.

66
00:04:48,050 --> 00:04:54,380
Agora, você teria implementado o roteador favorito como parte de sua quarta tarefa.

67
00:04:54,380 --> 00:04:56,530
Agora, no roteador favorito,

68
00:04:56,530 --> 00:04:58,910
você verá que para o roteador favorito,

69
00:04:58,910 --> 00:05:01,010
eu não estou mostrando a parte restante porque

70
00:05:01,010 --> 00:05:03,435
você deveria ter feito como parte de sua tarefa.

71
00:05:03,435 --> 00:05:11,520
Primeiro, deixe-me chamar sua atenção para o método get para o favoriteRouter.Route:DISHID.

72
00:05:11,520 --> 00:05:17,405
Agora eu vou usar este método get para apenas verificar para garantir que

73
00:05:17,405 --> 00:05:25,460
o prato específico com o Id prato já é um favorito para o usuário.

74
00:05:25,460 --> 00:05:29,130
Então, em vez de simplesmente dizer getoperation.supported,

75
00:05:29,130 --> 00:05:36,165
eu só vou alavancar a presença desta operação get e, em seguida, vamos dizer,

76
00:05:36,165 --> 00:05:47,500
favorites.findone e vamos dizer usuário: req.user. _id.

77
00:05:49,220 --> 00:05:59,340
Então, vamos encontrar os favoritos para esse usuário particular e, em seguida, vamos dizer, em seguida,

78
00:06:03,070 --> 00:06:25,530
favoritos e pegar erro próximo.

79
00:06:25,530 --> 00:06:35,265
Então, da mesma forma aqui, vamos adicionar no erro aqui, próximo erro aqui.

80
00:06:35,265 --> 00:06:37,380
Então, dentro disso, então,

81
00:06:37,380 --> 00:06:39,495
quando obtivermos os favoritos,

82
00:06:39,495 --> 00:06:45,360
então vamos verificar se não favoritos.

83
00:06:45,360 --> 00:06:47,690
Então, se não houver favoritos para

84
00:06:47,690 --> 00:06:53,900
este usuário, então, obviamente, o prato que estamos verificando não existe,

85
00:06:53,900 --> 00:07:07,520
então vamos retornar 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 e então vamos retornar dizendo existe false.

88
00:07:36,735 --> 00:07:44,215
O que estamos especificando aqui é que se eles obtêm é feito até este ponto final com um prato Id,

89
00:07:44,215 --> 00:07:52,835
esta bandeira existe aqui será definido como verdadeiro se este prato é parte dos meus favoritos.

90
00:07:52,835 --> 00:07:55,290
Se este prato não faz parte dos meus favoritos,

91
00:07:55,290 --> 00:07:58,100
Eu vou definir lá existe bandeira para falso.

92
00:07:58,100 --> 00:08:01,190
Então aqui, você vê que desde que eu não tenho nenhum favorito então

93
00:08:01,190 --> 00:08:04,770
existe deve ser automaticamente falso neste ponto.

94
00:08:04,770 --> 00:08:13,020
Então, vamos dizer que existe falso e, em seguida, vamos retornar os favoritos aqui.

95
00:08:13,180 --> 00:08:19,090
Bem, obviamente, neste caso, os favoritos seriam nulos neste momento.

96
00:08:19,090 --> 00:08:26,440
Caso contrário, então o que significa que os favoritos não é nulo,

97
00:08:26,440 --> 00:08:32,750
então vamos dizer se favorites.dishes.indexOf.

98
00:08:36,840 --> 00:08:45,995
Então, vamos procurar por Req.Params.Dishid.

99
00:08:45,995 --> 00:08:51,220
Então, nós estamos indo para procurar esta matriz pratos favoritos para

100
00:08:51,220 --> 00:08:56,605
ver se este prato existe lá e se ele não existe,

101
00:08:56,605 --> 00:09:00,525
obviamente isso irá retornar um índice negativo aqui.

102
00:09:00,525 --> 00:09:02,340
Nesse caso também,

103
00:09:02,340 --> 00:09:05,440
retornarei exatamente o mesmo que aqui.

104
00:09:05,440 --> 00:09:08,630
Então, se ele retorna um índice negativo então isso significa que

105
00:09:08,630 --> 00:09:12,260
mesmo que este usuário em particular tem um conjunto de favoritos,

106
00:09:12,260 --> 00:09:16,190
este prato específico não existe

107
00:09:16,190 --> 00:09:22,340
na lista de seus favoritos, então é por isso que ele vai retornar existe falso aqui.

108
00:09:22,340 --> 00:09:30,255
Agora, caso contrário, isso significa que o prato existe na lista de favoritos.

109
00:09:30,255 --> 00:09:31,859
Então, neste caso,

110
00:09:31,859 --> 00:09:36,670
eu retornarei o código de status 200 existe é verdadeiro.

111
00:09:36,670 --> 00:09:43,825
Assim, quando o usuário executa uma operação get neste ponto final com

112
00:09:43,825 --> 00:09:52,015
o /Favorites/DISHID onde o Id prato é fornecido

113
00:09:52,015 --> 00:09:55,630
como o parâmetro aqui, como o parâmetro request aqui,

114
00:09:55,630 --> 00:10:00,650
então vamos verificar se esse prato existe nos favoritos.

115
00:10:00,650 --> 00:10:05,775
Se nenhum dos favoritos existe para este usuário, em seguida, vamos retornar um existe false.

116
00:10:05,775 --> 00:10:08,120
Da mesma forma, se os favoritos existe, mas

117
00:10:08,120 --> 00:10:12,320
esse prato particular não existe nos favoritos, então retornaremos falso,

118
00:10:12,320 --> 00:10:13,910
caso contrário, retornaremos verdadeiro.

119
00:10:13,910 --> 00:10:20,260
Então esta bandeira existe pode ser usado pelo meu cliente para verificar se este prato é

120
00:10:20,260 --> 00:10:27,755
parte da lista de pratos favoritos para este usuário ou não.

121
00:10:27,755 --> 00:10:30,139
Além disso, enquanto estamos em favoritos,

122
00:10:30,139 --> 00:10:33,410
sempre que fizermos qualquer alteração nos favoritos,

123
00:10:33,410 --> 00:10:37,870
queremos poder preencher as informações do usuário e pratos,

124
00:10:37,870 --> 00:10:39,535
os favoritos, antes de voltarmos.

125
00:10:39,535 --> 00:10:43,240
Por exemplo, no post que fazemos,

126
00:10:43,240 --> 00:10:48,470
quando salvamos os favoritos, então, neste momento,

127
00:10:48,470 --> 00:10:55,470
gostaríamos de primeiro fazer favoritos.

128
00:10:55,620 --> 00:11:06,380
FindById, então porque acabamos de fazer as alterações vamos dizer favorite_id

129
00:11:07,740 --> 00:11:15,325
e vamos preencher tanto o usuário e também

130
00:11:15,325 --> 00:11:25,490
preencher os pratos nos favoritos.

131
00:11:25,740 --> 00:11:32,420
Então, quando os favoritos forem retornados,

132
00:11:32,610 --> 00:11:36,940
retornaremos esses favoritos em vez disso.

133
00:11:36,940 --> 00:11:40,440
Então, deixe-me fazer essa mudança aqui.

134
00:11:40,440 --> 00:11:46,910
Então, vamos cortar isso daqui e depois dentro do então,

135
00:11:46,910 --> 00:11:49,645
vamos devolver os favoritos.

136
00:11:49,645 --> 00:11:53,510
Depois de salvarmos os favoritos,

137
00:11:53,510 --> 00:11:54,980
então vamos procurá-lo,

138
00:11:54,980 --> 00:11:58,285
para o FavoriteByID e, em seguida, retornar

139
00:11:58,285 --> 00:12:03,940
esse favorito aqui, então vamos dizer então retorno favorito e código de status.

140
00:12:03,940 --> 00:12:05,355
Esta mudança que devemos fazer.

141
00:12:05,355 --> 00:12:08,180
Se você já implementou isso em seus favoritos,

142
00:12:08,180 --> 00:12:09,760
então você não precisa fazer essa alteração.

143
00:12:09,760 --> 00:12:13,310
Mas o que estamos fazendo é sempre que fazemos alterações nos favoritos,

144
00:12:13,310 --> 00:12:17,380
nós vamos preencher as informações do usuário e pratos e, em seguida, retornar esse valor

145
00:12:17,380 --> 00:12:22,360
porque nosso cliente React espera que isso esteja lá.

146
00:12:22,360 --> 00:12:24,685
Agora, o mesmo tipo de mudança,

147
00:12:24,685 --> 00:12:28,350
vamos precisar fazer variável b, salvar as alterações.

148
00:12:28,350 --> 00:12:33,125
Então, no post aqui,

149
00:12:33,125 --> 00:12:36,090
vamos fazer uma alteração para isso,

150
00:12:36,090 --> 00:12:42,705
então vamos dizer favorites.save e então vamos fazer favorites.findByID e fazer essa mudança.

151
00:12:42,705 --> 00:12:45,210
Da mesma forma, sob o id

152
00:12:45,210 --> 00:12:47,095
do prato, também no post,

153
00:12:47,095 --> 00:12:51,070
você será da mesma forma, sempre que você fizer alterações nos favoritos,

154
00:12:51,070 --> 00:12:57,715
primeiro procurará e depois preencherá o usuário e os pratos e depois devolvê-lo

155
00:12:57,715 --> 00:12:59,910
e, em seguida, da mesma forma na outra parte.

156
00:12:59,910 --> 00:13:06,290
Então, você deve ter implementado isso em sua quarta missão.

157
00:13:06,290 --> 00:13:09,010
Então, faça esta alteração adicional onde você irá preencher

158
00:13:09,010 --> 00:13:12,350
o usuário e pratos antes de retornar o valor.

159
00:13:12,350 --> 00:13:14,685
Também com a exclusão,

160
00:13:14,685 --> 00:13:17,385
faremos as mesmas alterações aqui.

161
00:13:17,385 --> 00:13:19,890
Então, você percebe que na exclusão,

162
00:13:19,890 --> 00:13:21,830
eu já fiz essa alteração aqui.

163
00:13:21,830 --> 00:13:27,085
Então, depois de salvarmos as alterações nos favoritos,

164
00:13:27,085 --> 00:13:29,480
procuraremos os favoritos e

165
00:13:29,480 --> 00:13:33,465
retornaremos depois de preencher o usuário e os pratos e os favoritos.

166
00:13:33,465 --> 00:13:36,505
Isto é o que o nosso cliente React espera que façamos.

167
00:13:36,505 --> 00:13:38,145
Então, mesmo para a exclusão,

168
00:13:38,145 --> 00:13:39,995
faremos as mesmas mudanças.

169
00:13:39,995 --> 00:13:44,115
Agora, com isso, meu roteador favorito é atualizado

170
00:13:44,115 --> 00:13:48,575
, então vamos avançar para atualizar users.js em seguida.

171
00:13:48,575 --> 00:13:52,370
Finalmente, vamos atualizar o arquivo users.js.

172
00:13:52,370 --> 00:13:57,060
Agora, no arquivo users.js, precisamos adicionar em

173
00:13:57,060 --> 00:14:05,245
outro campo roteador.options aqui,

174
00:14:05,245 --> 00:14:10,610
porque às vezes um pedido de postagem como você viu

175
00:14:10,610 --> 00:14:16,315
com o login enviará as opções primeiro para verificar,

176
00:14:16,315 --> 00:14:21,610
especialmente com carros, se a solicitação de postagem será permitida.

177
00:14:21,610 --> 00:14:30,080
Então é por isso que vamos verificar o curso com opções aqui e, em seguida,

178
00:14:31,860 --> 00:14:35,450
vamos simplesmente retornar

179
00:14:39,960 --> 00:14:43,045
uma mensagem

180
00:14:43,045 --> 00:14:46,180
de status de 200 em resposta a isso.

181
00:14:46,180 --> 00:14:52,960
Para qualquer endpoint em usuários, se recebermos as opções,

182
00:14:52,960 --> 00:14:56,530
simplesmente retornaremos um status 200 aqui.

183
00:14:56,530 --> 00:15:03,580
Agora a função de login que tínhamos implementado anteriormente,

184
00:15:03,580 --> 00:15:07,470
tínhamos simplesmente feito passport.authenticate

185
00:15:07,470 --> 00:15:12,930
local aqui e o verificamos os valores restantes aqui.

186
00:15:12,930 --> 00:15:15,215
Agora, este passport.authenticate local,

187
00:15:15,215 --> 00:15:17,600
se o usuário não for autenticado,

188
00:15:17,600 --> 00:15:21,800
ele simplesmente retorna um não autorizado na mensagem de resposta.

189
00:15:21,800 --> 00:15:28,380
Agora isso pode não ser muito significativo para o lado do cliente exibir essas informações,

190
00:15:28,380 --> 00:15:36,310
então é por isso que vamos aprimorar

191
00:15:36,310 --> 00:15:41,765
esse método de pós-login do roteador para que a autenticação retorne informações mais significativas neste momento.

192
00:15:41,765 --> 00:15:43,210
Então, para fazer isso,

193
00:15:43,210 --> 00:15:49,395
não vamos estar fazendo o passaporte.autenticar aqui, em

194
00:15:49,395 --> 00:15:51,955
vez disso vamos pegar.

195
00:15:51,955 --> 00:15:55,140
Então, deixe-me remover isso de lá e então você verá

196
00:15:55,140 --> 00:15:58,930
como eu vou atualizar o post do roteador aqui.

197
00:15:58,930 --> 00:16:08,620
Então, vamos ver o curso com opções e, em seguida, vamos incluir o req,

198
00:16:08,620 --> 00:16:12,160
res e em seguida aqui.

199
00:16:12,160 --> 00:16:16,885
Dentro deste req, res e próximo aqui,

200
00:16:16,885 --> 00:16:27,954
passport.authenticate chamará isso com local.

201
00:16:27,954 --> 00:16:31,210
Agora, quando chamamos isso com local,

202
00:16:31,210 --> 00:16:34,970
se ocorrer um erro de autenticação,

203
00:16:34,970 --> 00:16:38,240
o passport.authenticate pode ser feito para retornar

204
00:16:38,240 --> 00:16:44,230
o valor do erro e também ele irá retornar o usuário se

205
00:16:44,230 --> 00:16:48,960
não houver erro e um terceiro parâmetro chamado info

206
00:16:48,960 --> 00:16:54,000
que irá levar informações adicionais que podem ser analisadas de volta para o usuário.

207
00:16:54,000 --> 00:16:56,580
Esse erro será retornado quando houver

208
00:16:56,580 --> 00:16:59,950
um erro genuíno que ocorre no passport.authenticate.

209
00:16:59,950 --> 00:17:03,400
Mas se as informações do usuário

210
00:17:03,400 --> 00:17:07,645
são enviadas para o passport.authenticate, mas o usuário não existe,

211
00:17:07,645 --> 00:17:10,490
então isso não é contado como um erro.

212
00:17:10,490 --> 00:17:14,690
Em vez disso, ele será contado como o usuário não existe e

213
00:17:14,690 --> 00:17:19,305
essa informação é analisada de volta no objeto info que entra.

214
00:17:19,305 --> 00:17:21,500
Assim, o erro será retornado quando houver

215
00:17:21,500 --> 00:17:24,925
um erro genuíno que ocorre durante o processo de autenticação,

216
00:17:24,925 --> 00:17:30,820
mas as informações conterão informações se o usuário não existir.

217
00:17:30,820 --> 00:17:36,920
Então, o passport.authenticate está passando de volta uma mensagem dizendo que

218
00:17:36,920 --> 00:17:39,575
o usuário não existe ou que o nome de usuário

219
00:17:39,575 --> 00:17:42,850
está incorreto ou a senha está incorreta e assim por diante.

220
00:17:42,850 --> 00:17:46,870
Então, essa informação será passada na mensagem info.

221
00:17:46,870 --> 00:17:49,230
Agora vamos ver como isso é útil para

222
00:17:49,230 --> 00:17:52,060
nós quando olhamos para o lado do cliente um pouco mais tarde.

223
00:17:52,060 --> 00:17:55,400
Então, nesta situação,

224
00:17:55,400 --> 00:18:01,455
vamos lidar com isso da seguinte forma,

225
00:18:01,455 --> 00:18:06,810
e não só que quando chamamos este passaporte.autenticar,

226
00:18:06,810 --> 00:18:10,220
também precisamos passar em um req,

227
00:18:10,220 --> 00:18:15,080
res, próximo como os três parâmetros para ele.

228
00:18:15,080 --> 00:18:20,130
Então, esta é a estrutura quando você precisa chamar passport.authenticate e esperar que ele

229
00:18:20,130 --> 00:18:25,270
passe de volta informações como esta como um método de retorno de chamada aqui,

230
00:18:25,270 --> 00:18:27,630
então você também precisa fornecer este req, res, em

231
00:18:27,630 --> 00:18:30,250
seguida também.

232
00:18:30,250 --> 00:18:32,270
Agora, se isso ocorrer,

233
00:18:32,270 --> 00:18:36,780
então vamos dizer se errar,

234
00:18:36,780 --> 00:18:40,425
então, se houver um erro que ocorre,

235
00:18:40,425 --> 00:18:45,395
vamos dizer retorno próximo

236
00:18:45,395 --> 00:18:51,480
erro e, em seguida, deixar o manipulador de erros do nosso roteador expresso e cuidar disso.

237
00:18:51,480 --> 00:18:56,755
Agora, vamos considerar outras situações, se não usuário.

238
00:18:56,755 --> 00:18:59,630
Então, se chegamos a este ponto,

239
00:18:59,630 --> 00:19:02,580
então isso significa que não foi um erro que ocorreu,

240
00:19:02,580 --> 00:19:05,615
mas talvez o usuário não tenha sido encontrado.

241
00:19:05,615 --> 00:19:07,100
Se o usuário não for encontrado,

242
00:19:07,100 --> 00:19:11,190
então o usuário aqui será definido como null neste caso.

243
00:19:11,190 --> 00:19:14,634
Então, nessa situação,

244
00:19:14,634 --> 00:19:17,375
se o usuário não existir,

245
00:19:17,375 --> 00:19:23,680
então precisamos ser capazes de passar informações de volta para o lado do servidor.

246
00:19:23,680 --> 00:19:28,435
Então, o que vamos fazer é passar nesta informação neste formato.

247
00:19:28,435 --> 00:19:32,020
Então, eu vou cortar isso daqui e

248
00:19:32,020 --> 00:19:36,640
depois colá-lo aqui e então vamos editar isso.

249
00:19:36,640 --> 00:19:40,704
Então, se o usuário é nulo,

250
00:19:40,704 --> 00:19:45,830
então vamos enviar de volta um código de status como 401, o que significa

251
00:19:45,830 --> 00:19:53,975
não autorizado e, em seguida, vamos enviar de volta informações sucesso falso,

252
00:19:53,975 --> 00:19:57,405
e então não estaremos passando de volta o token,

253
00:19:57,405 --> 00:20:00,795
vamos passar de volta a mensagem de status.

254
00:20:00,795 --> 00:20:03,135
Então, aqui vamos dizer

255
00:20:03,135 --> 00:20:12,670
'Login Inbem-sucedido' e, em seguida, a terceira informação,

256
00:20:12,670 --> 00:20:18,070
vamos passar esta informação que o objeto que recebemos aqui como

257
00:20:18,070 --> 00:20:25,635
a terceira parte na mensagem de resposta que enviamos de volta do nosso servidor aqui.

258
00:20:25,635 --> 00:20:28,935
Assim, o sinalizador de sucesso será definido como false,

259
00:20:28,935 --> 00:20:32,385
o status será definido Login Inbem-sucedido e

260
00:20:32,385 --> 00:20:36,725
as informações de erro que são transmitidas nas informações serão passadas de volta.

261
00:20:36,725 --> 00:20:39,855
Agora, observe que essa situação

262
00:20:39,855 --> 00:20:43,125
ocorrerá se o nome de usuário e a senha estiverem incorretos

263
00:20:43,125 --> 00:20:48,600
e, portanto, isso não é um erro no sentido do erro, mas

264
00:20:48,600 --> 00:20:54,040
o fato de que a autenticação não conseguiu localizar o usuário ou a senha do usuário está incorreto.

265
00:20:54,040 --> 00:20:58,530
Então, essa informação será codificada na informação que vem e assim eu vou

266
00:20:58,530 --> 00:21:04,590
passar de volta como um erro para o lado do meu cliente.

267
00:21:04,590 --> 00:21:09,615
A parte de outra forma

268
00:21:09,615 --> 00:21:15,355
é tratada como Req.Login.

269
00:21:15,355 --> 00:21:17,220
Então, se isso for bem sucedido,

270
00:21:17,220 --> 00:21:22,710
o passport.authenticate vamos adicionar este método chamado req.Login para o usuário.

271
00:21:22,710 --> 00:21:24,340
Então, neste ponto,

272
00:21:24,340 --> 00:21:27,950
vamos simplesmente passar no objeto de usuário que obtivemos.

273
00:21:27,950 --> 00:21:31,055
Então, aqui, se chegamos a este ponto,

274
00:21:31,055 --> 00:21:36,195
então isso significa que o objeto de usuário não é nulo e também nenhum erro ocorreu,

275
00:21:36,195 --> 00:21:40,090
então isso significa que o usuário pode ser conectado.

276
00:21:41,080 --> 00:21:44,550
Então, vamos dizer err,

277
00:21:48,960 --> 00:21:51,460
vamos tentar fazer login no usuário.

278
00:21:51,460 --> 00:21:58,000
Então, vamos dizer se errar e

279
00:21:58,000 --> 00:22:05,345
então vamos passar de volta o mesmo tipo de informação de erro que fizemos aqui.

280
00:22:05,345 --> 00:22:09,840
Então, neste caso, se erro,

281
00:22:13,290 --> 00:22:19,430
então vamos passar de volta um código de status como 401 e vamos dizer sucesso

282
00:22:19,430 --> 00:22:25,125
é falso e status como Login mal sucedido,

283
00:22:25,125 --> 00:22:28,340
e, em seguida, as informações de erro,

284
00:22:29,280 --> 00:22:31,840
em vez da informação,

285
00:22:31,840 --> 00:22:42,380
vamos passar em 'Não foi possível fazer login usuário”.

286
00:22:42,380 --> 00:22:48,960
Então, essa é a mensagem que vamos passar aqui se o erro ocorrer.

287
00:22:48,960 --> 00:22:53,200
Caso contrário, estaríamos aqui embaixo.

288
00:22:53,200 --> 00:22:55,960
Então, neste ponto,

289
00:22:55,960 --> 00:22:59,440
seríamos capazes de gerar o token.

290
00:22:59,440 --> 00:23:02,495
Então, se chegamos até este ponto, isso

291
00:23:02,495 --> 00:23:06,370
significa que o usuário logou com sucesso,

292
00:23:06,370 --> 00:23:08,430
e assim podemos agora gerar o token.

293
00:23:08,430 --> 00:23:12,705
Então, vamos gerar o token com base no ID do usuário

294
00:23:12,705 --> 00:23:18,350
e, em seguida, vamos passar de volta o token de volta para o usuário.

295
00:23:18,350 --> 00:23:21,635
Então, aqui, vamos dizer var token,

296
00:23:21,635 --> 00:23:30,730
e então podemos dizer Res.StatusCode é 200 e, em seguida, res.json sucesso verdadeiro,

297
00:23:30,730 --> 00:23:33,600
então, o que significa que o usuário logado com sucesso.

298
00:23:33,600 --> 00:23:38,490
Então, o status seria login bem-sucedido.

299
00:23:38,490 --> 00:23:40,605
Então, a terceira parte,

300
00:23:40,605 --> 00:23:42,360
em vez do erro,

301
00:23:42,360 --> 00:23:46,200
passarei o token de volta ao usuário.

302
00:23:46,200 --> 00:23:48,760
Então, vamos dizer token,

303
00:23:51,100 --> 00:23:54,675
este token que acabamos de obter mais cedo.

304
00:23:54,675 --> 00:24:01,030
Então, esse token será passado como a propriedade token da mensagem de resposta.

305
00:24:01,030 --> 00:24:04,560
Então, aqui, observe que o sucesso é definido como verdadeiro, então,

306
00:24:04,560 --> 00:24:08,340
o que significa que o usuário logado com sucesso,

307
00:24:08,340 --> 00:24:12,290
e assim o usuário pode prosseguir neste ponto.

308
00:24:12,290 --> 00:24:19,050
Isso tem que ser feito dentro do Req.Login aqui.

309
00:24:19,820 --> 00:24:22,970
Então, neste ponto,

310
00:24:22,970 --> 00:24:27,180
vamos fechar o Req.Login.

311
00:24:27,180 --> 00:24:33,735
Então, observe que isso está dentro deste Req.Login aqui.

312
00:24:33,735 --> 00:24:37,320
Então, lá dentro, vamos passar esses três de volta.

313
00:24:37,320 --> 00:24:41,370
Então, deixe-me apenas recuar essas três linhas.

314
00:24:41,720 --> 00:24:48,850
Então, é assim que trataríamos o método de log do usuário.

315
00:24:48,850 --> 00:24:52,230
Então, novamente, revisando esse código mais uma vez.

316
00:24:52,230 --> 00:24:53,950
Então, vamos fazer postagem de roteador,

317
00:24:53,950 --> 00:24:56,815
mas em vez de fazer autenticação de passaporte ali mesmo,

318
00:24:56,815 --> 00:24:58,960
vamos dizer req, res

319
00:24:58,960 --> 00:25:01,240
, em seguida, dentro aqui,

320
00:25:01,240 --> 00:25:04,285
vamos fazer uma autenticação de passaporte para o local,

321
00:25:04,285 --> 00:25:06,560
e este autenticado vai passar de volta.

322
00:25:06,560 --> 00:25:09,250
Então, podemos fornecer uma função de retorno de chamada para isso,

323
00:25:09,250 --> 00:25:11,810
e esta função de retorno de chamada retornará o erro,

324
00:25:11,810 --> 00:25:14,730
o usuário, ou as informações aqui.

325
00:25:14,730 --> 00:25:16,300
Então, se for um erro,

326
00:25:16,300 --> 00:25:20,735
vamos apenas permitir que o manipulador de erros expresso para cuidar disso.

327
00:25:20,735 --> 00:25:22,730
Se o usuário for nulo,

328
00:25:22,730 --> 00:25:26,940
isso significa que o login do usuário não teve êxito,

329
00:25:26,940 --> 00:25:29,730
e a razão para isso estará nas informações.

330
00:25:29,730 --> 00:25:36,870
Então, isso irá passar de volta como o erro de informação na mensagem de resposta aqui.

331
00:25:36,870 --> 00:25:38,790
Se chegarmos a este ponto,

332
00:25:38,790 --> 00:25:43,555
o usuário é verificado com sucesso.

333
00:25:43,555 --> 00:25:45,400
Então, então vamos fazer login no usuário.

334
00:25:45,400 --> 00:25:47,630
Então, o passaporte autenticar,

335
00:25:47,630 --> 00:25:53,385
vamos adicionar neste método chamado login para o req, a mensagem de solicitação.

336
00:25:53,385 --> 00:25:56,770
Então, podemos chamar o login com o usuário.

337
00:25:56,770 --> 00:25:59,355
Se isso retornar um erro,

338
00:25:59,355 --> 00:26:03,105
então retornaremos o erro aqui adequadamente.

339
00:26:03,105 --> 00:26:08,590
Caso contrário, teremos chegado ao ponto em que o usuário é autenticado com sucesso.

340
00:26:08,590 --> 00:26:12,630
Então, podemos gerar o JSON Web Token aqui e, em seguida, retornar

341
00:26:12,630 --> 00:26:18,315
o JSON Web Token para o usuário para confirmar que o usuário está logado com êxito.

342
00:26:18,315 --> 00:26:21,545
Então, esse é o conjunto de passos que vamos usar aqui.

343
00:26:21,545 --> 00:26:25,735
Agora, a razão pela qual eu faço uma maneira mais elaborada de lidar com isso é que

344
00:26:25,735 --> 00:26:30,035
eu quero distinguir entre a situação em que um erro genuíno

345
00:26:30,035 --> 00:26:34,170
ocorre durante o processo de autenticação em vez da

346
00:26:34,170 --> 00:26:39,095
situação em que o nome de usuário é inválido ou a senha é inválida.

347
00:26:39,095 --> 00:26:42,860
Então, esses dois casos serão tratados por esta situação,

348
00:26:42,860 --> 00:26:46,550
onde a informação vai levar a informação de volta para nós.

349
00:26:46,550 --> 00:26:48,900
Então, isso não é um erro per se,

350
00:26:48,900 --> 00:26:52,090
mas é uma situação em que o usuário

351
00:26:52,090 --> 00:26:55,710
não é um usuário válido ou a senha do usuário não é válida.

352
00:26:55,710 --> 00:27:01,070
Então, é assim que vamos lidar com o processo de login do usuário.

353
00:27:01,070 --> 00:27:03,660
Além disso, vou adicionar em

354
00:27:03,660 --> 00:27:14,825
mais um método aqui chamado CheckJWTToken.

355
00:27:14,825 --> 00:27:21,100
É bem possível que, enquanto o cliente efetuou login e obtenha o JSON Web Token,

356
00:27:21,100 --> 00:27:24,855
algum tempo mais tarde, o JSON Web Token pode expirar.

357
00:27:24,855 --> 00:27:32,840
Portanto, se o usuário tentar acessar do lado do cliente com um token expirado para o servidor

358
00:27:32,840 --> 00:27:35,610
, o servidor não será capaz de autenticar o usuário.

359
00:27:35,610 --> 00:27:37,780
Então, em intervalos periódicos,

360
00:27:37,780 --> 00:27:42,180
podemos querer cruzar a verificação para ter certeza de que o JSON Web Token ainda é válido.

361
00:27:42,180 --> 00:27:44,975
Então, essa é a razão pela qual eu estou incluindo este,

362
00:27:44,975 --> 00:27:49,620
outro endpoint chamado CheckJWTToken.

363
00:27:49,620 --> 00:27:53,155
Então, se você fizer um get para o CheckJWTToken

364
00:27:53,155 --> 00:27:58,700
incluindo o token no cabeçalho de autorização,

365
00:27:58,700 --> 00:28:02,490
então esta chamada retornará um verdadeiro ou falso

366
00:28:02,490 --> 00:28:06,535
para indicar a você se o JSON Web Token ainda é válido ou não.

367
00:28:06,535 --> 00:28:10,930
Se não for válido, o lado do cliente poderá iniciar outro login para que

368
00:28:10,930 --> 00:28:15,945
o usuário obtenha um novo Token da Web JSON, se necessário.

369
00:28:15,945 --> 00:28:17,285
Então, para fazer isso,

370
00:28:17,285 --> 00:28:27,109
vamos dizer cors.corsWithOptions e req,

371
00:28:27,109 --> 00:28:31,385
res aqui como esperado.

372
00:28:31,385 --> 00:28:35,670
Aqui, vamos dizer

373
00:28:39,820 --> 00:28:49,360
passaporte autenticar jwt

374
00:28:49,360 --> 00:28:57,150
e sessão: false,

375
00:29:00,020 --> 00:29:07,270
e isso iria retornar err, usuário, informações.

376
00:29:09,020 --> 00:29:13,770
Então, lembre-se de como usamos o passaporte autenticar mais cedo.

377
00:29:13,770 --> 00:29:17,195
Então, chamamos o JWT com sessão falsa aqui.

378
00:29:17,195 --> 00:29:21,745
Então, mais cedo aqui, dizemos passaporte autenticar local.

379
00:29:21,745 --> 00:29:23,535
Então, isso é para a autenticação local.

380
00:29:23,535 --> 00:29:27,330
Então, isso é para a autenticação JSON Web Token.

381
00:29:27,330 --> 00:29:29,430
Então, quando chamamos isso,

382
00:29:29,430 --> 00:29:33,435
em seguida, uma vez que vai verificar o JSON Web Token, então vamos dizer,

383
00:29:33,435 --> 00:29:40,335
se err retorno próximo err,

384
00:29:40,335 --> 00:29:44,895
e, em seguida, deixar o manipulador de erro expresso cuidar dessa situação.

385
00:29:44,895 --> 00:29:50,469
Então, vamos dizer, se não usuário,

386
00:29:53,330 --> 00:30:00,330
se o usuário não existe, então da mesma forma.

387
00:30:00,330 --> 00:30:03,510
Então, o que significa que se o objeto de usuário foi

388
00:30:03,510 --> 00:30:07,810
encontrado a partir do JSON Web Token e depois carregado no req.user,

389
00:30:07,810 --> 00:30:11,400
isso significa que o usuário é um usuário válido

390
00:30:11,400 --> 00:30:13,485
e, portanto, pode ser permitido continuar.

391
00:30:13,485 --> 00:30:20,330
Caso contrário, vamos dizer que o usuário não existe.

392
00:30:20,330 --> 00:30:24,995
Então, precisamos informar que o JSON Web Token expirou.

393
00:30:24,995 --> 00:30:26,180
Então, neste ponto,

394
00:30:26,180 --> 00:30:29,090
vamos enviar uma res com

395
00:30:29,090 --> 00:30:36,545
um código de status de 401.

396
00:30:36,545 --> 00:30:47,130
Então, não autorizado, SetHeader, Content-Type,

397
00:30:49,900 --> 00:30:56,280
application/json e, em seguida, vamos retornar res.

398
00:30:58,680 --> 00:31:13,750
Res.json vai dizer status JWT

399
00:31:13,750 --> 00:31:17,090
inválido e, em seguida,

400
00:31:17,730 --> 00:31:23,690
vamos retornar um sinalizador chamado sucesso cai e, em seguida,

401
00:31:23,880 --> 00:31:29,080
vamos retornar as informações que obtemos se o usuário

402
00:31:29,080 --> 00:31:34,460
não é autenticado como o erro neste ponto.

403
00:31:36,420 --> 00:31:40,480
Caso contrário, isso significa que chegamos a este ponto,

404
00:31:40,480 --> 00:31:43,220
então o usuário é um usuário válido.

405
00:31:43,220 --> 00:31:44,850
Então, neste caso,

406
00:31:44,850 --> 00:31:47,230
deixe-me apenas copiar esse código aqui,

407
00:31:47,230 --> 00:31:54,070
estaremos enviando um código de status de 200 e, em seguida, o res.json,

408
00:31:54,070 --> 00:32:02,720
enviará JWT válido e bem sucedido sendo verdadeiro.

409
00:32:02,940 --> 00:32:09,820
A terceira parte, enviaremos as informações do usuário.

410
00:32:09,820 --> 00:32:16,000
Dessa forma, quando esse endpoint é chamado com o método get,

411
00:32:16,000 --> 00:32:19,170
então isso verificará se o token é válido ou não.

412
00:32:19,170 --> 00:32:20,220
Se o token for válido,

413
00:32:20,220 --> 00:32:24,020
então você receberá esta resposta e da bandeira de sucesso na resposta,

414
00:32:24,020 --> 00:32:27,770
você pode verificar se o jsonwebtoken é válido ou não.

415
00:32:27,770 --> 00:32:32,155
Isso é útil no lado do cliente.

416
00:32:32,155 --> 00:32:37,825
Agora, este passaporte autenticado aqui terá que ser fornecido

417
00:32:37,825 --> 00:32:43,790
com req e res como os dois parâmetros aqui.

418
00:32:43,790 --> 00:32:47,630
Então, é assim que chamamos o passaporte de autenticar.

419
00:32:47,630 --> 00:32:49,355
Então, observe que sempre que você chamar

420
00:32:49,355 --> 00:32:52,840
passaporte autenticar e esperar esta função de retorno de chamada aqui,

421
00:32:52,840 --> 00:33:01,825
você precisa anexar a este ponto req.res para o passaporte autenticar na parte de trás aqui.

422
00:33:01,825 --> 00:33:03,890
Em nosso servidor API descanso,

423
00:33:03,890 --> 00:33:07,490
nós tínhamos implementado nossos comentários de tal forma que os comentários

424
00:33:07,490 --> 00:33:12,245
formaram sub-documentos dentro do documento do dishe,

425
00:33:12,245 --> 00:33:16,540
então eles compram cada prato fechado seu próprio conjunto de comentários.

426
00:33:16,540 --> 00:33:19,520
Mas a forma como implementamos o nosso cliente React é

427
00:33:19,520 --> 00:33:22,965
tal que os comentários são mantidos independentes dos pratos,

428
00:33:22,965 --> 00:33:27,680
e os próprios comentários carregaram o ID do prato correspondente.

429
00:33:27,680 --> 00:33:30,400
Agora, essas são duas maneiras diferentes de

430
00:33:30,400 --> 00:33:34,445
implementar o lado do servidor, bem como o lado do cliente.

431
00:33:34,445 --> 00:33:39,685
Na aplicação Angular que estamos implementados em nossa especialização Angular,

432
00:33:39,685 --> 00:33:43,470
usamos o método de subdocumento para

433
00:33:43,470 --> 00:33:47,560
lidar com comentários em nosso aplicativo de cliente Angular.

434
00:33:47,560 --> 00:33:50,050
Assim, o servidor API restante foi

435
00:33:50,050 --> 00:33:54,090
implementado de tal forma que era mais adequado para o cliente Angular.

436
00:33:54,090 --> 00:34:00,600
Mas para os clientes React desde que mantivemos os comentários independentes dos pratos,

437
00:34:00,600 --> 00:34:03,985
e, em seguida, usar o ID prato dentro do comentário,

438
00:34:03,985 --> 00:34:09,300
então precisamos reestruturar o nosso servidor API resto,

439
00:34:09,300 --> 00:34:16,835
por isso é que temos um ponto final de comentário separado independente do endpoint pratos.

440
00:34:16,835 --> 00:34:22,310
Então, precisamos reestruturar nosso código no servidor

441
00:34:22,310 --> 00:34:29,140
para introduzir o endpoint da API REST /comments nesta fase.

442
00:34:29,140 --> 00:34:30,600
Então, para fazer isso,

443
00:34:30,600 --> 00:34:37,540
vamos em frente e implementar um novo modelo chamado como comment.js.

444
00:34:37,540 --> 00:34:39,260
Então, indo para os modelos,

445
00:34:39,260 --> 00:34:45,790
deixe-me implementar um novo arquivo chamado comments.js.

446
00:34:47,220 --> 00:34:50,015
No arquivo comments.js,

447
00:34:50,015 --> 00:34:56,110
vamos mover o CommentSchema do

448
00:34:56,110 --> 00:35:02,660
arquivo dishes.js para o arquivo comments.js e, em seguida, removê-lo completamente do arquivo dishes.js.

449
00:35:02,660 --> 00:35:03,900
Mas antes de fazer isso,

450
00:35:03,900 --> 00:35:08,770
precisamos copiar o mangusto e o esquema a partir daqui,

451
00:35:08,770 --> 00:35:13,860
então deixe-me apenas copiar isso de dishes.js para comment.js.

452
00:35:13,860 --> 00:35:16,590
Depois disso, indo para dishes.js,

453
00:35:16,590 --> 00:35:21,040
deixe-me cortar este CommentSchema completamente para fora daqui,

454
00:35:21,040 --> 00:35:28,300
porque vamos ter isso separadamente no modelo de comentários aqui.

455
00:35:28,300 --> 00:35:33,070
Então, vamos mover isso para o modelo de comentários e, em seguida, colá-lo aqui.

456
00:35:33,070 --> 00:35:35,050
Mas é claro que este não é o completo,

457
00:35:35,050 --> 00:35:37,870
vamos estar atualizando o CommentSchema um pouco.

458
00:35:37,870 --> 00:35:39,300
Mas antes de fazer isso,

459
00:35:39,300 --> 00:35:43,455
volte para o arquivo dishes.js e no arquivo de pratos,

460
00:35:43,455 --> 00:35:47,925
removeremos os comentários do DisHessChema,

461
00:35:47,925 --> 00:35:51,510
porque vamos armazenar o conteúdo separadamente dos

462
00:35:51,510 --> 00:35:55,550
pratos nesta versão do nosso servidor.

463
00:35:55,550 --> 00:36:00,450
Então, é assim que vamos atualizar o modelo de pratos aqui.

464
00:36:00,450 --> 00:36:08,180
Então, removemos os comentários completamente do modelo de pratos aqui.

465
00:36:08,180 --> 00:36:10,270
Indo para o modelo de comentários,

466
00:36:10,270 --> 00:36:15,355
então agora vemos que temos o CommentSchema implementado aqui.

467
00:36:15,355 --> 00:36:19,525
Mas, além disso, no CommentsSchema,

468
00:36:19,525 --> 00:36:23,330
agora precisamos apontar explicitamente para

469
00:36:23,330 --> 00:36:28,885
o prato específico para o qual este comentário é o comentário correspondente.

470
00:36:28,885 --> 00:36:30,700
Agora, aqui é onde

471
00:36:30,700 --> 00:36:37,435
nossa população de mangustos e

472
00:36:37,435 --> 00:36:41,580
a forma como armazenamos os objetos IDs vem em nosso resgate.

473
00:36:41,580 --> 00:36:45,860
Então, vamos atualizar o CommentSchema dizendo que teremos a classificação,

474
00:36:45,860 --> 00:36:47,800
o comentário e o autor aqui.

475
00:36:47,800 --> 00:36:49,110
Além do autor,

476
00:36:49,110 --> 00:36:56,080
vamos introduzir mais um campo chamado como o prato aqui que é

477
00:36:56,080 --> 00:37:05,540
do tipo: Mongoose.Schema types.ObjectID,

478
00:37:06,390 --> 00:37:19,870
e assim isso vai se referir ao prato aqui.

479
00:37:19,870 --> 00:37:29,060
Então, este seria um objeto de referência para o modelo de prato aqui,

480
00:37:29,060 --> 00:37:32,255
e assim com esta modificação agora

481
00:37:32,255 --> 00:37:36,640
nossos comentários irão conter o campo de classificação, o campo de comentário,

482
00:37:36,640 --> 00:37:42,355
o autor que é novamente uma referência ao usuário correspondente,

483
00:37:42,355 --> 00:37:47,660
e então o campo de prato que é uma referência ao correspondente prato aqui.

484
00:37:47,660 --> 00:37:50,060
Então, o que significa que agora precisamos

485
00:37:50,060 --> 00:37:53,640
preencher os comentários com o autor e o campo do prato.

486
00:37:53,640 --> 00:37:55,565
Uma vez que tenhamos concluído isso,

487
00:37:55,565 --> 00:38:01,585
então vamos dizer var Comentários

488
00:38:01,585 --> 00:38:09,910
mongoose.model e vamos chamar isso de '

489
00:38:09,910 --> 00:38:16,765
Comentário', e então isso usa o CommentSchema que acabamos de definir aqui,

490
00:38:16,765 --> 00:38:21,970
e então precisamos exportar isso a partir daqui,

491
00:38:21,970 --> 00:38:25,280
o comments.model a partir daqui.

492
00:38:25,280 --> 00:38:28,395
Então, agora que introduzimos os comments.model,

493
00:38:28,395 --> 00:38:35,045
então vamos em frente e, em seguida, introduzir um novo roteador chamado como CommentRouter.

494
00:38:35,045 --> 00:38:37,060
Então, para introduzir o roteador de comentários,

495
00:38:37,060 --> 00:38:39,630
vamos para as rotas aqui

496
00:38:39,630 --> 00:38:45,990
e, em seguida, criar um novo arquivo chamado commentRouter.js.

497
00:38:47,090 --> 00:38:52,415
No commentRouter.js, deixe-me copiar algumas coisas

498
00:38:52,415 --> 00:38:59,890
do DishRouter.

499
00:38:59,890 --> 00:39:07,720
Então, vamos ter esses comentários aqui,

500
00:39:07,720 --> 00:39:14,865
então deixe-me copiar sobre essas coisas do e também,

501
00:39:14,865 --> 00:39:21,070
enquanto eu estou nele deixe-me apenas copiar estes também até esse ponto,

502
00:39:21,070 --> 00:39:24,625
e então eu vou atualizar isso um pouco mais tarde.

503
00:39:24,625 --> 00:39:26,680
Então, indo para o CommentRouter,

504
00:39:26,680 --> 00:39:28,040
precisamos de todas essas partes,

505
00:39:28,040 --> 00:39:33,640
então vamos dizer Com, Express, BodyParser, mangusto

506
00:39:33,640 --> 00:39:37,735
, autenticar, cors, e então

507
00:39:37,735 --> 00:39:46,490
estaremos importando comentários de modelos/comentários.

508
00:39:49,950 --> 00:40:00,460
Em seguida, vamos chamar isso como o CommentRouter que é um Express.Router aqui.

509
00:40:02,060 --> 00:40:11,950
Então vamos dizer CommentRouter usar BodyParser,

510
00:40:11,950 --> 00:40:17,915
e então isso agora se tornaria rota CommentRouter.

511
00:40:17,915 --> 00:40:22,030
Agora, precisamos entrar no DisishRouter e, em seguida,

512
00:40:22,030 --> 00:40:27,200
remover todas as partes que se referem aos comentários aqui.

513
00:40:27,200 --> 00:40:34,330
Então, deixe-me apenas cortar esta parte e, em seguida, vamos reutilizar estes para o nosso CommentRouter.

514
00:40:34,330 --> 00:40:38,200
Então, tudo isso não é mais necessário no DishRouter.

515
00:40:38,200 --> 00:40:42,080
Então, eu vou remover tudo isso do DishRouter aqui,

516
00:40:42,080 --> 00:40:43,770
então deixe-me cortá-los,

517
00:40:43,770 --> 00:40:48,715
tudo relacionado à rota de comentários do DishRouter,

518
00:40:48,715 --> 00:40:50,770
então vamos para o CommentRouter,

519
00:40:50,770 --> 00:40:54,405
e então deixe-me ir em frente e colar isso no lugar aqui,

520
00:40:54,405 --> 00:40:57,100
então vamos editar isso aqui.

521
00:40:57,100 --> 00:41:02,660
Então, depois disso, precisamos exportar o CommentRouter.

522
00:41:05,160 --> 00:41:08,205
Então, vai exportar o CommentRouter para nós.

523
00:41:08,205 --> 00:41:12,060
Mas, claro, esse código não é completamente preciso.

524
00:41:12,060 --> 00:41:14,995
Então, precisamos ir em frente e corrigir este código aqui.

525
00:41:14,995 --> 00:41:16,585
Então, para este código,

526
00:41:16,585 --> 00:41:20,180
agora percebemos que esta não é a rota DishRouter,

527
00:41:20,180 --> 00:41:21,785
em vez disso, deve ser

528
00:41:21,785 --> 00:41:27,700
o endpoint /porque

529
00:41:27,700 --> 00:41:33,685
vamos montar isso no ponto de extremidade /comments aqui.

530
00:41:33,685 --> 00:41:35,685
Então, vamos dizer CommentRouter

531
00:41:35,685 --> 00:41:39,859
e, em seguida, as opções CorsWithOptions (req,

532
00:41:39,859 --> 00:41:42,550
res) que permanece como tal lá,

533
00:41:42,550 --> 00:41:48,429
e, em seguida, o get cors.cors e, em seguida, req.res,

534
00:41:48,429 --> 00:41:52,460
e, em seguida, este se tornará comentários.

535
00:41:53,880 --> 00:41:58,430
FindByID, req.

536
00:42:00,600 --> 00:42:05,330
Então, isso seria comments.Find

537
00:42:07,050 --> 00:42:17,080
e req.query aqui.

538
00:42:17,080 --> 00:42:20,920
Então, quando os comentários são encontrados

539
00:42:20,920 --> 00:42:22,974
, então, neste ponto,

540
00:42:22,974 --> 00:42:25,940
vamos preencher o autor,

541
00:42:26,880 --> 00:42:30,430
já tem lá, preencher aqui.

542
00:42:30,430 --> 00:42:33,380
Então, eu vou apenas remover esses comentários.autor, e então,

543
00:42:33,380 --> 00:42:37,410
vamos simplesmente preencher o autor aqui.

544
00:42:37,410 --> 00:42:44,425
Então, isso nos daria comentários aqui.

545
00:42:44,425 --> 00:42:49,310
Então, vamos dizer, isso pode ser simplificado significativamente.

546
00:42:49,310 --> 00:42:53,835
Então, o erro de captura está lá de qualquer maneira.

547
00:42:53,835 --> 00:43:00,805
Então, quando o comentário chegar, ele simplesmente retornará.

548
00:43:00,805 --> 00:43:03,910
Desculpe, deveria ser.

549
00:43:03,910 --> 00:43:06,525
Então, se para o get,

550
00:43:06,525 --> 00:43:09,305
quando recebemos os comentários,

551
00:43:09,305 --> 00:43:13,760
comments.Find req.query, .populate autor aqui,

552
00:43:13,760 --> 00:43:18,010
e então, vamos dizer, .then comentários,

553
00:43:18,010 --> 00:43:21,619
e então, vamos dizer, res.StatusCode 200,

554
00:43:21,619 --> 00:43:27,605
SetHeader e, em seguida, retornaremos os comentários daqui,

555
00:43:27,605 --> 00:43:30,850
res.json comentários daqui.

556
00:43:30,850 --> 00:43:36,970
Agora, eu não estou preenchendo os pratos aqui porque eu não preciso explicitamente

557
00:43:36,970 --> 00:43:45,300
dos pratos da maneira que eu uso esta informação no meu cliente reagir.

558
00:43:45,300 --> 00:43:46,840
Eu só preciso do ID do prato,

559
00:43:46,840 --> 00:43:49,085
e o ID do prato já está presente lá,

560
00:43:49,085 --> 00:43:55,310
e isso é bom o suficiente para eu usar esses dados no meu cliente reagir.

561
00:43:55,310 --> 00:43:57,685
Então, eu vou deixá-lo como tal lá.

562
00:43:57,685 --> 00:43:59,530
Eu só vou preencher

563
00:43:59,530 --> 00:44:02,910
as informações do autor lá porque precisamos da informação completa do autor

564
00:44:02,910 --> 00:44:08,930
sempre que renderizamos um item de comentário em nosso cliente reagir.

565
00:44:08,930 --> 00:44:12,655
Então, o get será atualizado assim aqui.

566
00:44:12,655 --> 00:44:22,015
Para o post corsWithOptions,

567
00:44:22,015 --> 00:44:26,070
diremos, Authenticate.VerifyUser req, res, próximo.

568
00:44:26,070 --> 00:44:29,540
Obviamente, para que um comentário seja postado,

569
00:44:29,540 --> 00:44:38,315
você precisa que o autor seja um usuário logado válido.

570
00:44:38,315 --> 00:44:42,910
Só então, você permitirá que o usuário publique um comentário.

571
00:44:42,910 --> 00:44:49,020
Em seguida, o comentário em si vem no corpo da mensagem de solicitação de entrada.

572
00:44:49,020 --> 00:44:51,810
Então, primeiro, vamos verificar o corpo

573
00:44:51,810 --> 00:44:58,865
para ter certeza de que o comentário está incluído no corpo aqui.

574
00:44:58,865 --> 00:45:03,730
Então, aqui, eu vou remover todas essas partes, e então,

575
00:45:03,730 --> 00:45:06,100
simplificá-lo ainda mais, e então,

576
00:45:06,100 --> 00:45:09,430
vamos implementar isso corretamente lá.

577
00:45:09,430 --> 00:45:17,755
Então, neste ponto, vamos dizer,

578
00:45:17,755 --> 00:45:27,465
se req.body não

579
00:45:27,465 --> 00:45:35,030
é igual a null, então o que significa que há um comentário que está fechado dentro do corpo.

580
00:45:37,380 --> 00:45:45,025
Então, deixe-me cortar isso e mover isso para a parte if aqui,

581
00:45:45,025 --> 00:45:47,155
e então, vamos editar isso aqui.

582
00:45:47,155 --> 00:45:52,245
Então, se o corpo não existir,

583
00:45:52,245 --> 00:45:56,140
então causaremos um erro.

584
00:45:56,140 --> 00:46:01,220
Então, vamos dizer, err novo erro,

585
00:46:01,500 --> 00:46:08,965
Comentário não encontrado no corpo da solicitação.

586
00:46:08,965 --> 00:46:12,440
Então, vamos levantar esse erro aqui.

587
00:46:12,450 --> 00:46:16,425
O status do erro é 404.

588
00:46:16,425 --> 00:46:20,385
Então, vamos dizer, retornar o próximo erro.

589
00:46:20,385 --> 00:46:26,560
Então, vamos lidar com a parte de erro aqui se o corpo

590
00:46:26,560 --> 00:46:33,280
não contém as informações de comentários apropriadas.

591
00:46:33,280 --> 00:46:35,450
Se contiver, então, é claro,

592
00:46:35,450 --> 00:46:38,170
o que faremos a seguir é,

593
00:46:38,170 --> 00:46:48,310
vamos dizer, req.body.author é req.user.

594
00:46:50,420 --> 00:46:55,610
A razão pela qual estamos fazendo isso é que nós lembramos que se ele

595
00:46:55,610 --> 00:46:59,950
é um usuário registrado e o usuário fez login,

596
00:46:59,950 --> 00:47:03,050
então o req.user conterá as informações do usuário.

597
00:47:03,050 --> 00:47:07,260
Então, eu só preciso do ID do usuário conectado no momento.

598
00:47:07,260 --> 00:47:10,310
Então, vamos dizer, req.user. _id e, em seguida,

599
00:47:10,310 --> 00:47:14,645
definiremos o req.body.author para req.user. _id.

600
00:47:14,645 --> 00:47:20,070
Agora, o usuário de verificação irá garantir automaticamente que, se você aterrissar neste ponto,

601
00:47:20,070 --> 00:47:25,710
então você obviamente teria um usuário que fez login corretamente.

602
00:47:25,710 --> 00:47:28,605
Caso contrário, isso já teria causado o problema.

603
00:47:28,605 --> 00:47:30,260
Então, quando você chegar a este ponto,

604
00:47:30,260 --> 00:47:37,660
você teria um usuário válido que já fez login no sistema lá dentro.

605
00:47:37,660 --> 00:47:43,460
Então, é aqui que você seria capaz agora.

606
00:47:43,460 --> 00:47:46,040
Então, o que estamos fazendo é que o campo autor,

607
00:47:46,040 --> 00:47:50,625
estamos explicitamente configurando-o na ID do usuário aqui para que

608
00:47:50,625 --> 00:47:57,490
o req.body contenha as partes restantes do comentário.

609
00:47:57,490 --> 00:48:01,315
Então, como você percebe, o comentário contém a classificação,

610
00:48:01,315 --> 00:48:04,540
o comentário em si, e o autor, e os campos de prato.

611
00:48:04,540 --> 00:48:11,510
Então, as partes restantes devem ter sido preenchidas pelo usuário.

612
00:48:11,510 --> 00:48:14,730
A classificação, o comentário

613
00:48:14,730 --> 00:48:17,775
e as informações do prato já devem ser preenchidas

614
00:48:17,775 --> 00:48:20,840
no corpo da mensagem de solicitação recebida.

615
00:48:20,840 --> 00:48:23,460
A parte do autor é deixada não preenchida lá,

616
00:48:23,460 --> 00:48:28,380
que vamos inserir explicitamente neste ponto no corpo aqui.

617
00:48:28,380 --> 00:48:32,515
Então, agora, o req.body conterá toda a informação do comentário.

618
00:48:32,515 --> 00:48:34,440
Então, neste ponto,

619
00:48:34,440 --> 00:48:43,400
em vez de fazer isso, vamos dizer, comentários.Criar.

620
00:48:44,550 --> 00:48:49,940
Usando o req.body, vamos criar os comentários aqui.

621
00:48:50,010 --> 00:48:53,304
Então, isso retornará

622
00:48:53,304 --> 00:48:58,735
o comentário correspondente ao comentário que acabamos de inserir aqui.

623
00:48:58,735 --> 00:49:00,755
Agora, uma vez que o comentário retornou,

624
00:49:00,755 --> 00:49:07,050
então devemos fazer comments.findByID.

625
00:49:07,050 --> 00:49:09,680
Agora, a razão pela qual precisamos fazer isso é porque precisamos

626
00:49:09,680 --> 00:49:13,070
preencher as informações do autor aqui.

627
00:49:13,780 --> 00:49:18,144
Então, vamos dizer, comentários FindByID. _id

628
00:49:18,144 --> 00:49:26,155
e, em seguida, preencheremos as informações do autor no próprio comentário.

629
00:49:26,155 --> 00:49:34,610
Então, vamos dizer, depois comentar.

630
00:49:36,570 --> 00:49:41,115
Agora, obviamente, aqui, você descobriria que o comentário

631
00:49:41,115 --> 00:49:44,880
existirá porque nós acabamos de inserir esse comentário no lugar lá.

632
00:49:44,880 --> 00:49:54,470
Então, aqui, vamos simplesmente retornar, 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
O comentário em si dirá, res.json, e então,

635
00:50:18,430 --> 00:50:21,745
retornará o comentário neste ponto.

636
00:50:21,745 --> 00:50:26,255
Então, esta é a maneira que vamos lidar com a inserção de

637
00:50:26,255 --> 00:50:30,805
um novo comentário no lado do nosso cliente aqui.

638
00:50:30,805 --> 00:50:33,925
Para o put, como você percebe,

639
00:50:33,925 --> 00:50:38,360
você não será capaz de fazer um put sobre os pontos finais /comments/.

640
00:50:38,360 --> 00:50:47,610
Então, vamos dizer, operação PUT não suportada em /comments/ ponto final.

641
00:50:52,050 --> 00:50:56,180
Esse é o ponto. Essa é a mensagem que você retornará.

642
00:50:56,180 --> 00:50:58,570
Então, StatusCode é 403

643
00:50:58,570 --> 00:51:02,610
e, em seguida, operação PUT não suportada em /comments/.

644
00:51:02,610 --> 00:51:05,260
Agora, quando fazemos uma exclusão,

645
00:51:13,230 --> 00:51:22,840
deixe-me apenas cortar isso a partir daqui, e então, vamos dizer,

646
00:51:30,440 --> 00:51:32,835
comentários.Remover.

647
00:51:32,835 --> 00:51:37,710
escrito vazio. Então, quando você faz uma exclusão no ponto final de comentários barra,

648
00:51:37,710 --> 00:51:40,990
você removerá todos os comentários do seu sistema.

649
00:51:40,990 --> 00:51:43,680
Então, esta é uma operação muito perigosa, e assim,

650
00:51:43,680 --> 00:51:48,990
você não deve estar fazendo isso normalmente.

651
00:51:48,990 --> 00:51:53,860
Então, só permitiremos que o administrador execute tal operação.

652
00:51:53,860 --> 00:51:59,410
Então, removeremos todos os comentários de lá.

653
00:51:59,410 --> 00:52:01,940
Então, quando você receber a resposta,

654
00:52:01,940 --> 00:52:07,700
então vamos dizer Res.StatusCode 200.

655
00:52:07,700 --> 00:52:11,080
Então, deixe-me copiar estas partes aqui,

656
00:52:12,090 --> 00:52:18,130
e depois vir e colá-las aqui.

657
00:52:18,130 --> 00:52:21,330
Então, vamos dizer, comentários.remover.

658
00:52:21,330 --> 00:52:30,480
Em seguida, resposta Res.StatusCode 200 aplicação json e, em seguida, res.json (resposta) aqui.

659
00:52:30,480 --> 00:52:33,100
Então, é assim que lidamos com a exclusão.

660
00:52:33,100 --> 00:52:37,280
Excluir operação no ponto de extremidade de comentários de barra.

661
00:52:37,280 --> 00:52:43,135
Agora, a próxima rota é o roteador de comentários.

662
00:52:43,135 --> 00:52:49,490
Então, aqui vamos dizer commentRouter.route e

663
00:52:49,490 --> 00:52:56,820
o ponto final aqui seria a barra commentId.

664
00:53:01,190 --> 00:53:05,580
Então, aqui as opções permanecerão como tal.

665
00:53:05,580 --> 00:53:09,760
Em seguida, para entrar no roteador atual,

666
00:53:09,760 --> 00:53:20,455
para o get vamos dizer, comments.findById (req.params.

667
00:53:20,455 --> 00:53:25,040
Este seria CommentID.

668
00:53:25,380 --> 00:53:31,029
Então, uma vez que encontramos o comentário específico,

669
00:53:31,029 --> 00:53:37,525
então vamos preencher apenas o autor de lá.

670
00:53:37,525 --> 00:53:39,985
Então, uma vez que você preencher o autor,

671
00:53:39,985 --> 00:53:45,830
então vamos dizer, em seguida, comentar.

672
00:53:47,880 --> 00:53:51,310
Agora, toda essa parte é desnecessária aqui,

673
00:53:51,310 --> 00:53:54,440
então eu vou deletar a parte.

674
00:53:54,480 --> 00:54:00,985
Esta também não é a coisa apropriada aqui.

675
00:54:00,985 --> 00:54:04,540
Então, deixe-me renomear código.

676
00:54:04,540 --> 00:54:08,990
Então, vamos dizer para o get comments.findById,

677
00:54:11,550 --> 00:54:15,385
em seguida, preencher o autor,

678
00:54:15,385 --> 00:54:20,365
em seguida, comentar, res.statusCode é 200, setHeader.

679
00:54:20,365 --> 00:54:22,435
Então o resto é JSON.

680
00:54:22,435 --> 00:54:29,960
Vamos simplesmente retornar os comentários aqui.

681
00:54:39,240 --> 00:54:46,750
Então, nós estaremos retornando o comentário neste ponto, res.json (comentário).

682
00:54:46,750 --> 00:54:49,340
Você encontrará o comentário específico

683
00:54:49,340 --> 00:54:52,415
e, em seguida, retornará esse comentário para a postagem.

684
00:54:52,415 --> 00:54:55,185
Para a pós-operação, como você percebe,

685
00:54:55,185 --> 00:54:56,900
a pós-operação não é

686
00:54:56,900 --> 00:55:06,740
permitida nos comentários ComentID.

687
00:55:10,080 --> 00:55:13,805
Então, essa é a mensagem que vamos enviar,

688
00:55:13,805 --> 00:55:19,110
operação POST não suportada em comentários barra ComentID.

689
00:55:19,110 --> 00:55:23,640
Então, essa é a mensagem que diremos para o posto.

690
00:55:23,640 --> 00:55:33,730
Agora, para o put, vamos dizer comments.Find where Id (req.params.commentId).

691
00:55:34,890 --> 00:55:39,230
Então, vamos encontrar o comentário lá,

692
00:55:40,890 --> 00:55:48,070
e há comentário, então para o colocar.

693
00:55:48,070 --> 00:55:50,805
Então, vamos encontrar o comentário lá,

694
00:55:50,805 --> 00:55:53,400
e então vamos dizer para os comentários.

695
00:55:53,400 --> 00:55:55,305
Então, se encontrarmos o comentário,

696
00:55:55,305 --> 00:56:07,080
se o comentário não for nulo,

697
00:56:07,080 --> 00:56:19,455
então também vamos verificar se comment.author.

698
00:56:19,455 --> 00:56:32,625
Caso contrário, comment.arthur é igual a (req.user. _id).

699
00:56:32,625 --> 00:56:38,095
Então, estamos verificando para garantir que

700
00:56:38,095 --> 00:56:43,755
o comments.author é o mesmo que o usuário atual.

701
00:56:43,755 --> 00:56:50,950
Somente o usuário atual que está conectado - se o usuário for o mesmo que o autor dos comentários

702
00:56:50,950 --> 00:56:53,760
, o usuário terá permissão para atualizar.

703
00:56:53,760 --> 00:56:57,190
Então, essa é a primeira coisa que vamos verificar.

704
00:56:57,190 --> 00:57:01,900
Então, comentários e comentários.author.equal para rec.user. _id.

705
00:57:01,900 --> 00:57:07,860
Se não, então você dirá que não está autorizado a atualizar este comentário.

706
00:57:07,860 --> 00:57:10,859
Como você vê o.403

707
00:57:10,859 --> 00:57:13,090
e, em seguida, retornar o próximo erro aqui.

708
00:57:13,090 --> 00:57:16,705
Então, vamos criar o erro lá.

709
00:57:16,705 --> 00:57:21,800
Então, depois disso, então diremos

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

711
00:57:40,010 --> 00:57:42,215
Isso é importante.

712
00:57:42,215 --> 00:57:45,580
Agora, esses dois não são necessários aqui,

713
00:57:45,580 --> 00:57:51,385
porque estamos salvando diretamente o comentário.

714
00:57:51,385 --> 00:58:05,980
Em seguida, pílulas, vamos dizer comentários.findByidAndUpdate,

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

716
00:58:14,965 --> 00:58:18,395
Então, vamos encontrar esse comentário específico,

717
00:58:18,395 --> 00:58:21,925
porque já foi fornecido o ID do comentário.

718
00:58:21,925 --> 00:58:27,205
Então, vamos fazer comentários findById req.params.commentId.

719
00:58:27,205 --> 00:58:30,260
Então vamos dizer então (comentário).

720
00:58:32,730 --> 00:58:38,705
Quando você fornecer o req.params.commentId,

721
00:58:38,705 --> 00:58:42,275
teremos que fornecer explicitamente o segundo parâmetro,

722
00:58:42,275 --> 00:58:45,825
que é o que queremos alterar.

723
00:58:45,825 --> 00:58:52,285
Então, vamos dizer $set: req.body.

724
00:58:52,285 --> 00:58:54,970
Então, o segundo parâmetro, essencialmente,

725
00:58:54,970 --> 00:58:58,740
informa qual parte você está mudando.

726
00:58:58,740 --> 00:59:03,710
Agora, uma vez que nos foi fornecido o corpo contendo o comentário atualizado,

727
00:59:03,710 --> 00:59:09,140
nós vamos apenas atualizar o comentário inteiro em si.

728
00:59:09,510 --> 00:59:18,205
Então a outra parte que pediremos é nova: verdadeira.

729
00:59:18,205 --> 00:59:23,240
Então, isso garantirá que o comentário atualizado será retornado

730
00:59:23,240 --> 00:59:29,815
no den desta chamada para o comments.findByidAndUpdate.

731
00:59:29,815 --> 00:59:32,565
Então, vamos dizer então comentários.

732
00:59:32,565 --> 00:59:35,214
Quando esse comentário é retornado,

733
00:59:35,214 --> 00:59:38,440
então vamos dizer comments.findById (comment. _id).

734
00:59:46,200 --> 00:59:51,460
Em seguida, preencha o autor lá.

735
00:59:51,460 --> 00:59:53,785
Vamos preencher o autor lá,

736
00:59:53,785 --> 00:59:58,490
e então vamos dizer então comentar.

737
00:59:58,700 --> 01:00:09,680
Então, você vê que vamos obter o comentário e, em seguida, retornar o comentário neste ponto.

738
01:00:09,680 --> 01:00:13,095
Então, é assim que vamos atualizar o comentário.

739
01:00:13,095 --> 01:00:17,395
Então, esta é a situação em que o comentário não é nulo.

740
01:00:17,395 --> 01:00:20,625
Então, esta declaração se para o comentário não é nula.

741
01:00:20,625 --> 01:00:23,785
Então, o outro se parte,

742
01:00:23,785 --> 01:00:29,020
agora isso não é aplicável,

743
01:00:29,020 --> 01:00:33,325
então vamos dizer mais, erro.

744
01:00:33,325 --> 01:00:35,470
O erro neste caso.

745
01:00:35,470 --> 01:00:37,825
Então, se o comentário é nulo,

746
01:00:37,825 --> 01:00:40,850
isso significa que não encontramos o comentário lá,

747
01:00:40,850 --> 01:00:43,650
então você não pode modificar um comentário inexistente.

748
01:00:43,650 --> 01:00:44,805
Então, vamos dizer err,

749
01:00:44,805 --> 01:00:54,700
novo comentário de erro req.params.commentId não encontrado e, em seguida, vamos retornar o erro.

750
01:00:54,700 --> 01:01:01,255
Então, é assim que vamos lidar com a parte put do nosso comentário aqui,

751
01:01:01,255 --> 01:01:04,099
e, finalmente, a exclusão.

752
01:01:06,120 --> 01:01:11,130
Para excluir, novamente teremos que primeiro encontrar

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

754
01:01:12,900 --> 01:01:25,720
e depois comentar.

755
01:01:25,720 --> 01:01:28,150
Então, vamos procurar o comentário.

756
01:01:28,150 --> 01:01:34,160
Então, vamos primeiro verificar se o comentário não é igual a null.

757
01:01:36,180 --> 01:01:39,955
É importante verificar aqui.

758
01:01:39,955 --> 01:01:50,990
Em seguida, a próxima parte que vamos verificar é se o comment.author é igual a req.user. _id.

759
01:01:58,830 --> 01:02:03,400
Nós certificamo-nos de que este usuário que está tentando excluir

760
01:02:03,400 --> 01:02:08,060
este comentário é exatamente o mesmo usuário que inseriu o comentário em primeiro lugar.

761
01:02:08,060 --> 01:02:10,750
Caso contrário, então, se esta for a situação,

762
01:02:10,750 --> 01:02:13,920
então você verá 'Você não está autorizado a excluir este comentário! '

763
01:02:13,920 --> 01:02:16,365
E, em seguida, retornar o status lá.

764
01:02:16,365 --> 01:02:20,920
Em seguida, abaixo aqui,

765
01:02:20,920 --> 01:02:41,310
vamos dizer comments.findByIdandRemove aqui.

766
01:02:41,310 --> 01:02:48,750
Então, vamos dizer comments.findByIdandRemove (req.params.commentId),

767
01:02:48,750 --> 01:02:54,035
então vamos obter alguma resposta do comentário.

768
01:02:54,035 --> 01:02:55,630
Então, neste ponto,

769
01:02:55,630 --> 01:02:59,830
vamos simplesmente dizer, Res.StatusCode.

770
01:02:59,830 --> 01:03:05,365
Então, vamos dizer comments.findByIdandRemove, em seguida, resposta.

771
01:03:05,365 --> 01:03:07,210
Se ele for removido corretamente,

772
01:03:07,210 --> 01:03:10,915
diremos 200 e, em seguida, res.json

773
01:03:10,915 --> 01:03:17,260
resposta aqui e também vamos pegar o erro neste ponto.

774
01:03:17,260 --> 01:03:25,195
Então, deixe-me copiar isso aqui e então incluiremos a captura do erro neste momento.

775
01:03:25,195 --> 01:03:28,895
Então, essa é a primeira coisa que vamos verificar.

776
01:03:28,895 --> 01:03:33,500
Vamos garantir que o comentário não é igual a null.

777
01:03:33,630 --> 01:03:38,360
Caso contrário, então esta é a outra parte.

778
01:03:39,810 --> 01:03:44,170
Então, esta é a parte mais do if else erro

779
01:03:44,170 --> 01:03:48,040
novo comentário req.params.commentId não encontrado e, em seguida,

780
01:03:48,040 --> 01:03:56,220
404 e enviar a parte else para nós e, em seguida, a parte então irá lidar adequadamente.

781
01:03:56,220 --> 01:04:01,460
Então, essas são as alterações que fazemos para o roteador de comentários aqui.

782
01:04:01,460 --> 01:04:05,025
Então, estamos lidando com o get put post e excluir para

783
01:04:05,025 --> 01:04:10,330
os comentários de barra e pontos comentários barra barra impacto ComentID.

784
01:04:10,330 --> 01:04:12,495
Então, uma vez que

785
01:04:12,495 --> 01:04:17,500
tenhamos concluído isso, então precisamos incluir isso no arquivo app.js.

786
01:04:17,500 --> 01:04:27,345
Então, vamos para o arquivo app.js e, em seguida, vamos dizer

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

788
01:04:31,130 --> 01:04:42,280
exigem roteiras/CommentRouter.

789
01:04:42,280 --> 01:04:45,960
Então, temos o roteador comentário aqui e, em seguida, vamos

790
01:04:45,960 --> 01:04:49,390
descer para o arquivo app.js abaixo aqui e

791
01:04:49,390 --> 01:04:54,610
, em seguida, vamos dizer app.use

792
01:04:55,040 --> 01:05:04,695
barra comentários, CommentRouter aqui.

793
01:05:04,695 --> 01:05:07,365
É isso. Então agora,

794
01:05:07,365 --> 01:05:09,390
meu roteador de comentários está pronto.

795
01:05:09,390 --> 01:05:12,935
Então, vamos em frente e salvar todas as alterações.

796
01:05:12,935 --> 01:05:19,020
Em seguida, o nosso servidor é agora atualizado

797
01:05:19,020 --> 01:05:24,420
a fim de lidar com todos os pedidos de nossos clientes React aqui.

798
01:05:24,420 --> 01:05:27,800
Agora, se você quiser fazer a maneira alternativa, isto é,

799
01:05:27,800 --> 01:05:34,120
você tem seus comentários como sub-documentos do seu prato e, em seguida, você quer lidar com isso,

800
01:05:34,120 --> 01:05:37,680
então você vai precisar atualizar o cliente React

801
01:05:37,680 --> 01:05:42,185
para poder usar os comentários de dentro de cada prato adequadamente.

802
01:05:42,185 --> 01:05:44,830
Isso será deixado como um exercício para você.

803
01:05:44,830 --> 01:05:48,920
Pense em como você iria projetar seu cliente reagir de tal forma que ele

804
01:05:48,920 --> 01:05:53,465
funciona muito bem com a versão anterior

805
01:05:53,465 --> 01:06:03,735
do servidor que tinha os comentários como sub-documentos de seus próprios pratos.

806
01:06:03,735 --> 01:06:07,065
Agora, isso vai ser uma maneira interessante de implementá-lo.

807
01:06:07,065 --> 01:06:10,480
Claro, é um pouco mais complicado do que a forma como

808
01:06:10,480 --> 01:06:14,965
implementamos o cliente React onde mantemos os comentários independentes

809
01:06:14,965 --> 01:06:20,840
dos pratos, mas então o trabalho adicional é então da responsabilidade

810
01:06:20,840 --> 01:06:22,910
do lado do cliente, porque você precisa selecionar

811
01:06:22,910 --> 01:06:26,765
os comentários apropriados quando estiver mostrando um prato específico.

812
01:06:26,765 --> 01:06:30,370
Você precisa selecionar os comentários de todos os comentários aqui.

813
01:06:30,370 --> 01:06:35,170
Então, esse é um trabalho adicional que o nosso cliente React faz devido

814
01:06:35,170 --> 01:06:40,680
ao fato de que separamos os comentários dos próprios pratos.

815
01:06:40,680 --> 01:06:46,165
Da mesma forma, se você pode redesenhar seu cliente angular para ser capaz de

816
01:06:46,165 --> 01:06:51,775
lidar com a situação em que os comentários são mantidos independentemente de seus pratos.

817
01:06:51,775 --> 01:06:56,020
Agora, então estes são todos os exercícios que você pode fazer para ver como você pode

818
01:06:56,020 --> 01:07:01,210
estender seus aplicativos cliente para lidar com qualquer tipo de servidor,

819
01:07:01,210 --> 01:07:04,430
os dois tipos diferentes de servidores lá.

820
01:07:04,860 --> 01:07:11,480
Então, com isso, concluímos a atualização para o nosso servidor aqui.

821
01:07:11,480 --> 01:07:15,040
Então, com isso, atualizamos tudo no lado do servidor.

822
01:07:15,040 --> 01:07:17,890
Então, vamos salvar todas as alterações no lado do servidor.

823
01:07:17,890 --> 01:07:26,755
Então, agora, nosso servidor está pronto para lidar com as solicitações recebidas do nosso cliente React.

824
01:07:26,755 --> 01:07:29,340
Com isso, completamos este exercício.

825
01:07:29,340 --> 01:07:33,300
Neste exercício, preparamos nosso servidor expresso

826
01:07:33,300 --> 01:07:38,985
para lidar com solicitações recebidas de nosso cliente React.

827
01:07:38,985 --> 01:07:43,190
No próximo exercício, vamos olhar para reagir cliente com mais detalhes para

828
01:07:43,190 --> 01:07:48,000
entender como ele está se comunicando com este servidor extra.

829
01:07:48,000 --> 01:07:50,640
Este é um bom momento para você fazer

830
01:07:50,640 --> 01:07:55,880
uma cobertura git com a mensagem integrando cliente e servidor.