1
00:00:01,220 --> 00:00:03,730
‫-: Neste vídeo, vamos criar um

2
00:00:03,730 --> 00:00:06,333
‫tipo especial de middleware chamado param middleware.

3
00:00:07,920 --> 00:00:11,460
‫Portanto, o param middleware é um middleware que só

4
00:00:11,460 --> 00:00:13,940
‫roda para determinados parâmetros, basicamente,

5
00:00:13,940 --> 00:00:17,450
‫quando temos um determinado parâmetro em nossa URL.

6
00:00:17,450 --> 00:00:20,000
‫Agora, em nosso exemplo aqui, o

7
00:00:20,000 --> 00:00:25,000
‫único parâmetro que podemos ter em nosso URL de rota é o id, certo?

8
00:00:25,320 --> 00:00:28,120
‫E para que possamos escrever um

9
00:00:28,120 --> 00:00:31,100
‫middleware que só seja executado quando esse id

10
00:00:31,100 --> 00:00:34,570
‫estiver presente na URL, ok, deixe-me mostrar como fazer isso.

11
00:00:34,570 --> 00:00:38,000
‫Na verdade, é bem simples, então está

12
00:00:39,690 --> 00:00:43,260
‫no nosso roteador e depois no método param, ok.

13
00:00:43,260 --> 00:00:46,210
‫E aqui especificamos primeiro o parâmetro que realmente

14
00:00:46,210 --> 00:00:48,890
‫queremos pesquisar, basicamente o parâmetro para o

15
00:00:48,890 --> 00:00:50,900
‫qual esse middleware será

16
00:00:50,900 --> 00:00:54,400
‫executado e é chamado de id e, em seguida,

17
00:00:54,400 --> 00:00:57,333
‫é claro, nossa função de middleware real.

18
00:00:59,060 --> 00:01:02,800
‫E, como de costume, temos acesso à solicitação e

19
00:01:02,800 --> 00:01:05,070
‫ao objeto de resposta,

20
00:01:05,070 --> 00:01:07,350
‫e então percebemos uma função de

21
00:01:07,350 --> 00:01:10,300
‫middleware também para a próxima função, certo?

22
00:01:10,300 --> 00:01:12,090
‫Agora, em uma função

23
00:01:12,090 --> 00:01:15,370
‫de middleware param, temos acesso a um quarto argumento

24
00:01:15,370 --> 00:01:18,783
‫e esse é o valor do parâmetro em questão.

25
00:01:20,280 --> 00:01:23,553
‫Então, normalmente chamamos aquele val, que significa valor.

26
00:01:26,240 --> 00:01:28,720
‫E agora podemos ir em frente

27
00:01:28,720 --> 00:01:30,650
‫e simplesmente registrá-lo no

28
00:01:30,650 --> 00:01:35,510
‫console, apenas para ver se isso realmente funciona, digamos que o Tour

29
00:01:37,700 --> 00:01:40,410
‫id é e depois o id, certo?

30
00:01:40,410 --> 00:01:43,840
‫A seguir, também temos que ligar em seguida, certo?

31
00:01:43,840 --> 00:01:46,470
‫Porque, caso contrário, o ciclo de resposta

32
00:01:46,470 --> 00:01:48,970
‫de solicitação ficará preso nesta função

33
00:01:48,970 --> 00:01:51,630
‫de middleware e não será capaz de

34
00:01:51,630 --> 00:01:54,570
‫passar para o próximo middleware na pilha, certo?

35
00:01:54,570 --> 00:01:56,903
‫Quais serão essas rotas aqui embaixo.

36
00:01:57,860 --> 00:02:01,563
‫Tudo bem, então vamos salvá-lo e verificar agora.

37
00:02:03,000 --> 00:02:05,260
‫E não queremos

38
00:02:06,370 --> 00:02:10,100
‫todos os usuários, mas um tour, certo?

39
00:02:10,100 --> 00:02:11,940
‫Bem, deixe-me mostrar

40
00:02:11,940 --> 00:02:16,940
‫primeiro o que acontece se não tivermos nenhum id, ok, e

41
00:02:17,020 --> 00:02:20,310
‫agora, não vemos nenhum registro em nosso console.

42
00:02:20,310 --> 00:02:22,870
‫Mas se agora enviei a mesma solicitação

43
00:02:22,870 --> 00:02:26,843
‫nesta rota em que temos o id, vamos ver o que acontece então.

44
00:02:26,843 --> 00:02:29,610
‫Oh, isso me diz que id não está

45
00:02:29,610 --> 00:02:33,500
‫definido, e de fato não é id, então isso foi um erro estúpido.

46
00:02:33,500 --> 00:02:36,420
‫Então é val para valor, certo?

47
00:02:36,420 --> 00:02:39,710
‫Portanto, lembre-se de como eu disse que esse parâmetro

48
00:02:39,710 --> 00:02:41,500
‫de valor é o

49
00:02:41,500 --> 00:02:44,400
‫que realmente conterá o valor do parâmetro id

50
00:02:44,400 --> 00:02:46,930
‫e, claro, é o que precisamos usar

51
00:02:46,930 --> 00:02:49,303
‫aqui para obter acesso a esse id.

52
00:02:50,280 --> 00:02:53,580
‫Então, vamos tentar de novo, e agora

53
00:02:53,580 --> 00:02:56,990
‫realmente temos o ID do Tour dois, certo?

54
00:02:56,990 --> 00:03:00,120
‫Então esse log veio direto desta função aqui.

55
00:03:00,120 --> 00:03:01,893
‫Agora, o que também quero

56
00:03:01,893 --> 00:03:04,160
‫mostrar a vocês é que essa função de

57
00:03:04,160 --> 00:03:07,003
‫middleware não será executada para nenhuma das rotas do usuário.

58
00:03:08,963 --> 00:03:13,380
‫Digamos que chamemos um usuário com um id específico,

59
00:03:13,380 --> 00:03:15,593
‫então vamos copiar este aqui,

60
00:03:16,770 --> 00:03:20,680
‫criar uma nova requisição com um id e

61
00:03:20,680 --> 00:03:22,493
‫deixar-me salvá-lo também.

62
00:03:25,250 --> 00:03:30,240
‫Então pegue o usuário e salve para o usuário, e quando eu enviar aqui,

63
00:03:30,240 --> 00:03:32,340
‫claro, obteremos nossa resposta padrão

64
00:03:32,340 --> 00:03:35,200
‫desta rota não definida, mas você também verá

65
00:03:35,200 --> 00:03:38,210
‫que não temos nenhum log como tínhamos antes.

66
00:03:38,210 --> 00:03:41,800
‫E isso é claro porque essa função de middleware é

67
00:03:41,800 --> 00:03:44,940
‫especificada apenas em nosso roteador de tour.

68
00:03:44,940 --> 00:03:48,280
‫Nesse tipo de miniaplicativo local, novamente,

69
00:03:48,280 --> 00:03:51,750
‫essa é a analogia que gosto de fazer.

70
00:03:51,750 --> 00:03:53,960
‫Então, basicamente, cada roteador

71
00:03:53,960 --> 00:03:58,040
‫é uma espécie de mini subaplicativo, um para cada recurso.

72
00:03:58,040 --> 00:04:02,210
‫E, portanto, como esse middleware é especificado apenas neste

73
00:04:02,210 --> 00:04:04,300
‫roteador, bem, é claro,

74
00:04:04,300 --> 00:04:06,680
‫ele é apenas parte da

75
00:04:06,680 --> 00:04:10,670
‫pilha de middleware se estivermos realmente dentro deste subaplicativo.

76
00:04:10,670 --> 00:04:11,780
‫Faz sentido?

77
00:04:11,780 --> 00:04:16,460
‫Então, vamos supor que temos uma solicitação de entrada em tours / id.

78
00:04:16,460 --> 00:04:20,110
‫Essa solicitação passará por todos esses middleware, primeiro este

79
00:04:20,110 --> 00:04:22,900
‫middleware, depois este, então este middleware, então

80
00:04:22,900 --> 00:04:26,190
‫este, então todos eles fazem parte da pilha

81
00:04:26,190 --> 00:04:28,700
‫de middleware e então ele finalmente

82
00:04:28,700 --> 00:04:31,360
‫atingirá este middleware e já que

83
00:04:31,360 --> 00:04:33,660
‫este é na verdade,

84
00:04:33,660 --> 00:04:36,650
‫a rota, ele entrará no middleware tourRouter.

85
00:04:36,650 --> 00:04:40,830
‫Ok, então a partir daí ele vai direto para o

86
00:04:40,830 --> 00:04:43,823
‫middleware, e então este código será executado.

87
00:04:45,650 --> 00:04:48,830
‫E, novamente, isso é apenas porque tem um id na rota.

88
00:04:48,830 --> 00:04:51,970
‫Se não, bem, então isso seria simplesmente ignorado

89
00:04:51,970 --> 00:04:54,540
‫e passaria direto para o

90
00:04:54,540 --> 00:04:58,097
‫próximo middleware na pilha, então esses aqui embaixo, certo?

91
00:04:58,097 --> 00:05:01,770
‫Legal, então é assim que o param middleware funciona; mas

92
00:05:01,770 --> 00:05:04,296
‫por enquanto não é realmente útil.

93
00:05:04,296 --> 00:05:06,170
‫Mas podemos realmente usá-lo para

94
00:05:06,170 --> 00:05:08,430
‫um caso de uso muito prático aqui.

95
00:05:08,430 --> 00:05:11,670
‫Então, vamos para nossas funções de manipulador aqui e

96
00:05:11,670 --> 00:05:14,800
‫você verá que em todas as funções de

97
00:05:14,800 --> 00:05:19,023
‫manipulador que realmente usam o id, verificamos se o id é válido.

98
00:05:20,080 --> 00:05:24,560
‫Então, fazemos isso aqui em get tour e

99
00:05:24,560 --> 00:05:29,470
‫também fazemos em update tour, aqui, e em delete tour.

100
00:05:29,470 --> 00:05:32,250
‫Portanto, todas essas três funções têm esse código muito semelhante,

101
00:05:32,250 --> 00:05:34,370
‫onde verificam se o id é

102
00:05:34,370 --> 00:05:38,010
‫válido e, se não, enviam de volta essa resposta de ID inválido.

103
00:05:38,010 --> 00:05:40,360
‫Portanto, temos todo esse código no mesmo

104
00:05:40,360 --> 00:05:43,100
‫lugar e como você já sabe, não é uma

105
00:05:43,100 --> 00:05:46,020
‫boa prática repetir o código e, portanto, o que

106
00:05:46,020 --> 00:05:48,750
‫podemos fazer aqui é usar o conceito de

107
00:05:48,750 --> 00:05:51,680
‫middleware param; e execute essa verificação aqui em um middleware

108
00:05:51,680 --> 00:05:53,660
‫externo que será executado antes

109
00:05:53,660 --> 00:05:56,483
‫mesmo que a solicitação atinja essas funções do manipulador.

110
00:05:57,690 --> 00:06:01,010
‫Então, vamos copiar ou cortar o

111
00:06:01,010 --> 00:06:04,761
‫código a partir daqui e criar uma nova

112
00:06:04,761 --> 00:06:09,761
‫função de middleware chamada checkID e, claro, também preciso exportá-la.

113
00:06:14,010 --> 00:06:18,344
‫Portanto, checkID e temos acesso, solicitação, resposta, em seguida, e

114
00:06:18,344 --> 00:06:21,980
‫novamente, lembre-se de que é um middleware de

115
00:06:21,980 --> 00:06:25,150
‫parâmetro e, portanto, o quarto argumento será

116
00:06:25,150 --> 00:06:27,353
‫o valor do parâmetro.

117
00:06:29,040 --> 00:06:32,090
‫Ok, cole aqui e depois não

118
00:06:32,090 --> 00:06:36,570
‫se esqueça de chamar o próximo no final do middleware, certo?

119
00:06:36,570 --> 00:06:38,650
‫E o que também é muito

120
00:06:38,650 --> 00:06:41,402
‫importante é que temos essa instrução de retorno

121
00:06:41,402 --> 00:06:44,010
‫aqui, porque se não tivéssemos esse retorno

122
00:06:44,010 --> 00:06:47,360
‫aqui, bem, o express enviaria essa resposta de volta, mas

123
00:06:47,360 --> 00:06:48,930
‫ainda continuaria executando

124
00:06:48,930 --> 00:06:50,550
‫o código nesta função.

125
00:06:50,550 --> 00:06:52,510
‫E assim, depois de

126
00:06:52,510 --> 00:06:55,170
‫enviar a resposta, ele ainda atingirá a

127
00:06:55,170 --> 00:06:57,670
‫próxima função e passará para o

128
00:06:57,670 --> 00:07:00,560
‫próximo middleware e enviará outra resposta ao cliente.

129
00:07:00,560 --> 00:07:02,500
‫Mas isso realmente não é permitido,

130
00:07:02,500 --> 00:07:05,930
‫então lembre-se de que já nos deparamos com esse erro antes,

131
00:07:05,930 --> 00:07:08,150
‫que nos dizia que não tínhamos permissão

132
00:07:08,150 --> 00:07:11,520
‫para enviar cabeçalhos depois que a resposta já havia sido enviada.

133
00:07:11,520 --> 00:07:13,030
‫E esse é

134
00:07:13,030 --> 00:07:14,990
‫o tipo de erro que teríamos

135
00:07:14,990 --> 00:07:17,380
‫se não tivéssemos essa instrução return, certo.

136
00:07:17,380 --> 00:07:20,880
‫Portanto, novamente, apenas certifique-se de que, após enviar esta

137
00:07:20,880 --> 00:07:23,460
‫resposta, a função retornará para que

138
00:07:23,460 --> 00:07:26,350
‫ela seja concluída e nunca mais a chame.

139
00:07:26,350 --> 00:07:28,350
‫Portanto, nunca se esqueça disso, mas é

140
00:07:28,350 --> 00:07:30,010
‫claro que faremos isso

141
00:07:30,010 --> 00:07:31,720
‫várias vezes durante o resto do

142
00:07:31,720 --> 00:07:34,823
‫curso e você se acostumará com esse tipo de padrão.

143
00:07:36,096 --> 00:07:39,570
‫Então, vamos remover esse código repetido de todas essas

144
00:07:39,570 --> 00:07:41,230
‫outras funções, então

145
00:07:44,756 --> 00:07:47,197
‫aqui está de novo, e sim.

146
00:07:49,740 --> 00:07:52,352
‫Também quero esse código aqui apenas para

147
00:07:52,352 --> 00:07:54,903
‫ter certeza de que a

148
00:07:57,910 --> 00:08:02,510
‫função está realmente em execução, e tudo bem, agora podemos nos livrar

149
00:08:02,510 --> 00:08:06,640
‫disso aqui e substituí-lo por nossa função de controlador recém-criada.

150
00:08:06,640 --> 00:08:07,990
‫TourController, checkID,

151
00:08:11,550 --> 00:08:13,143
‫vamos verificar isso agora,

152
00:08:15,180 --> 00:08:18,370
‫e bem de novo, apenas para ter certeza

153
00:08:18,370 --> 00:08:19,860
‫de que não

154
00:08:19,860 --> 00:08:24,350
‫é executado onde não temos um id, portanto, não temos log

155
00:08:24,350 --> 00:08:27,810
‫aqui, então tudo ainda está funcionando nesse lado.

156
00:08:27,810 --> 00:08:30,670
‫E agora faça o tour com uma id

157
00:08:30,670 --> 00:08:33,883
‫regular, então uma id válida, e então vamos ver.

158
00:08:34,750 --> 00:08:38,040
‫Bem, obtemos que o Tour id é log,

159
00:08:38,040 --> 00:08:40,346
‫e isso significa que se

160
00:08:40,346 --> 00:08:43,563
‫ele realmente executou nosso middleware checkID, certo?

161
00:08:44,560 --> 00:08:46,986
‫E se agora tentarmos um

162
00:08:46,986 --> 00:08:50,090
‫id inválido, obteremos nossa mensagem de ID

163
00:08:50,090 --> 00:08:54,803
‫inválido, o código de erro 404 e, claro, nosso id de tour.

164
00:08:56,200 --> 00:08:58,930
‫Vamos fazer o mesmo com o

165
00:08:58,930 --> 00:09:01,240
‫patch, já temos um

166
00:09:01,240 --> 00:09:04,740
‫ID inválido aqui e ele também roda neste.

167
00:09:04,740 --> 00:09:08,420
‫Então, perfeito, certo?

168
00:09:08,420 --> 00:09:11,865
‫Portanto, não temos mais o código checkID no

169
00:09:11,865 --> 00:09:15,910
‫manipulador de atualização que acabamos de invocar basicamente, mas ainda

170
00:09:15,910 --> 00:09:18,240
‫assim nosso ID é verificado

171
00:09:18,240 --> 00:09:21,470
‫porque temos esse middleware, então isso aqui.

172
00:09:21,470 --> 00:09:23,630
‫Temos esse middleware na pilha

173
00:09:23,630 --> 00:09:26,750
‫antes de realmente atingir o tourController de atualização.

174
00:09:26,750 --> 00:09:30,200
‫Portanto, este middleware agora faz parte do nosso pipeline

175
00:09:30,200 --> 00:09:32,770
‫como você pode imaginar, agora você pode

176
00:09:32,770 --> 00:09:35,340
‫argumentar que podemos simplesmente criar uma

177
00:09:35,340 --> 00:09:37,530
‫função simples que também pode

178
00:09:37,530 --> 00:09:40,220
‫verificar o ID e eu chamo essa

179
00:09:40,220 --> 00:09:43,910
‫função dentro de cada uma dessas funções de passeio e,

180
00:09:43,910 --> 00:09:47,830
‫em seguida, chamo dentro de cada um desses controladores de turismo

181
00:09:47,830 --> 00:09:49,410
‫relevantes; mas isso

182
00:09:49,410 --> 00:09:52,860
‫realmente iria contra a filosofia do express, onde devemos

183
00:09:52,860 --> 00:09:55,730
‫sempre trabalhar com a pilha de middleware, portanto,

184
00:09:55,730 --> 00:10:00,010
‫com esse pipeline o máximo que pudermos, ok, e essas funções aqui,

185
00:10:00,010 --> 00:10:02,850
‫eles não precisam se preocupar com a validação.

186
00:10:02,850 --> 00:10:05,580
‫Cada uma dessas funções tem apenas um propósito que

187
00:10:05,580 --> 00:10:07,540
‫é fazer o que dizem,

188
00:10:07,540 --> 00:10:09,200
‫então esta apenas obtém

189
00:10:09,200 --> 00:10:12,170
‫o passeio, esta apenas cria um passeio, esta apenas

190
00:10:12,170 --> 00:10:14,650
‫atualiza e esta apenas exclui, não verifica, não

191
00:10:14,650 --> 00:10:17,003
‫não precisa se preocupar com nada disso.

192
00:10:18,910 --> 00:10:21,060
‫E se agora adicionarmos

193
00:10:21,060 --> 00:10:24,630
‫outro controlador aqui também dependendo do id, então isso

194
00:10:24,630 --> 00:10:27,380
‫também verificará automaticamente se o id é

195
00:10:27,380 --> 00:10:30,960
‫inválido sem que tenhamos que fazer quaisquer etapas adicionais.

196
00:10:30,960 --> 00:10:34,620
‫Isso irá verificar automaticamente o id e

197
00:10:34,620 --> 00:10:38,670
‫isso é realmente útil e também como os

198
00:10:38,670 --> 00:10:41,450
‫aplicativos expressos devem funcionar, ótimo.

199
00:10:41,450 --> 00:10:45,810
‫Portanto, temos outra ferramenta em nossa caixa de ferramentas expresso que

200
00:10:45,810 --> 00:10:49,493
‫agora podemos usar para escrever nossos aplicativos expresso.