1
00:00:03,650 --> 00:00:08,385
Chúng tôi đã phát triển một máy chủ REST API đầy đủ

2
00:00:08,385 --> 00:00:12,485
sử dụng Express và MongoDB như một phần của khóa học này.

3
00:00:12,485 --> 00:00:16,965
Để máy chủ đó có thể giao tiếp một cách có ý nghĩa với khách hàng của chúng

4
00:00:16,965 --> 00:00:19,590
tôi, chúng tôi sẽ thực hiện một vài điều chỉnh nhỏ

5
00:00:19,590 --> 00:00:22,440
để nó trả về đúng loại dữ liệu để

6
00:00:22,440 --> 00:00:24,780
thực hiện khách hàng của chúng tôi có thể hoạt động

7
00:00:24,780 --> 00:00:28,935
hiệu quả hơn với dữ liệu được trả về từ trang web máy chủ của chúng tôi.

8
00:00:28,935 --> 00:00:30,410
Vì vậy, để làm điều đó, chúng

9
00:00:30,410 --> 00:00:36,580
ta hãy làm việc trên một vài điều chỉnh cho trang web máy chủ của chúng tôi trong bài tập này.

10
00:00:36,580 --> 00:00:39,215
Trước khi bạn bắt đầu bài tập này,

11
00:00:39,215 --> 00:00:42,410
tôi giả sử rằng bạn chưa thực hiện

12
00:00:42,410 --> 00:00:46,430
bài học trước đó về tích hợp khách hàng góc cạnh và

13
00:00:46,430 --> 00:00:55,395
máy chủ bởi vì bạn đang làm bài học này đi qua chuyên môn React.

14
00:00:55,395 --> 00:01:01,190
Vì vậy, những thay đổi mà tôi sẽ thực hiện cho máy chủ sẽ giả

15
00:01:01,190 --> 00:01:07,430
định rằng phiên bản của máy chủ mà bạn đang sửa đổi là trước bài học trước đó.

16
00:01:07,430 --> 00:01:11,540
Trong trường hợp bạn đã thực hiện bài học đó trên máy khách góc cạnh,

17
00:01:11,540 --> 00:01:16,505
một số thay đổi mà bạn đã thực hiện cho máy chủ của bạn sẽ được lặp lại một lần nữa

18
00:01:16,505 --> 00:01:22,495
trong bài tập này để bạn có thể bỏ qua phần thay đổi đó.

19
00:01:22,495 --> 00:01:26,055
Đi vào máy chủ của chúng tôi trong trình soạn thảo.

20
00:01:26,055 --> 00:01:29,125
Trước khi chúng tôi bắt đầu làm việc trên máy chủ,

21
00:01:29,125 --> 00:01:33,530
tôi sẽ đề nghị bạn tải xuống tất cả các hình ảnh mà tôi đã

22
00:01:33,530 --> 00:01:38,380
cung cấp như một tập tin zip trong các tài nguyên tập thể dục được gọi là images.zip.

23
00:01:38,380 --> 00:01:43,160
Giải nén tập tin và sau đó có được tất cả các hình ảnh từ đó và sau đó sao chép những hình ảnh đó

24
00:01:43,160 --> 00:01:48,290
vào thư mục hình ảnh công cộng trong máy chủ của chúng tôi.

25
00:01:48,290 --> 00:01:55,010
Vì vậy, bạn thấy rằng ở đây tôi đã sao chép tất cả các hình ảnh vào thư mục hình ảnh công cộng của tôi ở đây

26
00:01:55,010 --> 00:01:58,160
đã bởi vì máy chủ của chúng tôi là một trong đó sẽ

27
00:01:58,160 --> 00:02:02,275
phục vụ tất cả các hình ảnh cho ứng dụng khách hàng của chúng tôi.

28
00:02:02,275 --> 00:02:07,835
Tiếp theo, chúng tôi đi đến CORS và điều chỉnh danh sách trắng ở đây.

29
00:02:07,835 --> 00:02:11,565
Vì vậy, đối với ứng dụng khách hàng React của

30
00:02:11,565 --> 00:02:15,275
chúng tôi, nếu chúng tôi bắt đầu với lệnh start sợi,

31
00:02:15,275 --> 00:02:18,470
nó chạy ở tên máy tính của bạn: 3001.

32
00:02:18,470 --> 00:02:22,040
Vì vậy, bất kỳ yêu cầu nào đến từ vị trí của chúng tôi đến

33
00:02:22,040 --> 00:02:25,760
máy chủ sẽ mang nó như là nguồn gốc ở đó.

34
00:02:25,760 --> 00:02:30,380
Vì vậy, đó là lý do tại sao tôi sẽ thêm vào danh sách trắng của tôi để

35
00:02:30,380 --> 00:02:35,390
bất kỳ vấn đề CORS sẽ được giải quyết tự động.

36
00:02:35,390 --> 00:02:40,985
Vì vậy, đi vào tập tin cors.js trong danh sách trắng của tôi ở đây,

37
00:02:40,985 --> 00:02:49,460
hãy để tôi thêm vào

38
00:02:49,460 --> 00:02:55,640
tên máy tính http://my: 3001 và đây là

39
00:02:55,640 --> 00:02:58,610
nguồn gốc mà từ đó khách hàng của tôi

40
00:02:58,610 --> 00:03:02,075
sẽ có nguồn gốc các yêu cầu đến máy chủ này.

41
00:03:02,075 --> 00:03:07,075
Vì vậy, theo cách đó CORS của tôi sẽ không gây ra vấn đề cho khách hàng của tôi.

42
00:03:07,075 --> 00:03:11,690
Tiếp theo, chúng ta cần cập nhật một vài tuyến đường để

43
00:03:11,690 --> 00:03:17,690
xử lý các tham số truy vấn và cũng là một vài điều chỉnh nhỏ khác.

44
00:03:17,690 --> 00:03:21,280
Hãy để tôi bắt đầu với các tập tin promoRouter.js.

45
00:03:21,280 --> 00:03:25,010
Điều đó rất đơn giản để có được cập nhật.

46
00:03:25,010 --> 00:03:27,570
Vì vậy, đi vào tập tin promoRouter.js,

47
00:03:27,570 --> 00:03:32,360
trong tập tin Promorouter cho yêu cầu get mà chúng tôi nhận được

48
00:03:32,360 --> 00:03:37,610
ở đây thay vì làm chương trình khuyến mãi tìm thấy với một đối tượng JavaScript trống,

49
00:03:37,610 --> 00:03:47,320
ở đây tôi sẽ cung cấp req.query như tham số cho chương trình khuyến mãi tìm thấy ở đây,

50
00:03:47,320 --> 00:03:49,680
điều tương tự với router lãnh đạo cũng.

51
00:03:49,680 --> 00:03:52,745
Vì vậy, hãy để tôi đi đến tập tin leaderRouter.js.

52
00:03:52,745 --> 00:03:54,815
Trong bộ định tuyến lãnh đạo cũng,

53
00:03:54,815 --> 00:04:00,545
ở đây nơi bạn tìm thấy Leaders.Find với đối tượng JavaScript trống

54
00:04:00,545 --> 00:04:06,685
thay vì thay thế với req.query để các tham số truy vấn sẽ được thông qua.

55
00:04:06,685 --> 00:04:14,260
Vì vậy, đây là nơi chúng tôi sẽ vượt qua trong các tính năng:true như tham số truy vấn ở đây.

56
00:04:14,260 --> 00:04:16,945
Bây giờ, sau khi điều chỉnh hai,

57
00:04:16,945 --> 00:04:19,340
bây giờ chúng ta hãy làm việc trên bộ định tuyến đĩa.

58
00:04:19,340 --> 00:04:22,115
Vì vậy, đi vào tập tin dishRouter.js,

59
00:04:22,115 --> 00:04:26,310
ngay cả trong bộ định tuyến đĩa cũng cập nhật tương tự ở đây.

60
00:04:26,310 --> 00:04:31,200
Vì vậy, đi vào món ăn này.Find trong phương pháp get ở đây,

61
00:04:31,200 --> 00:04:33,945
thay đổi đó để req.query.

62
00:04:33,945 --> 00:04:38,070
Vì vậy, với điều này, bản cập nhật bộ định tuyến món ăn của tôi đã được hoàn thành.

63
00:04:38,070 --> 00:04:42,085
Vì vậy, bây giờ chúng tôi đã cập nhật bộ định tuyến quảng cáo, nhà lãnh đạo

64
00:04:42,085 --> 00:04:43,850
và bộ định tuyến món ăn,

65
00:04:43,850 --> 00:04:48,050
sau đó chúng tôi sẽ tiếp tục cập nhật bộ định tuyến yêu thích.

66
00:04:48,050 --> 00:04:54,380
Bây giờ, bạn đã thực hiện bộ định tuyến yêu thích như là một phần của nhiệm vụ thứ tư của bạn.

67
00:04:54,380 --> 00:04:56,530
Bây giờ, trong bộ định tuyến yêu thích,

68
00:04:56,530 --> 00:04:58,910
bạn sẽ thấy rằng đối với bộ định tuyến yêu thích,

69
00:04:58,910 --> 00:05:01,010
tôi không cho bạn thấy phần còn lại bởi vì

70
00:05:01,010 --> 00:05:03,435
bạn nên làm như một phần của nhiệm vụ của bạn.

71
00:05:03,435 --> 00:05:11,520
Trước tiên, hãy để tôi thu hút sự chú ý của bạn đến phương pháp get cho Favoriterouter.Route:dishid.

72
00:05:11,520 --> 00:05:17,405
Bây giờ tôi sẽ sử dụng phương pháp get này để chỉ kiểm tra để đảm bảo rằng

73
00:05:17,405 --> 00:05:25,460
các món ăn cụ thể với các món ăn Id đã là một yêu thích cho người dùng.

74
00:05:25,460 --> 00:05:29,130
Vì vậy, thay vì chỉ đơn giản là nói getoperation.supported,

75
00:05:29,130 --> 00:05:36,165
Tôi chỉ sẽ tận dụng sự hiện diện của hoạt động này get và sau đó chúng ta sẽ nói,

76
00:05:36,165 --> 00:05:47,500
favorites.findone và chúng ta sẽ nói người dùng: req.user.

77
00:05:49,220 --> 00:05:59,340
Vì vậy, chúng tôi sẽ tìm thấy mục yêu thích cho người dùng cụ thể đó và sau đó chúng tôi sẽ nói sau đó

78
00:06:03,070 --> 00:06:25,530
yêu thích và bắt lỗi tiếp theo.

79
00:06:25,530 --> 00:06:35,265
Sau đó, tương tự ở đây, chúng tôi sẽ thêm trong err ở đây, err tiếp theo ở đây.

80
00:06:35,265 --> 00:06:37,380
Vì vậy, bên trong điều này sau đó,

81
00:06:37,380 --> 00:06:39,495
khi chúng tôi nhận được yêu thích,

82
00:06:39,495 --> 00:06:45,360
sau đó chúng tôi sẽ kiểm tra nếu không yêu thích.

83
00:06:45,360 --> 00:06:47,690
Vì vậy, nếu không có mục yêu thích cho

84
00:06:47,690 --> 00:06:53,900
người dùng này thì rõ ràng là món ăn mà chúng tôi đang kiểm tra không tồn tại,

85
00:06:53,900 --> 00:07:07,520
vì vậy chúng tôi sẽ trả lại res.StatusCode 200,

86
00:07:07,520 --> 00:07:14,370
Setheader, Content-Type,

87
00:07:17,230 --> 00:07:36,735
ứng dụng/json và sau đó chúng tôi sẽ trở lại nói tồn tại sai.

88
00:07:36,735 --> 00:07:44,215
Những gì chúng tôi đang xác định ở đây là nếu họ nhận được được thực hiện để điểm kết thúc này với một Id món ăn,

89
00:07:44,215 --> 00:07:52,835
điều này tồn tại cờ ở đây sẽ được thiết lập để đúng nếu món ăn này là một phần của mục yêu thích của tôi.

90
00:07:52,835 --> 00:07:55,290
Nếu món ăn này không phải là một phần của mục yêu thích của

91
00:07:55,290 --> 00:07:58,100
tôi, Tôi sẽ thiết lập có tồn tại cờ để sai.

92
00:07:58,100 --> 00:08:01,190
Vì vậy, ở đây, bạn thấy rằng kể từ khi tôi không có bất kỳ yêu thích vì vậy

93
00:08:01,190 --> 00:08:04,770
tồn tại nên được tự động sai tại thời điểm này.

94
00:08:04,770 --> 00:08:13,020
Vì vậy, chúng tôi sẽ nói tồn tại sai và sau đó chúng tôi sẽ trả lại các mục yêu thích ở đây.

95
00:08:13,180 --> 00:08:19,090
Vâng, rõ ràng, trong trường hợp này các mục yêu thích sẽ là null tại thời điểm này.

96
00:08:19,090 --> 00:08:26,440
Nếu không, do đó, có nghĩa là yêu thích không phải là null,

97
00:08:26,440 --> 00:08:32,750
vì vậy chúng tôi sẽ nói nếu favorites.dishes.indexof.

98
00:08:36,840 --> 00:08:45,995
Vì vậy, chúng ta sẽ tìm kiếm Req.params.Dishid.

99
00:08:45,995 --> 00:08:51,220
Vì vậy, chúng ta sẽ tìm kiếm món ăn yêu thích này mảng để

100
00:08:51,220 --> 00:08:56,605
xem nếu món ăn này tồn tại trong đó và nếu nó không tồn tại,

101
00:08:56,605 --> 00:09:00,525
rõ ràng điều này sẽ trả lại một chỉ số tiêu cực ở đây.

102
00:09:00,525 --> 00:09:02,340
Trong trường hợp đó cũng,

103
00:09:02,340 --> 00:09:05,440
tôi sẽ trả lại chính xác giống như ở đây.

104
00:09:05,440 --> 00:09:08,630
Vì vậy, nếu nó trả về một chỉ số tiêu cực thì điều đó có nghĩa là

105
00:09:08,630 --> 00:09:12,260
mặc dù người dùng cụ thể này có một tập hợp các mục yêu thích,

106
00:09:12,260 --> 00:09:16,190
món ăn cụ thể này không tồn tại trong

107
00:09:16,190 --> 00:09:22,340
danh sách các mục yêu thích của mình vì vậy đó là lý do tại sao nó sẽ trở lại tồn tại sai ở đây.

108
00:09:22,340 --> 00:09:30,255
Bây giờ, nếu không điều đó có nghĩa là món ăn tồn tại trong danh sách yêu thích.

109
00:09:30,255 --> 00:09:31,859
Vì vậy, trong trường hợp này,

110
00:09:31,859 --> 00:09:36,670
tôi sẽ trả lại mã trạng thái 200 tồn tại là đúng.

111
00:09:36,670 --> 00:09:43,825
Vì vậy, theo cách đó, khi người dùng thực hiện một hoạt động get trên điểm cuối này với

112
00:09:43,825 --> 00:09:52,015
/Favorites/dishid nơi món ăn Id được cung cấp như là tham số ở đây,

113
00:09:52,015 --> 00:09:55,630
như tham số yêu cầu ở đây,

114
00:09:55,630 --> 00:10:00,650
sau đó chúng tôi sẽ kiểm tra xem liệu món ăn đó tồn tại trong mục yêu thích.

115
00:10:00,650 --> 00:10:05,775
Nếu không ai trong số các mục yêu thích tồn tại cho người dùng này sau đó chúng tôi sẽ trả về một tồn tại sai.

116
00:10:05,775 --> 00:10:08,120
Tương tự, nếu các mục yêu thích tồn tại nhưng

117
00:10:08,120 --> 00:10:12,320
món ăn đặc biệt đó không tồn tại trong mục yêu thích thì chúng tôi sẽ trả lại false,

118
00:10:12,320 --> 00:10:13,910
nếu không chúng tôi sẽ trả lại true.

119
00:10:13,910 --> 00:10:20,260
Vì vậy, điều này tồn tại cờ có thể được sử dụng bởi khách hàng của tôi để kiểm tra xem món ăn này là

120
00:10:20,260 --> 00:10:27,755
một phần của danh sách các món ăn yêu thích cho người dùng này hay không.

121
00:10:27,755 --> 00:10:30,139
Ngoài ra trong khi chúng tôi đang ở trong mục yêu thích,

122
00:10:30,139 --> 00:10:33,410
bất cứ khi nào chúng tôi thực hiện bất kỳ thay đổi cho mục yêu thích,

123
00:10:33,410 --> 00:10:37,870
chúng tôi muốn có thể cư trú thông tin người dùng và món ăn,

124
00:10:37,870 --> 00:10:39,535
mục yêu thích, trước khi chúng tôi trở lại.

125
00:10:39,535 --> 00:10:43,240
Ví dụ, trong bài viết mà chúng tôi làm,

126
00:10:43,240 --> 00:10:48,470
khi chúng tôi lưu các mục yêu thích sau đó tại thời điểm này,

127
00:10:48,470 --> 00:10:55,470
chúng tôi muốn đầu tiên làm mục yêu thích.

128
00:10:55,620 --> 00:11:06,380
FindByID, vì vậy bởi vì chúng tôi chỉ thực hiện những thay đổi chúng tôi sẽ nói favorite_id

129
00:11:07,740 --> 00:11:15,325
và chúng tôi sẽ cư trú cả người dùng và cũng

130
00:11:15,325 --> 00:11:25,490
cư trú các món ăn trong mục yêu thích.

131
00:11:25,740 --> 00:11:32,420
Sau đó, khi các mục yêu thích được trả lại,

132
00:11:32,610 --> 00:11:36,940
chúng tôi sẽ trả lại mục yêu thích đó thay vào đó.

133
00:11:36,940 --> 00:11:40,440
Vì vậy, để tôi thực hiện thay đổi này ở đây.

134
00:11:40,440 --> 00:11:46,910
Vì vậy, chúng tôi sẽ cắt ra từ đây và sau đó bên trong sau đó,

135
00:11:46,910 --> 00:11:49,645
chúng tôi sẽ trả lại các mục yêu thích.

136
00:11:49,645 --> 00:11:53,510
Sau khi chúng tôi lưu các mục yêu thích,

137
00:11:53,510 --> 00:11:54,980
sau đó chúng tôi sẽ tìm kiếm nó,

138
00:11:54,980 --> 00:11:58,285
cho FavoriteByID và sau

139
00:11:58,285 --> 00:12:03,940
đó trả lại yêu thích ở đây để chúng tôi sẽ nói sau đó yêu thích trở lại và mã trạng thái.

140
00:12:03,940 --> 00:12:05,355
Thay đổi này chúng ta nên thực hiện.

141
00:12:05,355 --> 00:12:08,180
Nếu bạn đã thực hiện điều này trong mục yêu thích của mình,

142
00:12:08,180 --> 00:12:09,760
thì bạn không cần phải thực hiện thay đổi này.

143
00:12:09,760 --> 00:12:13,310
Nhưng những gì chúng tôi đang làm là bất cứ khi nào chúng tôi thực hiện thay đổi cho mục yêu thích,

144
00:12:13,310 --> 00:12:17,380
chúng tôi sẽ điền cả thông tin người dùng và món ăn và sau đó trả lại giá trị này

145
00:12:17,380 --> 00:12:22,360
vì khách hàng React của chúng tôi mong đợi điều này sẽ có mặt ở đó.

146
00:12:22,360 --> 00:12:24,685
Bây giờ, cùng một loại thay đổi,

147
00:12:24,685 --> 00:12:28,350
chúng ta sẽ cần phải làm cho biến b, lưu các thay đổi.

148
00:12:28,350 --> 00:12:33,125
Vì vậy, trong bài viết ở đây,

149
00:12:33,125 --> 00:12:36,090
chúng tôi sẽ thực hiện một thay đổi để điều đó,

150
00:12:36,090 --> 00:12:42,705
vì vậy chúng tôi sẽ nói favorites.save và sau đó chúng tôi sẽ làm favorites.findbyID và thực hiện thay đổi đó.

151
00:12:42,705 --> 00:12:45,210
Tương tự như vậy, dưới id món ăn,

152
00:12:45,210 --> 00:12:47,095
cũng trong bài đăng,

153
00:12:47,095 --> 00:12:51,070
bạn sẽ tương tự, bất cứ khi nào bạn thực hiện thay đổi yêu thích,

154
00:12:51,070 --> 00:12:57,715
đầu tiên sẽ tìm kiếm nó và sau đó cư trú cả người dùng và các món ăn và sau đó trả lại nó,

155
00:12:57,715 --> 00:12:59,910
và sau đó tương tự trong phần khác.

156
00:12:59,910 --> 00:13:06,290
Vì vậy, bạn chắc đã thực hiện điều này trong nhiệm vụ thứ tư của bạn.

157
00:13:06,290 --> 00:13:09,010
Vì vậy, thực hiện thay đổi bổ sung này nơi bạn sẽ cư trú

158
00:13:09,010 --> 00:13:12,350
người dùng và các món ăn trước khi bạn trả về giá trị.

159
00:13:12,350 --> 00:13:14,685
Ngoài ra với việc xóa,

160
00:13:14,685 --> 00:13:17,385
chúng tôi sẽ thực hiện các thay đổi tương tự ở đây.

161
00:13:17,385 --> 00:13:19,890
Vì vậy, bạn nhận thấy rằng trong xóa,

162
00:13:19,890 --> 00:13:21,830
tôi đã thực hiện thay đổi này ở đây.

163
00:13:21,830 --> 00:13:27,085
Vì vậy, sau khi chúng tôi lưu các thay đổi vào mục yêu thích,

164
00:13:27,085 --> 00:13:29,480
sau đó chúng tôi sẽ tìm kiếm các mục yêu thích và sau đó

165
00:13:29,480 --> 00:13:33,465
trở lại sau khi điền vào cả người dùng và các món ăn và mục yêu thích.

166
00:13:33,465 --> 00:13:36,505
Đây là những gì khách hàng React của chúng tôi mong đợi chúng tôi làm.

167
00:13:36,505 --> 00:13:38,145
Vì vậy, ngay cả đối với việc xóa,

168
00:13:38,145 --> 00:13:39,995
chúng tôi sẽ thực hiện các thay đổi tương tự.

169
00:13:39,995 --> 00:13:44,115
Bây giờ, với điều này, bộ định tuyến yêu thích của tôi được cập nhật

170
00:13:44,115 --> 00:13:48,575
vì vậy chúng tôi sẽ tiến hành cập nhật users.js tiếp theo.

171
00:13:48,575 --> 00:13:52,370
Cuối cùng, chúng tôi sẽ cập nhật tệp users.js.

172
00:13:52,370 --> 00:13:57,060
Bây giờ, trong tập tin users.js chúng ta cần phải thêm vào một

173
00:13:57,060 --> 00:14:05,245
lĩnh vực router.options khác ở đây,

174
00:14:05,245 --> 00:14:10,610
bởi vì đôi khi một yêu cầu bài đăng như bạn đã thấy

175
00:14:10,610 --> 00:14:16,315
với đăng nhập sẽ gửi các tùy chọn đầu tiên để kiểm tra,

176
00:14:16,315 --> 00:14:21,610
đặc biệt là với xe ô tô, cho dù yêu cầu bài đăng sẽ được cho phép.

177
00:14:21,610 --> 00:14:30,080
Vì vậy, đó là lý do tại sao chúng tôi sẽ kiểm tra khóa học với các tùy chọn ở đây và sau đó

178
00:14:31,860 --> 00:14:35,450
chúng tôi sẽ chỉ đơn giản

179
00:14:39,960 --> 00:14:43,045
là trả về một thông báo trạng thái

180
00:14:43,045 --> 00:14:46,180
của 200 để đáp ứng với điều đó.

181
00:14:46,180 --> 00:14:52,960
Đối với bất kỳ điểm cuối dưới người dùng nếu chúng tôi nhận được các tùy chọn,

182
00:14:52,960 --> 00:14:56,530
chúng tôi sẽ chỉ đơn giản trả lại trạng thái 200 ở đây.

183
00:14:56,530 --> 00:15:03,580
Bây giờ chức năng đăng nhập mà chúng tôi đã thực hiện trước đó,

184
00:15:03,580 --> 00:15:07,470
chúng tôi đã chỉ đơn giản là thực hiện passport.authenticate

185
00:15:07,470 --> 00:15:12,930
địa phương ở đây và chúng tôi đã kiểm tra cho các giá trị còn lại ở đây.

186
00:15:12,930 --> 00:15:15,215
Bây giờ, passport.authenticate địa phương này,

187
00:15:15,215 --> 00:15:17,600
nếu người dùng không nhận được chứng thực,

188
00:15:17,600 --> 00:15:21,800
nó chỉ đơn giản là trả về một trái phép trong thư trả lời.

189
00:15:21,800 --> 00:15:28,380
Bây giờ điều đó có thể không phải là rất có ý nghĩa cho phía khách hàng để hiển thị thông tin này,

190
00:15:28,380 --> 00:15:30,480
vì vậy đó là lý do tại sao chúng tôi sẽ tăng cường

191
00:15:30,480 --> 00:15:36,310
phương pháp đăng nhập bài bộ định tuyến này để

192
00:15:36,310 --> 00:15:41,765
xác thực sẽ trả lại thông tin có ý nghĩa hơn tại thời điểm này.

193
00:15:41,765 --> 00:15:43,210
Vì vậy, để làm điều đó,

194
00:15:43,210 --> 00:15:49,395
chúng tôi sẽ không được làm passport.authenticate ở đây,

195
00:15:49,395 --> 00:15:51,955
thay vào đó chúng tôi sẽ mất.

196
00:15:51,955 --> 00:15:55,140
Vì vậy, hãy để tôi loại bỏ điều đó từ đó và sau đó bạn sẽ thấy

197
00:15:55,140 --> 00:15:58,930
làm thế nào tôi sẽ cập nhật bài đăng bộ định tuyến ở đây.

198
00:15:58,930 --> 00:16:08,620
Vì vậy, chúng ta sẽ thấy khóa học với các tùy chọn và sau đó chúng tôi sẽ bao gồm req,

199
00:16:08,620 --> 00:16:12,160
res và tiếp theo ở đây.

200
00:16:12,160 --> 00:16:16,885
Bên trong req này, res và tiếp theo ở đây,

201
00:16:16,885 --> 00:16:27,954
passport.authenticate sẽ gọi này với địa phương.

202
00:16:27,954 --> 00:16:31,210
Bây giờ, khi chúng ta gọi điều này với địa phương,

203
00:16:31,210 --> 00:16:34,970
nếu lỗi xác thực xảy ra,

204
00:16:34,970 --> 00:16:38,240
passport.authenticate có thể được thực hiện để trả về

205
00:16:38,240 --> 00:16:44,230
giá trị lỗi và nó cũng sẽ trả về người dùng nếu

206
00:16:44,230 --> 00:16:48,960
không có lỗi và một tham số thứ ba được gọi là thông tin

207
00:16:48,960 --> 00:16:54,000
đó sẽ mang thông tin bổ sung có thể được phân tích trở lại người dùng.

208
00:16:54,000 --> 00:16:56,580
Lỗi này sẽ được trả lại khi

209
00:16:56,580 --> 00:16:59,950
có lỗi chính hãng xảy ra trong passport.authenticate.

210
00:16:59,950 --> 00:17:03,400
Nhưng nếu thông tin người dùng

211
00:17:03,400 --> 00:17:07,645
được gửi vào passport.authenticate nhưng người dùng không tồn tại,

212
00:17:07,645 --> 00:17:10,490
thì thông tin đó không được tính là lỗi.

213
00:17:10,490 --> 00:17:14,690
Thay vào đó, nó sẽ được tính là người dùng không tồn tại và

214
00:17:14,690 --> 00:17:19,305
thông tin đó được phân tích lại trong đối tượng thông tin đi kèm.

215
00:17:19,305 --> 00:17:21,500
Vì vậy, lỗi sẽ được trả lại khi có

216
00:17:21,500 --> 00:17:24,925
một lỗi chính hãng xảy ra trong quá trình xác thực,

217
00:17:24,925 --> 00:17:30,820
nhưng thông tin sẽ chứa thông tin nếu người dùng không tồn tại.

218
00:17:30,820 --> 00:17:36,920
Vì vậy, passport.authenticate đang truyền lại một thông báo nói rằng

219
00:17:36,920 --> 00:17:39,575
người dùng không tồn tại hoặc tên người dùng

220
00:17:39,575 --> 00:17:42,850
là không chính xác hoặc mật khẩu là không chính xác và như vậy.

221
00:17:42,850 --> 00:17:46,870
Vì vậy, thông tin đó sẽ được thông qua trong thông báo thông tin.

222
00:17:46,870 --> 00:17:49,230
Bây giờ chúng ta sẽ thấy làm thế nào điều này là hữu ích cho

223
00:17:49,230 --> 00:17:52,060
chúng tôi khi chúng ta nhìn vào phía khách hàng một chút sau đó.

224
00:17:52,060 --> 00:17:55,400
Vì vậy, trong tình huống này,

225
00:17:55,400 --> 00:18:01,455
chúng tôi sẽ xử lý điều này như sau,

226
00:18:01,455 --> 00:18:06,810
và không chỉ rằng khi chúng tôi gọi passport.authenticate này,

227
00:18:06,810 --> 00:18:10,220
chúng tôi cũng cần phải vượt qua trong một req,

228
00:18:10,220 --> 00:18:15,080
res, tiếp theo là ba tham số cho nó.

229
00:18:15,080 --> 00:18:20,130
Vì vậy, đây là cấu trúc khi bạn cần phải gọi passport.authenticate và mong đợi nó để

230
00:18:20,130 --> 00:18:25,270
vượt qua bạn thông tin trở lại như thế này như một phương pháp gọi lại ở đây,

231
00:18:25,270 --> 00:18:27,630
vì vậy bạn cũng cần phải cung cấp req này, res,

232
00:18:27,630 --> 00:18:30,250
tiếp theo ngay có quá.

233
00:18:30,250 --> 00:18:32,270
Bây giờ, nếu điều này xảy ra,

234
00:18:32,270 --> 00:18:36,780
vì vậy chúng tôi sẽ nói nếu err,

235
00:18:36,780 --> 00:18:40,425
vì vậy nếu có một lỗi xảy ra,

236
00:18:40,425 --> 00:18:45,395
chúng tôi sẽ nói trở lại err tiếp theo và sau đó để cho

237
00:18:45,395 --> 00:18:51,480
trình xử lý lỗi của bộ định tuyến nhanh của chúng tôi và chăm sóc điều đó.

238
00:18:51,480 --> 00:18:56,755
Bây giờ, chúng tôi sẽ xem xét các tình huống khác, nếu không phải là người dùng.

239
00:18:56,755 --> 00:18:59,630
Vì vậy, nếu chúng ta đã đạt đến thời điểm này,

240
00:18:59,630 --> 00:19:02,580
thì điều đó có nghĩa là nó không phải là một lỗi xảy ra

241
00:19:02,580 --> 00:19:05,615
nhưng thay vào đó có lẽ người dùng không thể được tìm thấy.

242
00:19:05,615 --> 00:19:07,100
Nếu người dùng không được tìm thấy,

243
00:19:07,100 --> 00:19:11,190
thì người dùng ở đây sẽ được đặt thành null trong trường hợp này.

244
00:19:11,190 --> 00:19:14,634
Vì vậy, trong tình huống đó,

245
00:19:14,634 --> 00:19:17,375
nếu người dùng không tồn tại,

246
00:19:17,375 --> 00:19:23,680
thì chúng ta cần có khả năng truyền thông tin về phía máy chủ.

247
00:19:23,680 --> 00:19:28,435
Vì vậy, những gì chúng tôi sẽ làm là chúng tôi sẽ vượt qua thông tin này ở định dạng này.

248
00:19:28,435 --> 00:19:32,020
Vì vậy, tôi sẽ cắt điều này ra từ đây và

249
00:19:32,020 --> 00:19:36,640
sau đó dán nó vào đây và sau đó chúng tôi sẽ chỉnh sửa này.

250
00:19:36,640 --> 00:19:40,704
Vì vậy, nếu người dùng là null,

251
00:19:40,704 --> 00:19:45,830
sau đó chúng tôi sẽ gửi lại một mã trạng thái là 401 có nghĩa là

252
00:19:45,830 --> 00:19:53,975
trái phép và sau đó chúng tôi sẽ gửi lại thông tin thành công sai,

253
00:19:53,975 --> 00:19:57,405
và sau đó chúng tôi sẽ không được chuyển trở lại mã thông báo,

254
00:19:57,405 --> 00:20:00,795
chúng tôi sẽ vượt qua thông báo trạng thái.

255
00:20:00,795 --> 00:20:03,135
Vì vậy, ở đây chúng ta sẽ nói

256
00:20:03,135 --> 00:20:12,670
'Đăng nhập không thành công' và sau đó thông tin thứ ba,

257
00:20:12,670 --> 00:20:18,070
chúng tôi sẽ vượt qua thông tin này đối tượng mà chúng tôi nhận được ở đây như là

258
00:20:18,070 --> 00:20:25,635
phần thứ ba trong thư trả lời mà chúng tôi gửi lại từ máy chủ của chúng tôi ở đây.

259
00:20:25,635 --> 00:20:28,935
Vì vậy, cờ thành công sẽ được đặt thành false,

260
00:20:28,935 --> 00:20:32,385
trạng thái sẽ được đặt Đăng nhập không thành công và

261
00:20:32,385 --> 00:20:36,725
thông tin lỗi được thông qua trong thông tin sẽ được thông qua trở lại.

262
00:20:36,725 --> 00:20:39,855
Bây giờ, lưu ý rằng tình huống này sẽ xảy ra nếu

263
00:20:39,855 --> 00:20:43,125
tên người dùng và mật khẩu là không chính xác,

264
00:20:43,125 --> 00:20:48,600
và vì vậy đây không phải là một lỗi trong ý nghĩa lỗi nhưng thực tế là

265
00:20:48,600 --> 00:20:54,040
xác thực không thể tìm thấy người dùng hoặc mật khẩu của người dùng là không chính xác.

266
00:20:54,040 --> 00:20:58,530
Vì vậy, thông tin đó sẽ được mã hóa vào thông tin đi kèm và do đó tôi sẽ

267
00:20:58,530 --> 00:21:04,590
vượt qua trở lại như là một lỗi cho phía khách hàng của tôi.

268
00:21:04,590 --> 00:21:09,615
Phần khác

269
00:21:09,615 --> 00:21:15,355
được xử lý như Req.login.

270
00:21:15,355 --> 00:21:17,220
Vì vậy, nếu điều này là thành công,

271
00:21:17,220 --> 00:21:22,710
các passport.authenticate chúng tôi sẽ thêm phương pháp này được gọi là req.login cho người dùng.

272
00:21:22,710 --> 00:21:24,340
Vì vậy, tại thời điểm này,

273
00:21:24,340 --> 00:21:27,950
chúng tôi sẽ chỉ đơn giản là vượt qua trong đối tượng người dùng mà chúng tôi đã thu được.

274
00:21:27,950 --> 00:21:31,055
Vì vậy, ở đây, nếu chúng ta đã đạt đến thời điểm này,

275
00:21:31,055 --> 00:21:36,195
thì điều đó có nghĩa là đối tượng người dùng không phải là null và cũng không có lỗi xảy ra,

276
00:21:36,195 --> 00:21:40,090
do đó có nghĩa là người dùng có thể đăng nhập.

277
00:21:41,080 --> 00:21:44,550
Vì vậy, chúng tôi sẽ nói sai lầm,

278
00:21:48,960 --> 00:21:51,460
chúng tôi sẽ cố gắng đăng nhập người dùng.

279
00:21:51,460 --> 00:21:58,000
Vì vậy, chúng tôi sẽ nói nếu sai lầm và

280
00:21:58,000 --> 00:22:05,345
sau đó chúng tôi sẽ vượt qua cùng một loại thông tin lỗi mà chúng tôi đã làm ở đây.

281
00:22:05,345 --> 00:22:09,840
Vì vậy, trong trường hợp này, nếu lỗi,

282
00:22:13,290 --> 00:22:19,430
sau đó chúng tôi sẽ vượt qua một mã trạng thái là 401 và chúng tôi sẽ nói thành công

283
00:22:19,430 --> 00:22:25,125
là sai và trạng thái là Đăng nhập không thành công,

284
00:22:25,125 --> 00:22:28,340
và sau đó thông tin lỗi,

285
00:22:29,280 --> 00:22:31,840
thay vì thông tin,

286
00:22:31,840 --> 00:22:42,380
chúng tôi sẽ vượt qua trong 'Không thể đăng nhập người dùng”.

287
00:22:42,380 --> 00:22:48,960
Vì vậy, đó là thông báo mà chúng tôi sẽ vượt qua ở đây nếu lỗi xảy ra.

288
00:22:48,960 --> 00:22:53,200
Nếu không, chúng ta sẽ xuống dưới đây.

289
00:22:53,200 --> 00:22:55,960
Vì vậy, tại thời điểm này,

290
00:22:55,960 --> 00:22:59,440
chúng tôi sẽ có thể tạo ra mã thông báo.

291
00:22:59,440 --> 00:23:02,495
Vì vậy, nếu chúng ta đã đạt đến thời điểm này, điều

292
00:23:02,495 --> 00:23:06,370
đó có nghĩa là người dùng đã đăng nhập thành công,

293
00:23:06,370 --> 00:23:08,430
và vì vậy bây giờ chúng ta có thể tạo ra mã thông báo.

294
00:23:08,430 --> 00:23:12,705
Vì vậy, chúng tôi sẽ tạo ra mã thông báo dựa trên ID của người dùng,

295
00:23:12,705 --> 00:23:18,350
và sau đó chúng tôi sẽ chuyển lại mã thông báo trở lại cho người dùng.

296
00:23:18,350 --> 00:23:21,635
Vì vậy, ở đây, chúng ta sẽ nói var token,

297
00:23:21,635 --> 00:23:30,730
và sau đó chúng ta có thể nói res.StatusCode là 200 và sau đó res.json thành công đúng,

298
00:23:30,730 --> 00:23:33,600
vì vậy, có nghĩa là người dùng đăng nhập thành công.

299
00:23:33,600 --> 00:23:38,490
Vì vậy, trạng thái sẽ được đăng nhập thành công.

300
00:23:38,490 --> 00:23:40,605
Sau đó, phần thứ ba,

301
00:23:40,605 --> 00:23:42,360
thay vì lỗi,

302
00:23:42,360 --> 00:23:46,200
tôi sẽ chuyển mã thông báo trở lại cho người dùng.

303
00:23:46,200 --> 00:23:48,760
Vì vậy, chúng ta sẽ nói mã thông báo, mã

304
00:23:51,100 --> 00:23:54,675
thông báo này mà chúng ta vừa thu được trước đó.

305
00:23:54,675 --> 00:24:01,030
Vì vậy, mã thông báo đó sẽ được thông qua như là thuộc tính mã thông báo của thư trả lời.

306
00:24:01,030 --> 00:24:04,560
Vì vậy, ở đây, nhận thấy rằng sự thành công được đặt thành true, do

307
00:24:04,560 --> 00:24:08,340
đó, có nghĩa là người dùng đăng nhập thành công,

308
00:24:08,340 --> 00:24:12,290
và do đó người dùng có thể tiến hành thêm vào thời điểm này.

309
00:24:12,290 --> 00:24:19,050
Điều này phải được thực hiện bên trong Req.login ở đây.

310
00:24:19,820 --> 00:24:22,970
Vì vậy, tại thời điểm này,

311
00:24:22,970 --> 00:24:27,180
chúng tôi sẽ đóng Req.login.

312
00:24:27,180 --> 00:24:33,735
Vì vậy, chú ý rằng đây là bên trong Req.login này ở đây.

313
00:24:33,735 --> 00:24:37,320
Vì vậy, trong đó, chúng ta sẽ vượt qua ba thứ này.

314
00:24:37,320 --> 00:24:41,370
Vì vậy, để tôi chỉ thụt lề ba dòng này vào.

315
00:24:41,720 --> 00:24:48,850
Vì vậy, đó là cách chúng tôi sẽ xử lý phương pháp đăng nhập của người dùng.

316
00:24:48,850 --> 00:24:52,230
Vì vậy, một lần nữa, xem xét lại mã này một lần nữa.

317
00:24:52,230 --> 00:24:53,950
Vì vậy, chúng tôi sẽ làm bài router,

318
00:24:53,950 --> 00:24:56,815
nhưng thay vì làm hộ chiếu xác thực ngay tại đó,

319
00:24:56,815 --> 00:24:58,960
chúng tôi sẽ nói req, res,

320
00:24:58,960 --> 00:25:01,240
tiếp theo, và sau đó bên trong đây,

321
00:25:01,240 --> 00:25:04,285
chúng tôi sẽ làm một hộ chiếu xác thực cho địa phương,

322
00:25:04,285 --> 00:25:06,560
và xác thực này sẽ vượt qua trở lại.

323
00:25:06,560 --> 00:25:09,250
Vì vậy, chúng ta có thể cung cấp một hàm callback để điều đó,

324
00:25:09,250 --> 00:25:11,810
và hàm callback này sẽ trả về một trong hai lỗi,

325
00:25:11,810 --> 00:25:14,730
người dùng, hoặc thông tin ở đây.

326
00:25:14,730 --> 00:25:16,300
Vì vậy, nếu nó là một lỗi,

327
00:25:16,300 --> 00:25:20,735
chúng tôi sẽ chỉ cho phép trình xử lý lỗi thể hiện để chăm sóc điều đó.

328
00:25:20,735 --> 00:25:22,730
Nếu người dùng là null,

329
00:25:22,730 --> 00:25:26,940
thì điều đó có nghĩa là đăng nhập người dùng không thành

330
00:25:26,940 --> 00:25:29,730
công và lý do cho điều đó sẽ nằm trong thông tin.

331
00:25:29,730 --> 00:25:36,870
Vì vậy, điều đó sẽ vượt qua trở lại như là lỗi thông tin trong tin nhắn trả lời ở đây.

332
00:25:36,870 --> 00:25:38,790
Nếu chúng ta đi đến thời điểm này,

333
00:25:38,790 --> 00:25:43,555
thì người dùng được xác minh thành công.

334
00:25:43,555 --> 00:25:45,400
Vì vậy, sau đó chúng tôi sẽ đăng nhập vào người dùng.

335
00:25:45,400 --> 00:25:47,630
Vì vậy, hộ chiếu xác thực,

336
00:25:47,630 --> 00:25:53,385
chúng tôi sẽ thêm vào phương pháp này được gọi là đăng nhập vào req, thông báo yêu cầu.

337
00:25:53,385 --> 00:25:56,770
Vì vậy, chúng ta có thể gọi tên đăng nhập với người dùng.

338
00:25:56,770 --> 00:25:59,355
Nếu điều này trả về một lỗi,

339
00:25:59,355 --> 00:26:03,105
sau đó chúng tôi sẽ trả lại lỗi ở đây một cách thích hợp.

340
00:26:03,105 --> 00:26:08,590
Nếu không, thì chúng tôi sẽ đạt đến điểm mà người dùng được chứng thực thành công.

341
00:26:08,590 --> 00:26:12,630
Vì vậy, chúng tôi có thể tạo ra JSON Web Token ở đây và sau đó trả lại

342
00:26:12,630 --> 00:26:18,315
JSON Web Token cho người dùng để xác nhận rằng người dùng đã đăng nhập thành công.

343
00:26:18,315 --> 00:26:21,545
Vì vậy, đó là tập hợp các bước mà chúng ta sẽ sử dụng ở đây.

344
00:26:21,545 --> 00:26:25,735
Bây giờ, lý do tại sao tôi làm một cách phức tạp hơn để xử lý nó là

345
00:26:25,735 --> 00:26:30,035
tôi muốn phân biệt giữa tình huống mà một lỗi chính hãng

346
00:26:30,035 --> 00:26:34,170
xảy ra trong quá trình xác thực như trái ngược với tình

347
00:26:34,170 --> 00:26:39,095
huống mà tên người dùng không hợp lệ hoặc mật khẩu không hợp lệ.

348
00:26:39,095 --> 00:26:42,860
Vì vậy, hai trường hợp đó sẽ được xử lý bởi tình huống này,

349
00:26:42,860 --> 00:26:46,550
nơi mà thông tin sẽ mang thông tin về cho chúng tôi.

350
00:26:46,550 --> 00:26:48,900
Vì vậy, đó không phải là một lỗi riêng,

351
00:26:48,900 --> 00:26:52,090
nhưng đó là tình huống mà người dùng

352
00:26:52,090 --> 00:26:55,710
không phải là một người dùng hợp lệ hoặc mật khẩu của người dùng không hợp lệ.

353
00:26:55,710 --> 00:27:01,070
Vì vậy, đó là cách chúng tôi sẽ xử lý quá trình đăng nhập của người dùng.

354
00:27:01,070 --> 00:27:03,660
Ngoài ra, tôi sẽ thêm vào

355
00:27:03,660 --> 00:27:14,825
một phương pháp nữa ở đây được gọi là CheckJWTToken.

356
00:27:14,825 --> 00:27:21,100
Nó là khá có thể rằng trong khi khách hàng đã đăng nhập và có được JSON Web Token,

357
00:27:21,100 --> 00:27:24,855
đôi khi sau đó, JSON Web Token có thể hết hạn.

358
00:27:24,855 --> 00:27:32,840
Vì vậy, nếu người dùng cố gắng truy cập từ phía khách hàng với một mã thông báo hết hạn đến

359
00:27:32,840 --> 00:27:35,610
máy chủ, thì máy chủ sẽ không thể xác thực người dùng.

360
00:27:35,610 --> 00:27:37,780
Vì vậy, theo khoảng thời gian định kỳ,

361
00:27:37,780 --> 00:27:42,180
chúng tôi có thể muốn kiểm tra chéo để đảm bảo rằng JSON Web Token vẫn còn hợp lệ.

362
00:27:42,180 --> 00:27:44,975
Vì vậy, đó là lý do tại sao tôi bao gồm điều này,

363
00:27:44,975 --> 00:27:49,620
một điểm cuối khác được gọi là CheckJWTToken.

364
00:27:49,620 --> 00:27:53,155
Vì vậy, nếu bạn thực hiện một get để CheckJWTToken bằng cách

365
00:27:53,155 --> 00:27:58,700
bao gồm các token vào tiêu đề ủy quyền,

366
00:27:58,700 --> 00:28:02,490
sau đó cuộc gọi này sẽ trả về một true hoặc false

367
00:28:02,490 --> 00:28:06,535
để chỉ cho bạn xem JSON Web Token vẫn còn hợp lệ hay không.

368
00:28:06,535 --> 00:28:10,930
Nếu nó là không hợp lệ, sau đó phía khách hàng có thể bắt đầu một đăng nhập khác cho

369
00:28:10,930 --> 00:28:15,945
người dùng để có được một JSON Web Token mới nếu cần thiết.

370
00:28:15,945 --> 00:28:17,285
Vì vậy, để làm điều này,

371
00:28:17,285 --> 00:28:27,109
chúng ta sẽ nói Cors.CorsWithOptions và req,

372
00:28:27,109 --> 00:28:31,385
res ở đây như mong đợi.

373
00:28:31,385 --> 00:28:35,670
Trong đây, chúng ta sẽ nói

374
00:28:39,820 --> 00:28:49,360
hộ chiếu xác thực jwt

375
00:28:49,360 --> 00:28:57,150
và phiên: false,

376
00:29:00,020 --> 00:29:07,270
và điều này sẽ trả lại err, người dùng, thông tin.

377
00:29:09,020 --> 00:29:13,770
Vì vậy, nhớ lại cách chúng tôi sử dụng hộ chiếu xác thực trước đó.

378
00:29:13,770 --> 00:29:17,195
Vì vậy, chúng tôi gọi JWT với phiên false ở đây.

379
00:29:17,195 --> 00:29:21,745
Vì vậy, trước đó ở đây, chúng tôi nói hộ chiếu xác thực địa phương.

380
00:29:21,745 --> 00:29:23,535
Vì vậy, đây là để xác thực địa phương.

381
00:29:23,535 --> 00:29:27,330
Vì vậy, điều này là để xác thực JSON Web Token.

382
00:29:27,330 --> 00:29:29,430
Vì vậy, khi chúng tôi gọi đó,

383
00:29:29,430 --> 00:29:33,435
sau đó kể từ đó sẽ xác minh JSON Web Token, vì vậy chúng tôi sẽ nói,

384
00:29:33,435 --> 00:29:40,335
nếu err trở lại tiếp theo err,

385
00:29:40,335 --> 00:29:44,895
và sau đó để cho trình xử lý lỗi thể hiện chăm sóc tình huống đó.

386
00:29:44,895 --> 00:29:50,469
Sau đó, chúng ta sẽ nói, nếu không phải là người dùng,

387
00:29:53,330 --> 00:30:00,330
nếu người dùng không tồn tại, thì tương tự như vậy.

388
00:30:00,330 --> 00:30:03,510
Vì vậy, có nghĩa là nếu đối tượng người dùng được

389
00:30:03,510 --> 00:30:07,810
tìm thấy từ JSON Web Token và sau đó được nạp vào req.user,

390
00:30:07,810 --> 00:30:11,400
thì điều đó có nghĩa là người dùng là người dùng hợp lệ,

391
00:30:11,400 --> 00:30:13,485
và do đó có thể được phép tiếp tục.

392
00:30:13,485 --> 00:30:20,330
Nếu không, chúng ta sẽ nói rằng người dùng không tồn tại.

393
00:30:20,330 --> 00:30:24,995
Vì vậy, chúng ta cần thông báo rằng JSON Web Token đã hết hạn.

394
00:30:24,995 --> 00:30:26,180
Vì vậy, tại thời điểm này,

395
00:30:26,180 --> 00:30:29,090
chúng tôi sẽ gửi một res với

396
00:30:29,090 --> 00:30:36,545
một mã trạng thái 401.

397
00:30:36,545 --> 00:30:47,130
Vì vậy, trái phép, SeTheader, Content-Type,

398
00:30:49,900 --> 00:30:56,280
ứng dụng/json, và sau đó chúng tôi sẽ trả lại res.

399
00:30:58,680 --> 00:31:13,750
Res.json sẽ nói trạng thái JWT

400
00:31:13,750 --> 00:31:17,090
không hợp lệ và sau đó,

401
00:31:17,730 --> 00:31:23,690
chúng tôi sẽ trả lại một lá cờ gọi là thành công rơi và sau đó,

402
00:31:23,880 --> 00:31:29,080
chúng tôi sẽ trả lại thông tin mà chúng tôi có được nếu người dùng

403
00:31:29,080 --> 00:31:34,460
không được xác thực là lỗi tại thời điểm này.

404
00:31:36,420 --> 00:31:40,480
Nếu không, điều đó có nghĩa là chúng tôi đã đạt đến thời điểm này,

405
00:31:40,480 --> 00:31:43,220
sau đó người dùng là một người dùng hợp lệ.

406
00:31:43,220 --> 00:31:44,850
Vì vậy, trong trường hợp này,

407
00:31:44,850 --> 00:31:47,230
hãy để tôi chỉ cần sao chép mã đó ở đây,

408
00:31:47,230 --> 00:31:54,070
chúng tôi sẽ gửi một mã trạng thái của 200 và sau đó res.json,

409
00:31:54,070 --> 00:32:02,720
sẽ gửi JWT hợp lệ và thành công là sự thật.

410
00:32:02,940 --> 00:32:09,820
Phần thứ ba, chúng tôi sẽ gửi thông tin của người dùng.

411
00:32:09,820 --> 00:32:16,000
Vì vậy, theo cách đó, khi điểm cuối này được gọi với phương thức get,

412
00:32:16,000 --> 00:32:19,170
sau đó điều này sẽ xác minh cho dù mã thông báo là hợp lệ hay không.

413
00:32:19,170 --> 00:32:20,220
Nếu token là hợp lệ,

414
00:32:20,220 --> 00:32:24,020
sau đó bạn sẽ nhận được trả lời này và từ cờ thành công trong bài trả lời,

415
00:32:24,020 --> 00:32:27,770
bạn có thể kiểm tra xem jsonwebtoken có hợp lệ hay không.

416
00:32:27,770 --> 00:32:32,155
Điều này rất hữu ích ở phía khách hàng.

417
00:32:32,155 --> 00:32:37,825
Bây giờ, hộ chiếu này xác thực ở đây sẽ phải được cung cấp

418
00:32:37,825 --> 00:32:43,790
với req và res như hai tham số ở đây.

419
00:32:43,790 --> 00:32:47,630
Vì vậy, đó là cách chúng tôi gọi là chứng thực hộ chiếu.

420
00:32:47,630 --> 00:32:49,355
Vì vậy, lưu ý rằng bất cứ khi nào bạn gọi

421
00:32:49,355 --> 00:32:52,840
hộ chiếu xác thực và mong đợi chức năng gọi lại này ở đây,

422
00:32:52,840 --> 00:33:01,825
bạn cần phải nối thêm vào thời điểm này req.res để chứng thực hộ chiếu ở phía sau đây.

423
00:33:01,825 --> 00:33:03,890
Trong máy chủ API còn lại của chúng

424
00:33:03,890 --> 00:33:07,490
tôi, chúng tôi đã thực hiện ý kiến của chúng tôi theo cách mà các ý kiến

425
00:33:07,490 --> 00:33:12,245
hình thành các tài liệu phụ bên trong tài liệu của dishe,

426
00:33:12,245 --> 00:33:16,540
vì vậy họ mua mỗi món ăn kèm theo bộ ý kiến riêng của mình.

427
00:33:16,540 --> 00:33:19,520
Nhưng cách chúng tôi thực hiện khách hàng React của chúng tôi là

428
00:33:19,520 --> 00:33:22,965
như vậy mà các ý kiến được giữ độc lập với các món ăn,

429
00:33:22,965 --> 00:33:27,680
và các ý kiến tự mang ID món ăn tương ứng.

430
00:33:27,680 --> 00:33:30,400
Bây giờ, đây là hai cách khác nhau để

431
00:33:30,400 --> 00:33:34,445
thực hiện phía máy chủ cũng như phía máy khách.

432
00:33:34,445 --> 00:33:39,685
Trong ứng dụng Angular mà chúng tôi được thực hiện trong chuyên môn Angular của chúng

433
00:33:39,685 --> 00:33:43,470
tôi, chúng tôi đã sử dụng phương pháp tài liệu phụ để

434
00:33:43,470 --> 00:33:47,560
xử lý nhận xét trong ứng dụng khách Angular của chúng tôi.

435
00:33:47,560 --> 00:33:50,050
Vì vậy, máy chủ API còn lại đã được

436
00:33:50,050 --> 00:33:54,090
thực hiện theo cách mà nó phù hợp hơn cho máy khách Angular.

437
00:33:54,090 --> 00:34:00,600
Nhưng đối với các khách hàng React kể từ khi chúng tôi giữ các ý kiến độc lập với các món ăn,

438
00:34:00,600 --> 00:34:03,985
và sau đó sử dụng ID món ăn bên trong bình luận,

439
00:34:03,985 --> 00:34:09,300
vì vậy chúng tôi cần phải cơ cấu lại máy chủ API còn lại của chúng tôi,

440
00:34:09,300 --> 00:34:16,835
vì vậy nó là chúng tôi có một điểm cuối bình luận riêng biệt độc lập với các món ăn điểm cuối.

441
00:34:16,835 --> 00:34:22,310
Vì vậy, chúng ta cần phải cấu trúc lại mã của chúng tôi trong máy chủ

442
00:34:22,310 --> 00:34:29,140
để giới thiệu các /comments REST API điểm cuối ở giai đoạn này.

443
00:34:29,140 --> 00:34:30,600
Vì vậy, để làm điều đó,

444
00:34:30,600 --> 00:34:37,540
chúng ta hãy đi trước và thực hiện một mô hình mới được gọi là comment.js.

445
00:34:37,540 --> 00:34:39,260
Vì vậy, đi vào các mô hình,

446
00:34:39,260 --> 00:34:45,790
hãy để tôi thực hiện một tập tin mới có tên comments.js.

447
00:34:47,220 --> 00:34:50,015
Trong tập tin comments.js,

448
00:34:50,015 --> 00:34:56,110
chúng tôi sẽ di chuyển CommentSchema từ tập tin dishes.js

449
00:34:56,110 --> 00:35:02,660
vào tập tin comments.js và sau đó loại bỏ nó hoàn toàn từ tập tin dishes.js.

450
00:35:02,660 --> 00:35:03,900
Nhưng trước khi chúng ta làm điều đó,

451
00:35:03,900 --> 00:35:08,770
chúng ta cần sao chép các mongoose và giản đồ từ đây,

452
00:35:08,770 --> 00:35:13,860
vì vậy hãy để tôi chỉ sao chép điều này từ dishes.js vào comment.js.

453
00:35:13,860 --> 00:35:16,590
Sau đó, đi vào dishes.js,

454
00:35:16,590 --> 00:35:21,040
hãy để tôi cắt CommentSchema này hoàn toàn ra khỏi đây,

455
00:35:21,040 --> 00:35:28,300
bởi vì chúng tôi sẽ có điều này một cách riêng biệt trong mô hình ý kiến ở đây.

456
00:35:28,300 --> 00:35:33,070
Vì vậy, chúng ta hãy di chuyển nó vào mô hình nhận xét và sau đó dán nó vào đây.

457
00:35:33,070 --> 00:35:35,050
Nhưng tất nhiên đây không phải là hoàn chỉnh,

458
00:35:35,050 --> 00:35:37,870
chúng tôi sẽ cập nhật CommentSchema một chút.

459
00:35:37,870 --> 00:35:39,300
Nhưng trước khi chúng tôi làm điều đó,

460
00:35:39,300 --> 00:35:43,455
quay trở lại tập tin dishes.js và trong tập tin món ăn,

461
00:35:43,455 --> 00:35:47,925
chúng tôi sẽ loại bỏ các ý kiến từ DishessChema,

462
00:35:47,925 --> 00:35:51,510
bởi vì chúng tôi sẽ lưu trữ nội dung riêng biệt với

463
00:35:51,510 --> 00:35:55,550
các món ăn trong phiên bản này của máy chủ của chúng tôi.

464
00:35:55,550 --> 00:36:00,450
Vì vậy, đó là cách chúng tôi sẽ cập nhật mô hình món ăn ở đây.

465
00:36:00,450 --> 00:36:08,180
Vì vậy, chúng tôi đã loại bỏ các ý kiến hoàn toàn khỏi mô hình món ăn ở đây.

466
00:36:08,180 --> 00:36:10,270
Đi vào mô hình ý kiến,

467
00:36:10,270 --> 00:36:15,355
vì vậy bây giờ chúng ta thấy rằng chúng ta có CommentSchema thực hiện ở đây.

468
00:36:15,355 --> 00:36:19,525
Nhưng ngoài ra, trong CommentsSchema,

469
00:36:19,525 --> 00:36:23,330
bây giờ chúng ta cần phải rõ ràng trỏ đến

470
00:36:23,330 --> 00:36:28,885
món ăn cụ thể mà nhận xét này là bình luận tương ứng.

471
00:36:28,885 --> 00:36:30,700
Bây giờ, đây là nơi

472
00:36:30,700 --> 00:36:37,435
quần thể con ngỗng của chúng ta và

473
00:36:37,435 --> 00:36:41,580
cách chúng ta lưu trữ vật Ids đến để giải cứu chúng ta.

474
00:36:41,580 --> 00:36:45,860
Vì vậy, chúng tôi sẽ cập nhật CommentSchema nói rằng chúng tôi sẽ có đánh giá

475
00:36:45,860 --> 00:36:47,800
, bình luận và tác giả ở đây.

476
00:36:47,800 --> 00:36:49,110
Ngoài tác giả,

477
00:36:49,110 --> 00:36:56,080
chúng tôi sẽ giới thiệu thêm một lĩnh vực được gọi là món ăn ở đây là

478
00:36:56,080 --> 00:37:05,540
loại: Mongoose.schema types.ObjectID,

479
00:37:06,390 --> 00:37:19,870
và vì vậy điều này sẽ đề cập đến Dish ở đây.

480
00:37:19,870 --> 00:37:29,060
Vì vậy, đây sẽ là một đối tượng tham chiếu đến mô hình món ăn ở đây,

481
00:37:29,060 --> 00:37:32,255
và vì vậy với sửa đổi này bây giờ

482
00:37:32,255 --> 00:37:36,640
ý kiến của chúng tôi sẽ chứa lĩnh vực đánh giá, lĩnh vực bình luận,

483
00:37:36,640 --> 00:37:42,355
tác giả mà lại là một tham chiếu đến người dùng tương ứng,

484
00:37:42,355 --> 00:37:47,660
và sau đó lĩnh vực món ăn đó là một tham chiếu đến tương ứng món ăn ở đây.

485
00:37:47,660 --> 00:37:50,060
Vì vậy, có nghĩa là bây giờ chúng ta sẽ cần phải

486
00:37:50,060 --> 00:37:53,640
điền vào các ý kiến với cả tác giả và lĩnh vực món ăn.

487
00:37:53,640 --> 00:37:55,565
Một khi chúng tôi đã hoàn thành điều này,

488
00:37:55,565 --> 00:38:01,585
sau đó chúng tôi sẽ nói var Bình luận

489
00:38:01,585 --> 00:38:09,910
mongoose.model và chúng tôi sẽ gọi này 'Bình luận',

490
00:38:09,910 --> 00:38:16,765
và sau đó điều này sử dụng CommentSchema mà chúng tôi vừa xác định ở đây,

491
00:38:16,765 --> 00:38:21,970
và sau đó chúng tôi cần phải xuất khẩu này từ đây,

492
00:38:21,970 --> 00:38:25,280
bình luận .model từ đây.

493
00:38:25,280 --> 00:38:28,395
Vì vậy, bây giờ chúng tôi đã giới thiệu các bình luận .model,

494
00:38:28,395 --> 00:38:35,045
sau đó chúng tôi sẽ tiếp tục và sau đó giới thiệu một Router mới được gọi là CommentOrter.

495
00:38:35,045 --> 00:38:37,060
Vì vậy, để giới thiệu bộ định tuyến nhận xét,

496
00:38:37,060 --> 00:38:39,630
chúng ta hãy đi vào các tuyến đường ở đây,

497
00:38:39,630 --> 00:38:45,990
và sau đó tạo một tệp mới có tên commentRouter.js.

498
00:38:47,090 --> 00:38:52,415
Trong commentRouter.js, cho phép tôi sao chép một vài điều

499
00:38:52,415 --> 00:38:59,890
trên từ DishRouter.

500
00:38:59,890 --> 00:39:07,720
Vì vậy, chúng tôi sẽ có những ý kiến ở đây,

501
00:39:07,720 --> 00:39:14,865
vì vậy hãy để tôi sao chép qua những điều này từ và cũng có thể,

502
00:39:14,865 --> 00:39:21,070
trong khi tôi ở nó cho phép tôi chỉ cần sao chép những cũng lên đến thời điểm đó,

503
00:39:21,070 --> 00:39:24,625
và sau đó tôi sẽ cập nhật điều đó một chút sau đó.

504
00:39:24,625 --> 00:39:26,680
Vì vậy, đi vào bình luận,

505
00:39:26,680 --> 00:39:28,040
chúng ta cần tất cả các phần này,

506
00:39:28,040 --> 00:39:33,640
vì vậy chúng tôi sẽ nói Com, Express, BodyParser, mongoose,

507
00:39:33,640 --> 00:39:37,735
authenticate, cors, và sau đó chúng tôi

508
00:39:37,735 --> 00:39:46,490
sẽ nhập bình luận từ các mô hình/bình luận.

509
00:39:49,950 --> 00:40:00,460
Sau đó, chúng tôi sẽ gọi đây là bình luận mà là một Express.Router đây.

510
00:40:02,060 --> 00:40:11,950
Sau đó, chúng tôi sẽ nói CommentOrter sử dụng BodyParser,

511
00:40:11,950 --> 00:40:17,915
và sau đó điều này bây giờ sẽ trở thành con đường CommentOrter.

512
00:40:17,915 --> 00:40:22,030
Bây giờ, chúng ta cần phải đi vào DishRouter và sau đó

513
00:40:22,030 --> 00:40:27,200
loại bỏ tất cả các phần đề cập đến các ý kiến ở đây.

514
00:40:27,200 --> 00:40:34,330
Vì vậy, hãy để tôi chỉ cần cắt ra phần này và sau đó chúng tôi sẽ tái sử dụng những cho bình luận của chúng tôi.

515
00:40:34,330 --> 00:40:38,200
Vì vậy, tất cả những điều này không còn cần thiết trong DishRouter.

516
00:40:38,200 --> 00:40:42,080
Vì vậy, tôi sẽ loại bỏ tất cả điều này từ DishRouter ở đây,

517
00:40:42,080 --> 00:40:43,770
vì vậy hãy để tôi cắt chúng ra,

518
00:40:43,770 --> 00:40:48,715
tất cả mọi thứ liên quan đến lộ trình ý kiến từ DishRouter,

519
00:40:48,715 --> 00:40:50,770
sau đó chúng tôi sẽ đi vào bình luận,

520
00:40:50,770 --> 00:40:54,405
và sau đó cho phép tôi đi trước và dán vào vị trí ở đây,

521
00:40:54,405 --> 00:40:57,100
sau đó chúng tôi sẽ chỉnh sửa điều đó ở đây.

522
00:40:57,100 --> 00:41:02,660
Sau đó, sau đó, chúng ta cần xuất CommentOter.

523
00:41:05,160 --> 00:41:08,205
Vì vậy, sẽ xuất bình luận cho chúng tôi.

524
00:41:08,205 --> 00:41:12,060
Nhưng tất nhiên, mã này không hoàn toàn chính xác.

525
00:41:12,060 --> 00:41:14,995
Vì vậy, chúng ta cần phải đi trước và sửa chữa mã này ở đây.

526
00:41:14,995 --> 00:41:16,585
Vì vậy, cho mã này,

527
00:41:16,585 --> 00:41:20,180
bây giờ chúng ta nhận ra rằng đây không phải là tuyến đường DishRouter,

528
00:41:20,180 --> 00:41:21,785
thay vào đó phải là

529
00:41:21,785 --> 00:41:27,700
/endpoint bởi vì chúng ta

530
00:41:27,700 --> 00:41:33,685
sẽ được gắn kết này trong /comments điểm cuối đây.

531
00:41:33,685 --> 00:41:35,685
Vì vậy, chúng ta sẽ nói Commentrouter,

532
00:41:35,685 --> 00:41:39,859
và sau đó các tùy chọn CorsWithOptions (req,

533
00:41:39,859 --> 00:41:42,550
res) mà vẫn còn như vậy ở

534
00:41:42,550 --> 00:41:48,429
đó, và sau đó nhận cors.cors và sau đó req.res,

535
00:41:48,429 --> 00:41:52,460
và sau đó điều này sẽ trở thành bình luận.

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

537
00:42:00,600 --> 00:42:05,330
Vì vậy, đây sẽ là bình luận. Tìm

538
00:42:07,050 --> 00:42:17,080
và req.query đây.

539
00:42:17,080 --> 00:42:20,920
Vì vậy, khi các ý kiến được tìm thấy,

540
00:42:20,920 --> 00:42:22,974
sau đó, tại thời điểm này,

541
00:42:22,974 --> 00:42:25,940
chúng tôi sẽ cư trú tác giả,

542
00:42:26,880 --> 00:42:30,430
đã có ở đó, cư trú ở đây.

543
00:42:30,430 --> 00:42:33,380
Vì vậy, tôi chỉ cần loại bỏ bình luận này.author, và sau đó,

544
00:42:33,380 --> 00:42:37,410
chúng tôi sẽ chỉ đơn giản là cư tác giả ở đây.

545
00:42:37,410 --> 00:42:44,425
Sau đó, điều này sẽ cung cấp cho chúng tôi ý kiến ở đây.

546
00:42:44,425 --> 00:42:49,310
Sau đó, chúng ta sẽ nói, điều này có thể được đơn giản hóa đáng kể.

547
00:42:49,310 --> 00:42:53,835
Vì vậy, lỗi bắt là ở đó anyway.

548
00:42:53,835 --> 00:43:00,805
Vì vậy, khi nhận xét đến, nó sẽ đơn giản trở lại.

549
00:43:00,805 --> 00:43:03,910
Xin lỗi, phải thế thôi.

550
00:43:03,910 --> 00:43:06,525
Vì vậy, nếu cho nhận được,

551
00:43:06,525 --> 00:43:09,305
khi chúng tôi nhận được các ý kiến, bình

552
00:43:09,305 --> 00:43:13,760
luận. Tìm req.query, .populate tác giả ở đây,

553
00:43:13,760 --> 00:43:18,010
và sau đó, chúng tôi sẽ nói, .then ý kiến,

554
00:43:18,010 --> 00:43:21,619
và sau đó, chúng tôi sẽ nói, res.StatusCode 200,

555
00:43:21,619 --> 00:43:27,605
Setheader, và sau đó, chúng tôi sẽ trả lại ý kiến từ đây,

556
00:43:27,605 --> 00:43:30,850
res.json ý kiến từ đây.

557
00:43:30,850 --> 00:43:36,970
Bây giờ, tôi không điền vào các món ăn ở đây bởi vì tôi không rõ ràng cần

558
00:43:36,970 --> 00:43:45,300
các món ăn theo cách tôi sử dụng thông tin này trong khách hàng phản ứng của tôi.

559
00:43:45,300 --> 00:43:46,840
Tôi chỉ cần ID món ăn,

560
00:43:46,840 --> 00:43:49,085
và ID món ăn đã có mặt ở đó,

561
00:43:49,085 --> 00:43:55,310
và đó là đủ tốt cho tôi để sử dụng dữ liệu này trong khách hàng phản ứng của tôi.

562
00:43:55,310 --> 00:43:57,685
Vì vậy, tôi sẽ để nó như vậy ở đó.

563
00:43:57,685 --> 00:43:59,530
Tôi sẽ chỉ điền

564
00:43:59,530 --> 00:44:02,910
thông tin tác giả ở đó bởi vì chúng ta cần thông tin tác giả đầy đủ

565
00:44:02,910 --> 00:44:08,930
bất cứ khi nào chúng tôi đưa ra một mục nhận xét trong khách hàng phản ứng của chúng tôi.

566
00:44:08,930 --> 00:44:12,655
Vì vậy, get sẽ được cập nhật như thế này ở đây.

567
00:44:12,655 --> 00:44:22,015
Đối với bài CorsWithOptions,

568
00:44:22,015 --> 00:44:26,070
chúng ta sẽ nói, Authenticate.VerifyUser req, res, tiếp theo.

569
00:44:26,070 --> 00:44:29,540
Rõ ràng, để nhận xét được đăng,

570
00:44:29,540 --> 00:44:38,315
bạn cần tác giả là một người dùng đăng nhập hợp lệ.

571
00:44:38,315 --> 00:44:42,910
Chỉ sau đó, bạn sẽ cho phép người dùng đăng bình luận.

572
00:44:42,910 --> 00:44:49,020
Sau đó, bản thân nhận xét đi kèm trong nội dung của thư yêu cầu đến.

573
00:44:49,020 --> 00:44:51,810
Vì vậy, trước tiên, chúng tôi sẽ kiểm tra cơ thể

574
00:44:51,810 --> 00:44:58,865
để đảm bảo rằng nhận xét được bao gồm trong cơ thể ở đây.

575
00:44:58,865 --> 00:45:03,730
Vì vậy, ở đây, tôi sẽ loại bỏ tất cả các phần này, và sau đó,

576
00:45:03,730 --> 00:45:06,100
đơn giản hóa nó hơn nữa, và sau đó,

577
00:45:06,100 --> 00:45:09,430
chúng tôi sẽ thực hiện điều này một cách chính xác ở đó.

578
00:45:09,430 --> 00:45:17,755
Vì vậy, ngay tại thời điểm này, chúng ta sẽ nói,

579
00:45:17,755 --> 00:45:27,465
nếu req.body không bằng null,

580
00:45:27,465 --> 00:45:35,030
vì vậy có nghĩa là có một nhận xét được kèm theo bên trong cơ thể.

581
00:45:37,380 --> 00:45:45,025
Vì vậy, để tôi cắt nó và chuyển nó vào phần nếu ở đây,

582
00:45:45,025 --> 00:45:47,155
và sau đó, chúng tôi sẽ chỉnh sửa nó ở đây.

583
00:45:47,155 --> 00:45:52,245
Vì vậy, nếu cơ thể không tồn tại,

584
00:45:52,245 --> 00:45:56,140
thì chúng ta sẽ gây ra một lỗi.

585
00:45:56,140 --> 00:46:01,220
Vì vậy, chúng ta sẽ nói, sai lầm mới,

586
00:46:01,500 --> 00:46:08,965
Bình luận không tìm thấy trong cơ thể yêu cầu.

587
00:46:08,965 --> 00:46:12,440
Vì vậy, chúng tôi sẽ nêu ra lỗi này ở đây.

588
00:46:12,450 --> 00:46:16,425
Trạng thái lỗi là 404.

589
00:46:16,425 --> 00:46:20,385
Sau đó, chúng tôi sẽ nói, trả lại lỗi tiếp theo.

590
00:46:20,385 --> 00:46:26,560
Vì vậy, chúng ta hãy xử lý phần lỗi ở đây nếu cơ thể

591
00:46:26,560 --> 00:46:33,280
không chứa thông tin nhận xét thích hợp.

592
00:46:33,280 --> 00:46:35,450
Nếu nó chứa, sau đó, tất nhiên,

593
00:46:35,450 --> 00:46:38,170
những gì chúng ta sẽ làm tiếp theo là,

594
00:46:38,170 --> 00:46:48,310
chúng ta sẽ nói, req.body.author là req.user. _id.

595
00:46:50,420 --> 00:46:55,610
Lý do tại sao chúng tôi làm điều này là chúng tôi nhớ lại rằng nếu nó

596
00:46:55,610 --> 00:46:59,950
là một người dùng đã đăng ký và người dùng đã đăng nhập,

597
00:46:59,950 --> 00:47:03,050
sau đó req.user sẽ chứa thông tin người dùng.

598
00:47:03,050 --> 00:47:07,260
Vì vậy, tôi chỉ cần ID của người dùng đang đăng nhập.

599
00:47:07,260 --> 00:47:10,310
Vì vậy, chúng tôi sẽ nói, req.user. _id, và sau đó,

600
00:47:10,310 --> 00:47:14,645
chúng tôi sẽ thiết lập req.body.author để req.user. _id

601
00:47:14,645 --> 00:47:20,070
Bây giờ, người dùng xác minh sẽ tự động đảm bảo rằng nếu bạn hạ cánh tại thời điểm này,

602
00:47:20,070 --> 00:47:25,710
sau đó bạn rõ ràng sẽ có một người dùng đã đăng nhập chính xác.

603
00:47:25,710 --> 00:47:28,605
Nếu không, điều đó đã gây ra vấn đề ở đó.

604
00:47:28,605 --> 00:47:30,260
Vì vậy, khi bạn đạt được tại thời điểm này,

605
00:47:30,260 --> 00:47:37,660
bạn sẽ có một người dùng hợp lệ đã đăng nhập vào hệ thống trong đó.

606
00:47:37,660 --> 00:47:43,460
Vì vậy, đây là nơi bạn có thể đến bây giờ.

607
00:47:43,460 --> 00:47:46,040
Vì vậy, những gì chúng tôi đang làm là lĩnh vực tác giả,

608
00:47:46,040 --> 00:47:50,625
chúng tôi rõ ràng thiết lập nó vào ID của người dùng ở đây để

609
00:47:50,625 --> 00:47:57,490
req.body chứa các phần còn lại của nhận xét.

610
00:47:57,490 --> 00:48:01,315
Vì vậy, như bạn nhận ra, bình luận chứa đánh giá,

611
00:48:01,315 --> 00:48:04,540
bình luận chính nó, và tác giả, và các lĩnh vực món ăn.

612
00:48:04,540 --> 00:48:11,510
Vì vậy, các phần còn lại nên đã được lấp đầy bởi người dùng.

613
00:48:11,510 --> 00:48:14,730
Đánh giá, nhận xét

614
00:48:14,730 --> 00:48:17,775
và thông tin món ăn nên đã được điền

615
00:48:17,775 --> 00:48:20,840
vào nội dung của tin nhắn yêu cầu đến.

616
00:48:20,840 --> 00:48:23,460
Phần tác giả được để lại không được lấp đầy ở đó,

617
00:48:23,460 --> 00:48:28,380
mà chúng tôi sẽ chèn rõ ràng tại thời điểm này vào cơ thể ở đây.

618
00:48:28,380 --> 00:48:32,515
Vì vậy, bây giờ, req.body sẽ chứa toàn bộ thông tin nhận xét.

619
00:48:32,515 --> 00:48:34,440
Vì vậy, tại thời điểm này,

620
00:48:34,440 --> 00:48:43,400
thay vì làm điều này, chúng ta sẽ nói, bình luận.

621
00:48:44,550 --> 00:48:49,940
Sử dụng req.body, chúng tôi sẽ tạo các ý kiến ở đây.

622
00:48:50,010 --> 00:48:53,304
Sau đó, điều này sẽ trả

623
00:48:53,304 --> 00:48:58,735
lại bình luận tương ứng với bình luận mà chúng tôi vừa chèn vào đây.

624
00:48:58,735 --> 00:49:00,755
Bây giờ, một khi bình luận đã trở lại,

625
00:49:00,755 --> 00:49:07,050
sau đó chúng ta nên làm bình luận. FindByid.

626
00:49:07,050 --> 00:49:09,680
Bây giờ, lý do chúng ta cần làm điều này là vì chúng ta cần

627
00:49:09,680 --> 00:49:13,070
phải điền thông tin tác giả ở đây.

628
00:49:13,780 --> 00:49:18,144
Vì vậy, chúng ta sẽ nói, FindByID bình luận. _id,

629
00:49:18,144 --> 00:49:26,155
và sau đó, chúng tôi sẽ điền thông tin tác giả vào bình luận chính nó.

630
00:49:26,155 --> 00:49:34,610
Sau đó, chúng ta sẽ nói, sau đó bình luận.

631
00:49:36,570 --> 00:49:41,115
Bây giờ, rõ ràng, ở đây, bạn sẽ thấy rằng bình luận sẽ

632
00:49:41,115 --> 00:49:44,880
tồn tại bởi vì chúng tôi chỉ chèn bình luận đó vào vị trí đó.

633
00:49:44,880 --> 00:49:54,470
Vì vậy, ở đây, chúng tôi sẽ chỉ đơn giản là trở lại, res.StatusCode là 200,

634
00:49:54,900 --> 00:50:10,040
res.SeTheader là Content-Type, application/json.

635
00:50:14,610 --> 00:50:18,430
Bản thân nhận xét sẽ nói, res.json, và sau đó,

636
00:50:18,430 --> 00:50:21,745
trả lại nhận xét tại thời điểm này.

637
00:50:21,745 --> 00:50:26,255
Vì vậy, đây là cách chúng tôi sẽ xử lý việc chèn

638
00:50:26,255 --> 00:50:30,805
một nhận xét mới vào phía khách hàng của chúng tôi ở đây.

639
00:50:30,805 --> 00:50:33,925
Đối với đặt, như bạn nhận ra,

640
00:50:33,925 --> 00:50:38,360
bạn sẽ không thể thực hiện một put trên /bình luận/điểm kết thúc.

641
00:50:38,360 --> 00:50:47,610
Vì vậy, chúng ta sẽ nói, PUT hoạt động không được hỗ trợ trên /bình luận/điểm kết thúc.

642
00:50:52,050 --> 00:50:56,180
Đó là vấn đề. Đó là thông điệp mà anh sẽ trở lại.

643
00:50:56,180 --> 00:50:58,570
Vì vậy, StatusCode là 403,

644
00:50:58,570 --> 00:51:02,610
và sau đó, PUT hoạt động không được hỗ trợ trên /bình luận/.

645
00:51:02,610 --> 00:51:05,260
Bây giờ, khi chúng ta xóa,

646
00:51:13,230 --> 00:51:22,840
hãy để tôi cắt nó từ đây, và sau đó, chúng ta sẽ nói,

647
00:51:30,440 --> 00:51:32,835
bình luận.

648
00:51:32,835 --> 00:51:37,710
viết trống. Vì vậy, khi bạn thực hiện một xóa trên điểm cuối nhận xét gạch chéo,

649
00:51:37,710 --> 00:51:40,990
bạn sẽ loại bỏ tất cả các ý kiến từ hệ thống của bạn.

650
00:51:40,990 --> 00:51:43,680
Vì vậy, đây là một hoạt động rất nguy hiểm, và vì vậy,

651
00:51:43,680 --> 00:51:48,990
bạn không nên làm điều này bình thường.

652
00:51:48,990 --> 00:51:53,860
Vì vậy, chúng tôi sẽ chỉ cho phép quản trị viên thực hiện một thao tác như vậy.

653
00:51:53,860 --> 00:51:59,410
Vì vậy, chúng tôi sẽ xóa tất cả các ý kiến từ đó.

654
00:51:59,410 --> 00:52:01,940
Vì vậy, khi bạn nhận được phản ứng,

655
00:52:01,940 --> 00:52:07,700
sau đó chúng tôi sẽ nói res.StatusCode 200.

656
00:52:07,700 --> 00:52:11,080
Vì vậy, để tôi sao chép những phần này ở đây,

657
00:52:12,090 --> 00:52:18,130
và sau đó đến và dán nó vào đây.

658
00:52:18,130 --> 00:52:21,330
Vì vậy, chúng tôi sẽ nói, bình luận.

659
00:52:21,330 --> 00:52:30,480
Sau đó phản ứng res.StatusCode 200 ứng dụng json và sau đó res.json (phản ứng) ở đây.

660
00:52:30,480 --> 00:52:33,100
Vì vậy, đó là cách chúng tôi xử lý việc xóa.

661
00:52:33,100 --> 00:52:37,280
Xóa hoạt động trên điểm cuối nhận xét dấu gạch chéo.

662
00:52:37,280 --> 00:52:43,135
Bây giờ, tuyến đường tiếp theo là bộ định tuyến nhận xét.

663
00:52:43,135 --> 00:52:49,490
Vì vậy, ở đây chúng ta sẽ nói bình luận. Route và

664
00:52:49,490 --> 00:52:56,820
điểm kết thúc ở đây sẽ là dấu gạch chéo CommentID.

665
00:53:01,190 --> 00:53:05,580
Vì vậy, ở đây các tùy chọn sẽ vẫn như vậy.

666
00:53:05,580 --> 00:53:09,760
Sau đó, cho get trên router hiện tại,

667
00:53:09,760 --> 00:53:20,455
cho get chúng ta sẽ nói, bình luận. FindByID (req.params.

668
00:53:20,455 --> 00:53:25,040
Đây sẽ là lời bình luận.

669
00:53:25,380 --> 00:53:31,029
Vì vậy, một khi chúng tôi tìm thấy bình luận cụ thể,

670
00:53:31,029 --> 00:53:37,525
sau đó chúng tôi sẽ cư trú chỉ là tác giả từ đó.

671
00:53:37,525 --> 00:53:39,985
Sau đó, một khi bạn cư tác giả,

672
00:53:39,985 --> 00:53:45,830
sau đó chúng tôi sẽ nói, sau đó bình luận.

673
00:53:47,880 --> 00:53:51,310
Bây giờ, tất cả phần này là không cần thiết ở đây,

674
00:53:51,310 --> 00:53:54,440
vì vậy tôi sẽ chỉ xóa phần này.

675
00:53:54,480 --> 00:54:00,985
Đây cũng không phải là điều thích hợp ở đây.

676
00:54:00,985 --> 00:54:04,540
Vì vậy, để tôi đổi tên mã.

677
00:54:04,540 --> 00:54:08,990
Vì vậy, chúng ta sẽ nói cho nhận bình luận. FindByID,

678
00:54:11,550 --> 00:54:15,385
sau đó cư tác giả,

679
00:54:15,385 --> 00:54:20,365
sau đó bình luận, res.StatusCode là 200, Setheader.

680
00:54:20,365 --> 00:54:22,435
Sau đó, phần còn lại là json.

681
00:54:22,435 --> 00:54:29,960
Chúng tôi sẽ chỉ đơn giản là trả lại các ý kiến ở đây.

682
00:54:39,240 --> 00:54:46,750
Vì vậy, chúng tôi sẽ trả lại bình luận tại thời điểm này, res.json (bình luận).

683
00:54:46,750 --> 00:54:49,340
Bạn sẽ tìm thấy nhận xét cụ thể,

684
00:54:49,340 --> 00:54:52,415
và sau đó trả lại nhận xét đó cho bài đăng.

685
00:54:52,415 --> 00:54:55,185
Đối với sau phẫu thuật, như bạn nhận ra,

686
00:54:55,185 --> 00:54:56,900
sau phẫu thuật không được

687
00:54:56,900 --> 00:55:06,740
phép trên bình luận CommentID.

688
00:55:10,080 --> 00:55:13,805
Vì vậy, đó là thông điệp mà chúng tôi sẽ gửi,

689
00:55:13,805 --> 00:55:19,110
POST hoạt động không được hỗ trợ trên bình luận dấu gạch chéo CommentID.

690
00:55:19,110 --> 00:55:23,640
Vì vậy, đó là thông điệp chúng tôi sẽ nói cho đặt.

691
00:55:23,640 --> 00:55:33,730
Bây giờ, cho đặt, chúng ta sẽ nói bình luận. Tìm nơi Id (Req.params.Commentid).

692
00:55:34,890 --> 00:55:39,230
Vì vậy, chúng tôi sẽ tìm thấy bình luận ở đó,

693
00:55:40,890 --> 00:55:48,070
và có bình luận, vì vậy cho đặt.

694
00:55:48,070 --> 00:55:50,805
Vì vậy, chúng tôi sẽ tìm thấy bình luận ở đó,

695
00:55:50,805 --> 00:55:53,400
và sau đó chúng tôi sẽ nói cho các ý kiến.

696
00:55:53,400 --> 00:55:55,305
Vì vậy, nếu chúng ta tìm thấy bình luận,

697
00:55:55,305 --> 00:56:07,080
nếu bình luận không phải là null,

698
00:56:07,080 --> 00:56:19,455
sau đó chúng tôi cũng sẽ kiểm tra nếu bình luận.

699
00:56:19,455 --> 00:56:32,625
Nếu không, comment.arthur bằng (req.user. _id).

700
00:56:32,625 --> 00:56:38,095
Vì vậy, chúng tôi đang kiểm tra chéo để đảm

701
00:56:38,095 --> 00:56:43,755
bảo rằng bình luận .author là giống như người dùng hiện tại.

702
00:56:43,755 --> 00:56:50,950
Chỉ người dùng hiện tại đã đăng nhập- nếu người dùng giống như tác giả nhận xét,

703
00:56:50,950 --> 00:56:53,760
thì người dùng sẽ được phép cập nhật.

704
00:56:53,760 --> 00:56:57,190
Vì vậy, đó là điều đầu tiên mà chúng tôi sẽ kiểm tra.

705
00:56:57,190 --> 00:57:01,900
Vì vậy, bình luận, sau đó bình luận. author.equal to rec.user. _id

706
00:57:01,900 --> 00:57:07,860
Nếu không, sau đó bạn sẽ nói rằng bạn không được phép cập nhật bình luận này.

707
00:57:07,860 --> 00:57:10,859
Như bạn thấy .403,

708
00:57:10,859 --> 00:57:13,090
và sau đó trả lại lỗi tiếp theo ở đây.

709
00:57:13,090 --> 00:57:16,705
Vì vậy, chúng tôi sẽ tạo ra lỗi ở đó.

710
00:57:16,705 --> 00:57:21,800
Sau đó, sau đó chúng ta sẽ nói

711
00:57:29,910 --> 00:57:36,860
req.body.author, req.user. Điều

712
00:57:40,010 --> 00:57:42,215
đó rất quan trọng.

713
00:57:42,215 --> 00:57:45,580
Bây giờ, hai điều này không cần thiết ở đây,

714
00:57:45,580 --> 00:57:51,385
bởi vì chúng tôi đang trực tiếp lưu bình luận.

715
00:57:51,385 --> 00:58:05,980
Sau đó thuốc, chúng tôi sẽ nói bình luận .FindbyidanDupdate,

716
00:58:05,980 --> 00:58:14,965
và Req.params.Commentid.

717
00:58:14,965 --> 00:58:18,395
Vì vậy, chúng tôi sẽ tìm thấy rằng bình luận cụ thể,

718
00:58:18,395 --> 00:58:21,925
bởi vì chúng tôi đã được cung cấp ID nhận xét.

719
00:58:21,925 --> 00:58:27,205
Vì vậy, chúng tôi sẽ làm ý kiến findByID req.params.Commentid.

720
00:58:27,205 --> 00:58:30,260
Sau đó, chúng tôi sẽ nói sau đó (bình luận).

721
00:58:32,730 --> 00:58:38,705
Khi bạn cung cấp Req.params.Commentid,

722
00:58:38,705 --> 00:58:42,275
chúng tôi sẽ phải cung cấp một cách rõ ràng tham số thứ hai,

723
00:58:42,275 --> 00:58:45,825
đó là những gì chúng tôi muốn thay đổi.

724
00:58:45,825 --> 00:58:52,285
Vì vậy, chúng ta sẽ nói $set: req.body.

725
00:58:52,285 --> 00:58:54,970
Vì vậy, tham số thứ hai, về cơ bản,

726
00:58:54,970 --> 00:58:58,740
cho bạn biết phần nào bạn đang thay đổi.

727
00:58:58,740 --> 00:59:03,710
Bây giờ, kể từ khi chúng tôi đã được cung cấp cơ thể chứa bình luận cập nhật,

728
00:59:03,710 --> 00:59:09,140
chúng tôi sẽ chỉ cập nhật toàn bộ bình luận chính nó.

729
00:59:09,510 --> 00:59:18,205
Sau đó, phần còn lại chúng tôi sẽ yêu cầu là mới: đúng.

730
00:59:18,205 --> 00:59:23,240
Vì vậy, điều này sẽ đảm bảo rằng các bình luận Cập Nhật sẽ được trả lại trong

731
00:59:23,240 --> 00:59:29,815
den của cuộc gọi này để bình luận. FindByidanDupdate.

732
00:59:29,815 --> 00:59:32,565
Vì vậy, chúng tôi sẽ nói sau đó ý kiến.

733
00:59:32,565 --> 00:59:35,214
Khi nhận xét đó được trả lại,

734
00:59:35,214 --> 00:59:38,440
sau đó chúng tôi sẽ nói bình luận. FindByid (bình luận. _id).

735
00:59:46,200 --> 00:59:51,460
Sau đó cư tác giả ở đó.

736
00:59:51,460 --> 00:59:53,785
Chúng tôi sẽ cư tác giả ở đó,

737
00:59:53,785 --> 00:59:58,490
và sau đó chúng tôi sẽ nói sau đó bình luận.

738
00:59:58,700 --> 01:00:09,680
Vì vậy, bạn thấy rằng chúng tôi sẽ có được nhận xét và sau đó trả lại bình luận tại thời điểm này.

739
01:00:09,680 --> 01:00:13,095
Vì vậy, đó là cách chúng tôi sẽ cập nhật bình luận.

740
01:00:13,095 --> 01:00:17,395
Vì vậy, đây là tình huống mà bình luận không phải là null.

741
01:00:17,395 --> 01:00:20,625
Vì vậy, điều này nếu tuyên bố cho nhận xét không phải là null.

742
01:00:20,625 --> 01:00:23,785
Vì vậy, người khác nếu một phần,

743
01:00:23,785 --> 01:00:29,020
bây giờ điều này là không áp dụng,

744
01:00:29,020 --> 01:00:33,325
vì vậy chúng tôi sẽ nói khác, lỗi.

745
01:00:33,325 --> 01:00:35,470
Lỗi trong trường hợp này.

746
01:00:35,470 --> 01:00:37,825
Vì vậy, nếu bình luận là null,

747
01:00:37,825 --> 01:00:40,850
điều đó có nghĩa là chúng tôi không tìm thấy bình luận trong đó,

748
01:00:40,850 --> 01:00:43,650
vì vậy bạn không thể sửa đổi một bình luận không tồn tại.

749
01:00:43,650 --> 01:00:44,805
Vì vậy, chúng tôi sẽ nói sai lầm,

750
01:00:44,805 --> 01:00:54,700
mới nhận xét lỗi req.params.CommentID không tìm thấy và sau đó chúng tôi sẽ trả lại lỗi.

751
01:00:54,700 --> 01:01:01,255
Vì vậy, đó là cách chúng tôi sẽ xử lý phần đặt của nhận xét của chúng tôi ở đây,

752
01:01:01,255 --> 01:01:04,099
và sau đó cuối cùng là xóa.

753
01:01:06,120 --> 01:01:11,130
Để xóa, một lần nữa chúng ta sẽ phải tìm

754
01:01:11,130 --> 01:01:12,900
bình luận đầu tiên. FindByid (Req.params.Commentid)

755
01:01:12,900 --> 01:01:25,720
và sau đó bình luận.

756
01:01:25,720 --> 01:01:28,150
Vì vậy, chúng tôi sẽ tìm kiếm nhận xét.

757
01:01:28,150 --> 01:01:34,160
Vì vậy, trước tiên chúng ta sẽ kiểm tra xem bình luận không bằng null.

758
01:01:36,180 --> 01:01:39,955
Điều đó rất quan trọng để kiểm tra ở đây.

759
01:01:39,955 --> 01:01:50,990
Sau đó, phần tiếp theo chúng tôi sẽ kiểm tra là nếu bình luận. Tác giả bằng req.user. _id

760
01:01:58,830 --> 01:02:03,400
Chúng tôi đảm bảo rằng người dùng này đang cố gắng để xóa

761
01:02:03,400 --> 01:02:08,060
nhận xét này là chính xác cùng một người dùng chèn nhận xét ở nơi đầu tiên.

762
01:02:08,060 --> 01:02:10,750
Nếu không, vì vậy nếu đây là tình huống,

763
01:02:10,750 --> 01:02:13,920
sau đó bạn sẽ thấy 'Bạn không được phép xóa nhận xét này! '

764
01:02:13,920 --> 01:02:16,365
Và sau đó trả lại trạng thái ở đó.

765
01:02:16,365 --> 01:02:20,920
Sau đó, dưới đây,

766
01:02:20,920 --> 01:02:41,310
chúng tôi sẽ nói bình luận. FindByidandRemove đây.

767
01:02:41,310 --> 01:02:48,750
Vì vậy, chúng tôi sẽ nói bình luận .findbyidandRemove (Req.params.Commentid),

768
01:02:48,750 --> 01:02:54,035
sau đó chúng tôi sẽ nhận được một số phản ứng từ nhận xét.

769
01:02:54,035 --> 01:02:55,630
Vì vậy, tại thời điểm này,

770
01:02:55,630 --> 01:02:59,830
chúng tôi sẽ chỉ đơn giản là nói, res.StatusCode.

771
01:02:59,830 --> 01:03:05,365
Vì vậy, chúng tôi sẽ nói bình luận. FindByidandRemove sau đó phản ứng.

772
01:03:05,365 --> 01:03:07,210
Nếu nó được gỡ bỏ một cách chính xác,

773
01:03:07,210 --> 01:03:10,915
chúng tôi sẽ nói 200 và sau đó res.json

774
01:03:10,915 --> 01:03:17,260
phản ứng ở đây và chúng tôi cũng sẽ bắt gặp lỗi tại thời điểm này.

775
01:03:17,260 --> 01:03:25,195
Vì vậy, để tôi chỉ cần sao chép điều đó ở đây và sau đó chúng tôi sẽ bao gồm việc bắt lỗi tại thời điểm này.

776
01:03:25,195 --> 01:03:28,895
Vì vậy, đó là điều đầu tiên mà chúng tôi sẽ kiểm tra.

777
01:03:28,895 --> 01:03:33,500
Chúng tôi sẽ đảm bảo rằng bình luận không bằng null.

778
01:03:33,630 --> 01:03:38,360
Nếu không, vì vậy đây là phần khác.

779
01:03:39,810 --> 01:03:44,170
Vì vậy, đây là phần khác của nếu khác lỗi

780
01:03:44,170 --> 01:03:48,040
mới bình luận req.params.CommentID không tìm thấy và sau đó

781
01:03:48,040 --> 01:03:56,220
404 và gửi phần khác cho chúng tôi và sau đó phần sau đó sẽ xử lý một cách thích hợp.

782
01:03:56,220 --> 01:04:01,460
Vì vậy, đây là những thay đổi mà chúng tôi thực hiện cho bộ định tuyến nhận xét ở đây.

783
01:04:01,460 --> 01:04:05,025
Vì vậy, chúng tôi đang xử lý bài get put và xóa cho

784
01:04:05,025 --> 01:04:10,330
các nhận xét dấu gạch chéo và điểm dấu gạch chéo ý kiến dấu gạch chéo ý kiến tác động.

785
01:04:10,330 --> 01:04:12,495
Vì vậy, một khi chúng tôi đã hoàn thành điều này,

786
01:04:12,495 --> 01:04:17,500
sau đó chúng ta cần phải bao gồm điều này vào tập tin app.js.

787
01:04:17,500 --> 01:04:27,345
Vì vậy, chúng tôi sẽ đi vào các tập tin app.js và sau đó chúng tôi sẽ nói

788
01:04:27,345 --> 01:04:30,070
var bình luận

789
01:04:31,130 --> 01:04:42,280
yêu cầu Routes/bình luận.

790
01:04:42,280 --> 01:04:45,960
Vì vậy, chúng tôi có bộ định tuyến bình luận ở đây và sau đó chúng tôi sẽ đi

791
01:04:45,960 --> 01:04:49,390
xuống vào tập tin app.js xuống dưới đây và

792
01:04:49,390 --> 01:04:54,610
sau đó chúng tôi sẽ nói app.use

793
01:04:55,040 --> 01:05:04,695
dấu gạch chéo ý kiến, bình luận ở đây.

794
01:05:04,695 --> 01:05:07,365
Đó là nó. Vì vậy, bây giờ,

795
01:05:07,365 --> 01:05:09,390
bộ định tuyến nhận xét của tôi đã sẵn sàng.

796
01:05:09,390 --> 01:05:12,935
Vì vậy, chúng ta hãy tiếp tục và lưu tất cả các thay đổi.

797
01:05:12,935 --> 01:05:19,020
Sau đó, máy chủ của chúng tôi bây giờ được cập nhật

798
01:05:19,020 --> 01:05:24,420
để xử lý tất cả các yêu cầu từ khách hàng React của chúng tôi ở đây.

799
01:05:24,420 --> 01:05:27,800
Bây giờ, nếu bạn muốn làm theo cách khác, đó là,

800
01:05:27,800 --> 01:05:34,120
bạn có ý kiến của bạn như là tài liệu phụ của món ăn của bạn và sau đó bạn muốn xử lý điều

801
01:05:34,120 --> 01:05:37,680
đó, sau đó bạn sẽ cần phải cập nhật các khách hàng React

802
01:05:37,680 --> 01:05:42,185
để có thể sử dụng các ý kiến từ bên trong mỗi món ăn một cách thích hợp.

803
01:05:42,185 --> 01:05:44,830
Điều đó sẽ được để lại như một bài tập cho bạn.

804
01:05:44,830 --> 01:05:48,920
Hãy suy nghĩ về cách bạn sẽ thiết kế khách hàng phản ứng của bạn để nó

805
01:05:48,920 --> 01:05:53,465
hoạt động rất tốt với phiên bản trước

806
01:05:53,465 --> 01:06:03,735
của máy chủ mà có nhận xét như là tài liệu phụ của món ăn của mình.

807
01:06:03,735 --> 01:06:07,065
Bây giờ, đó sẽ là một cách thú vị để thực hiện nó.

808
01:06:07,065 --> 01:06:10,480
Tất nhiên, nó phức tạp hơn một chút so với cách chúng tôi

809
01:06:10,480 --> 01:06:14,965
thực hiện React khách hàng nơi chúng tôi giữ ý kiến độc lập của

810
01:06:14,965 --> 01:06:20,840
các món ăn nhưng sau đó công việc bổ sung là trách nhiệm

811
01:06:20,840 --> 01:06:22,910
của phía khách hàng bởi vì bạn cần phải chọn

812
01:06:22,910 --> 01:06:26,765
các ý kiến thích hợp khi bạn đang hiển thị món ăn cụ thể.

813
01:06:26,765 --> 01:06:30,370
Bạn cần phải chọn các ý kiến từ tất cả các ý kiến ở đây.

814
01:06:30,370 --> 01:06:35,170
Vì vậy, đó là một công việc bổ sung mà khách hàng React của chúng tôi thực hiện vì

815
01:06:35,170 --> 01:06:40,680
thực tế là chúng tôi tách các ý kiến từ các món ăn mình.

816
01:06:40,680 --> 01:06:46,165
Tương tự, nếu bạn có thể thiết kế lại khách hàng góc cạnh của bạn để có thể

817
01:06:46,165 --> 01:06:51,775
đối phó với tình huống mà các ý kiến được giữ độc lập với các món ăn của bạn.

818
01:06:51,775 --> 01:06:56,020
Bây giờ, đây là tất cả các bài tập mà bạn có thể làm để xem làm thế nào bạn có thể

819
01:06:56,020 --> 01:07:01,210
mở rộng ứng dụng khách hàng của bạn để xử lý bất kỳ loại máy chủ,

820
01:07:01,210 --> 01:07:04,430
hai loại máy chủ khác nhau ở đó.

821
01:07:04,860 --> 01:07:11,480
Vì vậy, với điều này, chúng tôi hoàn thành bản cập nhật cho máy chủ của chúng tôi ở đây.

822
01:07:11,480 --> 01:07:15,040
Vì vậy, với điều này, chúng tôi đã cập nhật mọi thứ ở phía máy chủ.

823
01:07:15,040 --> 01:07:17,890
Vì vậy, chúng ta hãy lưu tất cả các thay đổi ở phía máy chủ.

824
01:07:17,890 --> 01:07:26,755
Vì vậy, bây giờ, máy chủ của chúng tôi đã sẵn sàng để xử lý các yêu cầu đến từ khách hàng React của chúng tôi.

825
01:07:26,755 --> 01:07:29,340
Với điều này, chúng tôi hoàn thành bài tập này.

826
01:07:29,340 --> 01:07:33,300
Trong bài tập này, chúng tôi đã chuẩn bị máy chủ nhanh của chúng tôi

827
01:07:33,300 --> 01:07:38,985
để xử lý các yêu cầu đến từ khách hàng React của chúng tôi.

828
01:07:38,985 --> 01:07:43,190
Trong bài tập tiếp theo, chúng ta sẽ xem xét phản ứng khách hàng chi tiết hơn để

829
01:07:43,190 --> 01:07:48,000
hiểu làm thế nào nó được giao tiếp với máy chủ bổ sung này.

830
01:07:48,000 --> 01:07:50,640
Đây là thời điểm tốt để bạn thực hiện

831
01:07:50,640 --> 01:07:55,880
một bảo hiểm git với thông điệp tích hợp khách hàng và máy chủ.