Chúng tôi đã phát triển một máy chủ REST API đầy đủ
sử dụng Express và MongoDB như một phần của khóa học này.
Để 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
tôi, chúng tôi sẽ thực hiện một vài điều chỉnh nhỏ
để nó trả về đúng loại dữ liệu để
thực hiện khách hàng của chúng tôi có thể hoạt động
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.
Vì vậy, để làm điều đó, chúng
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.
Trước khi bạn bắt đầu bài tập này,
tôi giả sử rằng bạn chưa thực hiện
bài học trước đó về tích hợp khách hàng góc cạnh và
máy chủ bởi vì bạn đang làm bài học này đi qua chuyên môn React.
Vì vậy, những thay đổi mà tôi sẽ thực hiện cho máy chủ sẽ giả
đị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 đó.
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,
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
trong bài tập này để bạn có thể bỏ qua phần thay đổi đó.
Đi vào máy chủ của chúng tôi trong trình soạn thảo.
Trước khi chúng tôi bắt đầu làm việc trên máy chủ,
tôi sẽ đề nghị bạn tải xuống tất cả các hình ảnh mà tôi đã
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.
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 đó
vào thư mục hình ảnh công cộng trong máy chủ của chúng tôi.
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
đã bởi vì máy chủ của chúng tôi là một trong đó sẽ
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.
Tiếp theo, chúng tôi đi đến CORS và điều chỉnh danh sách trắng ở đây.
Vì vậy, đối với ứng dụng khách hàng React của
chúng tôi, nếu chúng tôi bắt đầu với lệnh start sợi,
nó chạy ở tên máy tính của bạn: 3001.
Vì vậy, bất kỳ yêu cầu nào đến từ vị trí của chúng tôi đến
máy chủ sẽ mang nó như là nguồn gốc ở đó.
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 để
bất kỳ vấn đề CORS sẽ được giải quyết tự động.
Vì vậy, đi vào tập tin cors.js trong danh sách trắng của tôi ở đây,
hãy để tôi thêm vào
tên máy tính http://my: 3001 và đây là
nguồn gốc mà từ đó khách hàng của tôi
sẽ có nguồn gốc các yêu cầu đến máy chủ này.
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.
Tiếp theo, chúng ta cần cập nhật một vài tuyến đường để
xử lý các tham số truy vấn và cũng là một vài điều chỉnh nhỏ khác.
Hãy để tôi bắt đầu với các tập tin promoRouter.js.
Điều đó rất đơn giản để có được cập nhật.
Vì vậy, đi vào tập tin promoRouter.js,
trong tập tin Promorouter cho yêu cầu get mà chúng tôi nhận được
ở đâ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,
ở đâ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,
điều tương tự với router lãnh đạo cũng.
Vì vậy, hãy để tôi đi đến tập tin leaderRouter.js.
Trong bộ định tuyến lãnh đạo cũng,
ở đây nơi bạn tìm thấy Leaders.Find với đối tượng JavaScript trống
thay vì thay thế với req.query để các tham số truy vấn sẽ được thông qua.
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.
Bây giờ, sau khi điều chỉnh hai,
bây giờ chúng ta hãy làm việc trên bộ định tuyến đĩa.
Vì vậy, đi vào tập tin dishRouter.js,
ngay cả trong bộ định tuyến đĩa cũng cập nhật tương tự ở đây.
Vì vậy, đi vào món ăn này.Find trong phương pháp get ở đây,
thay đổi đó để req.query.
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.
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
và bộ định tuyến món ăn,
sau đó chúng tôi sẽ tiếp tục cập nhật bộ định tuyến yêu thích.
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.
Bây giờ, trong bộ định tuyến yêu thích,
bạn sẽ thấy rằng đối với bộ định tuyến yêu thích,
tôi không cho bạn thấy phần còn lại bởi vì
bạn nên làm như một phần của nhiệm vụ của bạn.
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.
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
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.
Vì vậy, thay vì chỉ đơn giản là nói getoperation.supported,
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,
favorites.findone và chúng ta sẽ nói người dùng: req.user.
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 đó
yêu thích và bắt lỗi tiếp theo.
Sau đó, tương tự ở đây, chúng tôi sẽ thêm trong err ở đây, err tiếp theo ở đây.
Vì vậy, bên trong điều này sau đó,
khi chúng tôi nhận được yêu thích,
sau đó chúng tôi sẽ kiểm tra nếu không yêu thích.
Vì vậy, nếu không có mục yêu thích cho
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,
vì vậy chúng tôi sẽ trả lại res.StatusCode 200,
Setheader, Content-Type,
ứng dụng/json và sau đó chúng tôi sẽ trở lại nói tồn tại sai.
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,
đ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.
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
tôi, Tôi sẽ thiết lập có tồn tại cờ để sai.
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
tồn tại nên được tự động sai tại thời điểm này.
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.
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.
Nếu không, do đó, có nghĩa là yêu thích không phải là null,
vì vậy chúng tôi sẽ nói nếu favorites.dishes.indexof.
Vì vậy, chúng ta sẽ tìm kiếm Req.params.Dishid.
Vì vậy, chúng ta sẽ tìm kiếm món ăn yêu thích này mảng để
xem nếu món ăn này tồn tại trong đó và nếu nó không tồn tại,
rõ ràng điều này sẽ trả lại một chỉ số tiêu cực ở đây.
Trong trường hợp đó cũng,
tôi sẽ trả lại chính xác giống như ở đây.
Vì vậy, nếu nó trả về một chỉ số tiêu cực thì điều đó có nghĩa là
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,
món ăn cụ thể này không tồn tại trong
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.
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.
Vì vậy, trong trường hợp này,
tôi sẽ trả lại mã trạng thái 200 tồn tại là đúng.
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
/Favorites/dishid nơi món ăn Id được cung cấp như là tham số ở đây,
như tham số yêu cầu ở đây,
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.
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.
Tương tự, nếu các mục yêu thích tồn tại nhưng
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,
nếu không chúng tôi sẽ trả lại true.
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à
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.
Ngoài ra trong khi chúng tôi đang ở trong mục yêu thích,
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,
chúng tôi muốn có thể cư trú thông tin người dùng và món ăn,
mục yêu thích, trước khi chúng tôi trở lại.
Ví dụ, trong bài viết mà chúng tôi làm,
khi chúng tôi lưu các mục yêu thích sau đó tại thời điểm này,
chúng tôi muốn đầu tiên làm mục yêu thích.
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
và chúng tôi sẽ cư trú cả người dùng và cũng
cư trú các món ăn trong mục yêu thích.
Sau đó, khi các mục yêu thích được trả lại,
chúng tôi sẽ trả lại mục yêu thích đó thay vào đó.
Vì vậy, để tôi thực hiện thay đổi này ở đây.
Vì vậy, chúng tôi sẽ cắt ra từ đây và sau đó bên trong sau đó,
chúng tôi sẽ trả lại các mục yêu thích.
Sau khi chúng tôi lưu các mục yêu thích,
sau đó chúng tôi sẽ tìm kiếm nó,
cho FavoriteByID và sau
đó 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.
Thay đổi này chúng ta nên thực hiện.
Nếu bạn đã thực hiện điều này trong mục yêu thích của mình,
thì bạn không cần phải thực hiện thay đổi này.
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,
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
vì khách hàng React của chúng tôi mong đợi điều này sẽ có mặt ở đó.
Bây giờ, cùng một loại thay đổi,
chúng ta sẽ cần phải làm cho biến b, lưu các thay đổi.
Vì vậy, trong bài viết ở đây,
chúng tôi sẽ thực hiện một thay đổi để điều đó,
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 đó.
Tương tự như vậy, dưới id món ăn,
cũng trong bài đăng,
bạn sẽ tương tự, bất cứ khi nào bạn thực hiện thay đổi yêu thích,
đầ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ó,
và sau đó tương tự trong phần khác.
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.
Vì vậy, thực hiện thay đổi bổ sung này nơi bạn sẽ cư trú
người dùng và các món ăn trước khi bạn trả về giá trị.
Ngoài ra với việc xóa,
chúng tôi sẽ thực hiện các thay đổi tương tự ở đây.
Vì vậy, bạn nhận thấy rằng trong xóa,
tôi đã thực hiện thay đổi này ở đây.
Vì vậy, sau khi chúng tôi lưu các thay đổi vào mục yêu thích,
sau đó chúng tôi sẽ tìm kiếm các mục yêu thích và sau đó
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.
Đây là những gì khách hàng React của chúng tôi mong đợi chúng tôi làm.
Vì vậy, ngay cả đối với việc xóa,
chúng tôi sẽ thực hiện các thay đổi tương tự.
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
vì vậy chúng tôi sẽ tiến hành cập nhật users.js tiếp theo.
Cuối cùng, chúng tôi sẽ cập nhật tệp users.js.
Bây giờ, trong tập tin users.js chúng ta cần phải thêm vào một
lĩnh vực router.options khác ở đây,
bởi vì đôi khi một yêu cầu bài đăng như bạn đã thấy
với đăng nhập sẽ gửi các tùy chọn đầu tiên để kiểm tra,
đặc biệt là với xe ô tô, cho dù yêu cầu bài đăng sẽ được cho phép.
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 đó
chúng tôi sẽ chỉ đơn giản
là trả về một thông báo trạng thái
của 200 để đáp ứng với điều đó.
Đố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,
chúng tôi sẽ chỉ đơn giản trả lại trạng thái 200 ở đây.
Bây giờ chức năng đăng nhập mà chúng tôi đã thực hiện trước đó,
chúng tôi đã chỉ đơn giản là thực hiện passport.authenticate
địa phương ở đây và chúng tôi đã kiểm tra cho các giá trị còn lại ở đây.
Bây giờ, passport.authenticate địa phương này,
nếu người dùng không nhận được chứng thực,
nó chỉ đơn giản là trả về một trái phép trong thư trả lời.
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,
vì vậy đó là lý do tại sao chúng tôi sẽ tăng cường
phương pháp đăng nhập bài bộ định tuyến này để
xác thực sẽ trả lại thông tin có ý nghĩa hơn tại thời điểm này.
Vì vậy, để làm điều đó,
chúng tôi sẽ không được làm passport.authenticate ở đây,
thay vào đó chúng tôi sẽ mất.
Vì vậy, hãy để tôi loại bỏ điều đó từ đó và sau đó bạn sẽ thấy
làm thế nào tôi sẽ cập nhật bài đăng bộ định tuyến ở đây.
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,
res và tiếp theo ở đây.
Bên trong req này, res và tiếp theo ở đây,
passport.authenticate sẽ gọi này với địa phương.
Bây giờ, khi chúng ta gọi điều này với địa phương,
nếu lỗi xác thực xảy ra,
passport.authenticate có thể được thực hiện để trả về
giá trị lỗi và nó cũng sẽ trả về người dùng nếu
không có lỗi và một tham số thứ ba được gọi là thông tin
đó sẽ mang thông tin bổ sung có thể được phân tích trở lại người dùng.
Lỗi này sẽ được trả lại khi
có lỗi chính hãng xảy ra trong passport.authenticate.
Nhưng nếu thông tin người dùng
được gửi vào passport.authenticate nhưng người dùng không tồn tại,
thì thông tin đó không được tính là lỗi.
Thay vào đó, nó sẽ được tính là người dùng không tồn tại và
thông tin đó được phân tích lại trong đối tượng thông tin đi kèm.
Vì vậy, lỗi sẽ được trả lại khi có
một lỗi chính hãng xảy ra trong quá trình xác thực,
nhưng thông tin sẽ chứa thông tin nếu người dùng không tồn tại.
Vì vậy, passport.authenticate đang truyền lại một thông báo nói rằng
người dùng không tồn tại hoặc tên người dùng
là không chính xác hoặc mật khẩu là không chính xác và như vậy.
Vì vậy, thông tin đó sẽ được thông qua trong thông báo thông tin.
Bây giờ chúng ta sẽ thấy làm thế nào điều này là hữu ích cho
chúng tôi khi chúng ta nhìn vào phía khách hàng một chút sau đó.
Vì vậy, trong tình huống này,
chúng tôi sẽ xử lý điều này như sau,
và không chỉ rằng khi chúng tôi gọi passport.authenticate này,
chúng tôi cũng cần phải vượt qua trong một req,
res, tiếp theo là ba tham số cho nó.
Vì vậy, đây là cấu trúc khi bạn cần phải gọi passport.authenticate và mong đợi nó để
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,
vì vậy bạn cũng cần phải cung cấp req này, res,
tiếp theo ngay có quá.
Bây giờ, nếu điều này xảy ra,
vì vậy chúng tôi sẽ nói nếu err,
vì vậy nếu có một lỗi xảy ra,
chúng tôi sẽ nói trở lại err tiếp theo và sau đó để cho
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 đó.
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.
Vì vậy, nếu chúng ta đã đạt đến thời điểm này,
thì điều đó có nghĩa là nó không phải là một lỗi xảy ra
nhưng thay vào đó có lẽ người dùng không thể được tìm thấy.
Nếu người dùng không được tìm thấy,
thì người dùng ở đây sẽ được đặt thành null trong trường hợp này.
Vì vậy, trong tình huống đó,
nếu người dùng không tồn tại,
thì chúng ta cần có khả năng truyền thông tin về phía máy chủ.
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.
Vì vậy, tôi sẽ cắt điều này ra từ đây và
sau đó dán nó vào đây và sau đó chúng tôi sẽ chỉnh sửa này.
Vì vậy, nếu người dùng là null,
sau đó chúng tôi sẽ gửi lại một mã trạng thái là 401 có nghĩa là
trái phép và sau đó chúng tôi sẽ gửi lại thông tin thành công sai,
và sau đó chúng tôi sẽ không được chuyển trở lại mã thông báo,
chúng tôi sẽ vượt qua thông báo trạng thái.
Vì vậy, ở đây chúng ta sẽ nói
'Đăng nhập không thành công' và sau đó thông tin thứ ba,
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à
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.
Vì vậy, cờ thành công sẽ được đặt thành false,
trạng thái sẽ được đặt Đăng nhập không thành công và
thông tin lỗi được thông qua trong thông tin sẽ được thông qua trở lại.
Bây giờ, lưu ý rằng tình huống này sẽ xảy ra nếu
tên người dùng và mật khẩu là không chính xác,
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à
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.
Vì vậy, thông tin đó sẽ được mã hóa vào thông tin đi kèm và do đó tôi sẽ
vượt qua trở lại như là một lỗi cho phía khách hàng của tôi.
Phần khác
được xử lý như Req.login.
Vì vậy, nếu điều này là thành công,
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.
Vì vậy, tại thời điểm này,
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.
Vì vậy, ở đây, nếu chúng ta đã đạt đến thời điểm này,
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,
do đó có nghĩa là người dùng có thể đăng nhập.
Vì vậy, chúng tôi sẽ nói sai lầm,
chúng tôi sẽ cố gắng đăng nhập người dùng.
Vì vậy, chúng tôi sẽ nói nếu sai lầm và
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.
Vì vậy, trong trường hợp này, nếu lỗi,
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
là sai và trạng thái là Đăng nhập không thành công,
và sau đó thông tin lỗi,
thay vì thông tin,
chúng tôi sẽ vượt qua trong 'Không thể đăng nhập người dùng”.
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.
Nếu không, chúng ta sẽ xuống dưới đây.
Vì vậy, tại thời điểm này,
chúng tôi sẽ có thể tạo ra mã thông báo.
Vì vậy, nếu chúng ta đã đạt đến thời điểm này, điều
đó có nghĩa là người dùng đã đăng nhập thành công,
và vì vậy bây giờ chúng ta có thể tạo ra mã thông báo.
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,
và sau đó chúng tôi sẽ chuyển lại mã thông báo trở lại cho người dùng.
Vì vậy, ở đây, chúng ta sẽ nói var token,
và sau đó chúng ta có thể nói res.StatusCode là 200 và sau đó res.json thành công đúng,
vì vậy, có nghĩa là người dùng đăng nhập thành công.
Vì vậy, trạng thái sẽ được đăng nhập thành công.
Sau đó, phần thứ ba,
thay vì lỗi,
tôi sẽ chuyển mã thông báo trở lại cho người dùng.
Vì vậy, chúng ta sẽ nói mã thông báo, mã
thông báo này mà chúng ta vừa thu được trước đó.
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.
Vì vậy, ở đây, nhận thấy rằng sự thành công được đặt thành true, do
đó, có nghĩa là người dùng đăng nhập thành công,
và do đó người dùng có thể tiến hành thêm vào thời điểm này.
Điều này phải được thực hiện bên trong Req.login ở đây.
Vì vậy, tại thời điểm này,
chúng tôi sẽ đóng Req.login.
Vì vậy, chú ý rằng đây là bên trong Req.login này ở đây.
Vì vậy, trong đó, chúng ta sẽ vượt qua ba thứ này.
Vì vậy, để tôi chỉ thụt lề ba dòng này vào.
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.
Vì vậy, một lần nữa, xem xét lại mã này một lần nữa.
Vì vậy, chúng tôi sẽ làm bài router,
nhưng thay vì làm hộ chiếu xác thực ngay tại đó,
chúng tôi sẽ nói req, res,
tiếp theo, và sau đó bên trong đây,
chúng tôi sẽ làm một hộ chiếu xác thực cho địa phương,
và xác thực này sẽ vượt qua trở lại.
Vì vậy, chúng ta có thể cung cấp một hàm callback để điều đó,
và hàm callback này sẽ trả về một trong hai lỗi,
người dùng, hoặc thông tin ở đây.
Vì vậy, nếu nó là một lỗi,
chúng tôi sẽ chỉ cho phép trình xử lý lỗi thể hiện để chăm sóc điều đó.
Nếu người dùng là null,
thì điều đó có nghĩa là đăng nhập người dùng không thành
công và lý do cho điều đó sẽ nằm trong thông tin.
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.
Nếu chúng ta đi đến thời điểm này,
thì người dùng được xác minh thành công.
Vì vậy, sau đó chúng tôi sẽ đăng nhập vào người dùng.
Vì vậy, hộ chiếu xác thực,
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.
Vì vậy, chúng ta có thể gọi tên đăng nhập với người dùng.
Nếu điều này trả về một lỗi,
sau đó chúng tôi sẽ trả lại lỗi ở đây một cách thích hợp.
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.
Vì vậy, chúng tôi có thể tạo ra JSON Web Token ở đây và sau đó trả lại
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.
Vì vậy, đó là tập hợp các bước mà chúng ta sẽ sử dụng ở đây.
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à
tôi muốn phân biệt giữa tình huống mà một lỗi chính hãng
xảy ra trong quá trình xác thực như trái ngược với tình
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ệ.
Vì vậy, hai trường hợp đó sẽ được xử lý bởi tình huống này,
nơi mà thông tin sẽ mang thông tin về cho chúng tôi.
Vì vậy, đó không phải là một lỗi riêng,
nhưng đó là tình huống mà người dùng
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ệ.
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.
Ngoài ra, tôi sẽ thêm vào
một phương pháp nữa ở đây được gọi là CheckJWTToken.
Nó là khá có thể rằng trong khi khách hàng đã đăng nhập và có được JSON Web Token,
đôi khi sau đó, JSON Web Token có thể hết hạn.
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
máy chủ, thì máy chủ sẽ không thể xác thực người dùng.
Vì vậy, theo khoảng thời gian định kỳ,
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ệ.
Vì vậy, đó là lý do tại sao tôi bao gồm điều này,
một điểm cuối khác được gọi là CheckJWTToken.
Vì vậy, nếu bạn thực hiện một get để CheckJWTToken bằng cách
bao gồm các token vào tiêu đề ủy quyền,
sau đó cuộc gọi này sẽ trả về một true hoặc false
để chỉ cho bạn xem JSON Web Token vẫn còn hợp lệ hay không.
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
người dùng để có được một JSON Web Token mới nếu cần thiết.
Vì vậy, để làm điều này,
chúng ta sẽ nói Cors.CorsWithOptions và req,
res ở đây như mong đợi.
Trong đây, chúng ta sẽ nói
hộ chiếu xác thực jwt
và phiên: false,
và điều này sẽ trả lại err, người dùng, thông tin.
Vì vậy, nhớ lại cách chúng tôi sử dụng hộ chiếu xác thực trước đó.
Vì vậy, chúng tôi gọi JWT với phiên false ở đây.
Vì vậy, trước đó ở đây, chúng tôi nói hộ chiếu xác thực địa phương.
Vì vậy, đây là để xác thực địa phương.
Vì vậy, điều này là để xác thực JSON Web Token.
Vì vậy, khi chúng tôi gọi đó,
sau đó kể từ đó sẽ xác minh JSON Web Token, vì vậy chúng tôi sẽ nói,
nếu err trở lại tiếp theo err,
và sau đó để cho trình xử lý lỗi thể hiện chăm sóc tình huống đó.
Sau đó, chúng ta sẽ nói, nếu không phải là người dùng,
nếu người dùng không tồn tại, thì tương tự như vậy.
Vì vậy, có nghĩa là nếu đối tượng người dùng được
tìm thấy từ JSON Web Token và sau đó được nạp vào req.user,
thì điều đó có nghĩa là người dùng là người dùng hợp lệ,
và do đó có thể được phép tiếp tục.
Nếu không, chúng ta sẽ nói rằng người dùng không tồn tại.
Vì vậy, chúng ta cần thông báo rằng JSON Web Token đã hết hạn.
Vì vậy, tại thời điểm này,
chúng tôi sẽ gửi một res với
một mã trạng thái 401.
Vì vậy, trái phép, SeTheader, Content-Type,
ứng dụng/json, và sau đó chúng tôi sẽ trả lại res.
Res.json sẽ nói trạng thái JWT
không hợp lệ và sau đó,
chúng tôi sẽ trả lại một lá cờ gọi là thành công rơi và sau đó,
chúng tôi sẽ trả lại thông tin mà chúng tôi có được nếu người dùng
không được xác thực là lỗi tại thời điểm này.
Nếu không, điều đó có nghĩa là chúng tôi đã đạt đến thời điểm này,
sau đó người dùng là một người dùng hợp lệ.
Vì vậy, trong trường hợp này,
hãy để tôi chỉ cần sao chép mã đó ở đây,
chúng tôi sẽ gửi một mã trạng thái của 200 và sau đó res.json,
sẽ gửi JWT hợp lệ và thành công là sự thật.
Phần thứ ba, chúng tôi sẽ gửi thông tin của người dùng.
Vì vậy, theo cách đó, khi điểm cuối này được gọi với phương thức get,
sau đó điều này sẽ xác minh cho dù mã thông báo là hợp lệ hay không.
Nếu token là hợp lệ,
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,
bạn có thể kiểm tra xem jsonwebtoken có hợp lệ hay không.
Điều này rất hữu ích ở phía khách hàng.
Bây giờ, hộ chiếu này xác thực ở đây sẽ phải được cung cấp
với req và res như hai tham số ở đây.
Vì vậy, đó là cách chúng tôi gọi là chứng thực hộ chiếu.
Vì vậy, lưu ý rằng bất cứ khi nào bạn gọi
hộ chiếu xác thực và mong đợi chức năng gọi lại này ở đây,
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.
Trong máy chủ API còn lại của chúng
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
hình thành các tài liệu phụ bên trong tài liệu của dishe,
vì vậy họ mua mỗi món ăn kèm theo bộ ý kiến riêng của mình.
Nhưng cách chúng tôi thực hiện khách hàng React của chúng tôi là
như vậy mà các ý kiến được giữ độc lập với các món ăn,
và các ý kiến tự mang ID món ăn tương ứng.
Bây giờ, đây là hai cách khác nhau để
thực hiện phía máy chủ cũng như phía máy khách.
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
tôi, chúng tôi đã sử dụng phương pháp tài liệu phụ để
xử lý nhận xét trong ứng dụng khách Angular của chúng tôi.
Vì vậy, máy chủ API còn lại đã được
thực hiện theo cách mà nó phù hợp hơn cho máy khách Angular.
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,
và sau đó sử dụng ID món ăn bên trong bình luận,
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,
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.
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ủ
để giới thiệu các /comments REST API điểm cuối ở giai đoạn này.
Vì vậy, để làm điều đó,
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.
Vì vậy, đi vào các mô hình,
hãy để tôi thực hiện một tập tin mới có tên comments.js.
Trong tập tin comments.js,
chúng tôi sẽ di chuyển CommentSchema từ tập tin dishes.js
vào tập tin comments.js và sau đó loại bỏ nó hoàn toàn từ tập tin dishes.js.
Nhưng trước khi chúng ta làm điều đó,
chúng ta cần sao chép các mongoose và giản đồ từ đây,
vì vậy hãy để tôi chỉ sao chép điều này từ dishes.js vào comment.js.
Sau đó, đi vào dishes.js,
hãy để tôi cắt CommentSchema này hoàn toàn ra khỏi đây,
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.
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.
Nhưng tất nhiên đây không phải là hoàn chỉnh,
chúng tôi sẽ cập nhật CommentSchema một chút.
Nhưng trước khi chúng tôi làm điều đó,
quay trở lại tập tin dishes.js và trong tập tin món ăn,
chúng tôi sẽ loại bỏ các ý kiến từ DishessChema,
bởi vì chúng tôi sẽ lưu trữ nội dung riêng biệt với
các món ăn trong phiên bản này của máy chủ của chúng tôi.
Vì vậy, đó là cách chúng tôi sẽ cập nhật mô hình món ăn ở đây.
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.
Đi vào mô hình ý kiến,
vì vậy bây giờ chúng ta thấy rằng chúng ta có CommentSchema thực hiện ở đây.
Nhưng ngoài ra, trong CommentsSchema,
bây giờ chúng ta cần phải rõ ràng trỏ đến
món ăn cụ thể mà nhận xét này là bình luận tương ứng.
Bây giờ, đây là nơi
quần thể con ngỗng của chúng ta và
cách chúng ta lưu trữ vật Ids đến để giải cứu chúng ta.
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á
, bình luận và tác giả ở đây.
Ngoài tác giả,
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à
loại: Mongoose.schema types.ObjectID,
và vì vậy điều này sẽ đề cập đến Dish ở đây.
Vì vậy, đây sẽ là một đối tượng tham chiếu đến mô hình món ăn ở đây,
và vì vậy với sửa đổi này bây giờ
ý 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,
tác giả mà lại là một tham chiếu đến người dùng tương ứng,
và sau đó lĩnh vực món ăn đó là một tham chiếu đến tương ứng món ăn ở đây.
Vì vậy, có nghĩa là bây giờ chúng ta sẽ cần phải
điền vào các ý kiến với cả tác giả và lĩnh vực món ăn.
Một khi chúng tôi đã hoàn thành điều này,
sau đó chúng tôi sẽ nói var Bình luận
mongoose.model và chúng tôi sẽ gọi này 'Bình luận',
và sau đó điều này sử dụng CommentSchema mà chúng tôi vừa xác định ở đây,
và sau đó chúng tôi cần phải xuất khẩu này từ đây,
bình luận .model từ đây.
Vì vậy, bây giờ chúng tôi đã giới thiệu các bình luận .model,
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.
Vì vậy, để giới thiệu bộ định tuyến nhận xét,
chúng ta hãy đi vào các tuyến đường ở đây,
và sau đó tạo một tệp mới có tên commentRouter.js.
Trong commentRouter.js, cho phép tôi sao chép một vài điều
trên từ DishRouter.
Vì vậy, chúng tôi sẽ có những ý kiến ở đây,
vì vậy hãy để tôi sao chép qua những điều này từ và cũng có thể,
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 đó,
và sau đó tôi sẽ cập nhật điều đó một chút sau đó.
Vì vậy, đi vào bình luận,
chúng ta cần tất cả các phần này,
vì vậy chúng tôi sẽ nói Com, Express, BodyParser, mongoose,
authenticate, cors, và sau đó chúng tôi
sẽ nhập bình luận từ các mô hình/bình luận.
Sau đó, chúng tôi sẽ gọi đây là bình luận mà là một Express.Router đây.
Sau đó, chúng tôi sẽ nói CommentOrter sử dụng BodyParser,
và sau đó điều này bây giờ sẽ trở thành con đường CommentOrter.
Bây giờ, chúng ta cần phải đi vào DishRouter và sau đó
loại bỏ tất cả các phần đề cập đến các ý kiến ở đây.
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.
Vì vậy, tất cả những điều này không còn cần thiết trong DishRouter.
Vì vậy, tôi sẽ loại bỏ tất cả điều này từ DishRouter ở đây,
vì vậy hãy để tôi cắt chúng ra,
tất cả mọi thứ liên quan đến lộ trình ý kiến từ DishRouter,
sau đó chúng tôi sẽ đi vào bình luận,
và sau đó cho phép tôi đi trước và dán vào vị trí ở đây,
sau đó chúng tôi sẽ chỉnh sửa điều đó ở đây.
Sau đó, sau đó, chúng ta cần xuất CommentOter.
Vì vậy, sẽ xuất bình luận cho chúng tôi.
Nhưng tất nhiên, mã này không hoàn toàn chính xác.
Vì vậy, chúng ta cần phải đi trước và sửa chữa mã này ở đây.
Vì vậy, cho mã này,
bây giờ chúng ta nhận ra rằng đây không phải là tuyến đường DishRouter,
thay vào đó phải là
/endpoint bởi vì chúng ta
sẽ được gắn kết này trong /comments điểm cuối đây.
Vì vậy, chúng ta sẽ nói Commentrouter,
và sau đó các tùy chọn CorsWithOptions (req,
res) mà vẫn còn như vậy ở
đó, và sau đó nhận cors.cors và sau đó req.res,
và sau đó điều này sẽ trở thành bình luận.
FindByID, req.
Vì vậy, đây sẽ là bình luận. Tìm
và req.query đây.
Vì vậy, khi các ý kiến được tìm thấy,
sau đó, tại thời điểm này,
chúng tôi sẽ cư trú tác giả,
đã có ở đó, cư trú ở đây.
Vì vậy, tôi chỉ cần loại bỏ bình luận này.author, và sau đó,
chúng tôi sẽ chỉ đơn giản là cư tác giả ở đây.
Sau đó, điều này sẽ cung cấp cho chúng tôi ý kiến ở đây.
Sau đó, chúng ta sẽ nói, điều này có thể được đơn giản hóa đáng kể.
Vì vậy, lỗi bắt là ở đó anyway.
Vì vậy, khi nhận xét đến, nó sẽ đơn giản trở lại.
Xin lỗi, phải thế thôi.
Vì vậy, nếu cho nhận được,
khi chúng tôi nhận được các ý kiến, bình
luận. Tìm req.query, .populate tác giả ở đây,
và sau đó, chúng tôi sẽ nói, .then ý kiến,
và sau đó, chúng tôi sẽ nói, res.StatusCode 200,
Setheader, và sau đó, chúng tôi sẽ trả lại ý kiến từ đây,
res.json ý kiến từ đây.
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
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.
Tôi chỉ cần ID món ăn,
và ID món ăn đã có mặt ở đó,
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.
Vì vậy, tôi sẽ để nó như vậy ở đó.
Tôi sẽ chỉ điền
thông tin tác giả ở đó bởi vì chúng ta cần thông tin tác giả đầy đủ
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.
Vì vậy, get sẽ được cập nhật như thế này ở đây.
Đối với bài CorsWithOptions,
chúng ta sẽ nói, Authenticate.VerifyUser req, res, tiếp theo.
Rõ ràng, để nhận xét được đăng,
bạn cần tác giả là một người dùng đăng nhập hợp lệ.
Chỉ sau đó, bạn sẽ cho phép người dùng đăng bình luận.
Sau đó, bản thân nhận xét đi kèm trong nội dung của thư yêu cầu đến.
Vì vậy, trước tiên, chúng tôi sẽ kiểm tra cơ thể
để đảm bảo rằng nhận xét được bao gồm trong cơ thể ở đây.
Vì vậy, ở đây, tôi sẽ loại bỏ tất cả các phần này, và sau đó,
đơn giản hóa nó hơn nữa, và sau đó,
chúng tôi sẽ thực hiện điều này một cách chính xác ở đó.
Vì vậy, ngay tại thời điểm này, chúng ta sẽ nói,
nếu req.body không bằng null,
vì vậy có nghĩa là có một nhận xét được kèm theo bên trong cơ thể.
Vì vậy, để tôi cắt nó và chuyển nó vào phần nếu ở đây,
và sau đó, chúng tôi sẽ chỉnh sửa nó ở đây.
Vì vậy, nếu cơ thể không tồn tại,
thì chúng ta sẽ gây ra một lỗi.
Vì vậy, chúng ta sẽ nói, sai lầm mới,
Bình luận không tìm thấy trong cơ thể yêu cầu.
Vì vậy, chúng tôi sẽ nêu ra lỗi này ở đây.
Trạng thái lỗi là 404.
Sau đó, chúng tôi sẽ nói, trả lại lỗi tiếp theo.
Vì vậy, chúng ta hãy xử lý phần lỗi ở đây nếu cơ thể
không chứa thông tin nhận xét thích hợp.
Nếu nó chứa, sau đó, tất nhiên,
những gì chúng ta sẽ làm tiếp theo là,
chúng ta sẽ nói, req.body.author là req.user. _id.
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ó
là một người dùng đã đăng ký và người dùng đã đăng nhập,
sau đó req.user sẽ chứa thông tin người dùng.
Vì vậy, tôi chỉ cần ID của người dùng đang đăng nhập.
Vì vậy, chúng tôi sẽ nói, req.user. _id, và sau đó,
chúng tôi sẽ thiết lập req.body.author để req.user. _id
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,
sau đó bạn rõ ràng sẽ có một người dùng đã đăng nhập chính xác.
Nếu không, điều đó đã gây ra vấn đề ở đó.
Vì vậy, khi bạn đạt được tại thời điểm này,
bạn sẽ có một người dùng hợp lệ đã đăng nhập vào hệ thống trong đó.
Vì vậy, đây là nơi bạn có thể đến bây giờ.
Vì vậy, những gì chúng tôi đang làm là lĩnh vực tác giả,
chúng tôi rõ ràng thiết lập nó vào ID của người dùng ở đây để
req.body chứa các phần còn lại của nhận xét.
Vì vậy, như bạn nhận ra, bình luận chứa đánh giá,
bình luận chính nó, và tác giả, và các lĩnh vực món ăn.
Vì vậy, các phần còn lại nên đã được lấp đầy bởi người dùng.
Đánh giá, nhận xét
và thông tin món ăn nên đã được điền
vào nội dung của tin nhắn yêu cầu đến.
Phần tác giả được để lại không được lấp đầy ở đó,
mà chúng tôi sẽ chèn rõ ràng tại thời điểm này vào cơ thể ở đây.
Vì vậy, bây giờ, req.body sẽ chứa toàn bộ thông tin nhận xét.
Vì vậy, tại thời điểm này,
thay vì làm điều này, chúng ta sẽ nói, bình luận.
Sử dụng req.body, chúng tôi sẽ tạo các ý kiến ở đây.
Sau đó, điều này sẽ trả
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.
Bây giờ, một khi bình luận đã trở lại,
sau đó chúng ta nên làm bình luận. FindByid.
Bây giờ, lý do chúng ta cần làm điều này là vì chúng ta cần
phải điền thông tin tác giả ở đây.
Vì vậy, chúng ta sẽ nói, FindByID bình luận. _id,
và sau đó, chúng tôi sẽ điền thông tin tác giả vào bình luận chính nó.
Sau đó, chúng ta sẽ nói, sau đó bình luận.
Bây giờ, rõ ràng, ở đây, bạn sẽ thấy rằng bình luận sẽ
tồn tại bởi vì chúng tôi chỉ chèn bình luận đó vào vị trí đó.
Vì vậy, ở đây, chúng tôi sẽ chỉ đơn giản là trở lại, res.StatusCode là 200,
res.SeTheader là Content-Type, application/json.
Bản thân nhận xét sẽ nói, res.json, và sau đó,
trả lại nhận xét tại thời điểm này.
Vì vậy, đây là cách chúng tôi sẽ xử lý việc chèn
một nhận xét mới vào phía khách hàng của chúng tôi ở đây.
Đối với đặt, như bạn nhận ra,
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.
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.
Đó là vấn đề. Đó là thông điệp mà anh sẽ trở lại.
Vì vậy, StatusCode là 403,
và sau đó, PUT hoạt động không được hỗ trợ trên /bình luận/.
Bây giờ, khi chúng ta xóa,
hãy để tôi cắt nó từ đây, và sau đó, chúng ta sẽ nói,
bình luận.
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,
bạn sẽ loại bỏ tất cả các ý kiến từ hệ thống của bạn.
Vì vậy, đây là một hoạt động rất nguy hiểm, và vì vậy,
bạn không nên làm điều này bình thường.
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.
Vì vậy, chúng tôi sẽ xóa tất cả các ý kiến từ đó.
Vì vậy, khi bạn nhận được phản ứng,
sau đó chúng tôi sẽ nói res.StatusCode 200.
Vì vậy, để tôi sao chép những phần này ở đây,
và sau đó đến và dán nó vào đây.
Vì vậy, chúng tôi sẽ nói, bình luận.
Sau đó phản ứng res.StatusCode 200 ứng dụng json và sau đó res.json (phản ứng) ở đây.
Vì vậy, đó là cách chúng tôi xử lý việc xóa.
Xóa hoạt động trên điểm cuối nhận xét dấu gạch chéo.
Bây giờ, tuyến đường tiếp theo là bộ định tuyến nhận xét.
Vì vậy, ở đây chúng ta sẽ nói bình luận. Route và
điểm kết thúc ở đây sẽ là dấu gạch chéo CommentID.
Vì vậy, ở đây các tùy chọn sẽ vẫn như vậy.
Sau đó, cho get trên router hiện tại,
cho get chúng ta sẽ nói, bình luận. FindByID (req.params.
Đây sẽ là lời bình luận.
Vì vậy, một khi chúng tôi tìm thấy bình luận cụ thể,
sau đó chúng tôi sẽ cư trú chỉ là tác giả từ đó.
Sau đó, một khi bạn cư tác giả,
sau đó chúng tôi sẽ nói, sau đó bình luận.
Bây giờ, tất cả phần này là không cần thiết ở đây,
vì vậy tôi sẽ chỉ xóa phần này.
Đây cũng không phải là điều thích hợp ở đây.
Vì vậy, để tôi đổi tên mã.
Vì vậy, chúng ta sẽ nói cho nhận bình luận. FindByID,
sau đó cư tác giả,
sau đó bình luận, res.StatusCode là 200, Setheader.
Sau đó, phần còn lại là json.
Chúng tôi sẽ chỉ đơn giản là trả lại các ý kiến ở đây.
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).
Bạn sẽ tìm thấy nhận xét cụ thể,
và sau đó trả lại nhận xét đó cho bài đăng.
Đối với sau phẫu thuật, như bạn nhận ra,
sau phẫu thuật không được
phép trên bình luận CommentID.
Vì vậy, đó là thông điệp mà chúng tôi sẽ gửi,
POST hoạt động không được hỗ trợ trên bình luận dấu gạch chéo CommentID.
Vì vậy, đó là thông điệp chúng tôi sẽ nói cho đặt.
Bây giờ, cho đặt, chúng ta sẽ nói bình luận. Tìm nơi Id (Req.params.Commentid).
Vì vậy, chúng tôi sẽ tìm thấy bình luận ở đó,
và có bình luận, vì vậy cho đặt.
Vì vậy, chúng tôi sẽ tìm thấy bình luận ở đó,
và sau đó chúng tôi sẽ nói cho các ý kiến.
Vì vậy, nếu chúng ta tìm thấy bình luận,
nếu bình luận không phải là null,
sau đó chúng tôi cũng sẽ kiểm tra nếu bình luận.
Nếu không, comment.arthur bằng (req.user. _id).
Vì vậy, chúng tôi đang kiểm tra chéo để đảm
bảo rằng bình luận .author là giống như người dùng hiện tại.
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,
thì người dùng sẽ được phép cập nhật.
Vì vậy, đó là điều đầu tiên mà chúng tôi sẽ kiểm tra.
Vì vậy, bình luận, sau đó bình luận. author.equal to rec.user. _id
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.
Như bạn thấy .403,
và sau đó trả lại lỗi tiếp theo ở đây.
Vì vậy, chúng tôi sẽ tạo ra lỗi ở đó.
Sau đó, sau đó chúng ta sẽ nói
req.body.author, req.user. Điều
đó rất quan trọng.
Bây giờ, hai điều này không cần thiết ở đây,
bởi vì chúng tôi đang trực tiếp lưu bình luận.
Sau đó thuốc, chúng tôi sẽ nói bình luận .FindbyidanDupdate,
và Req.params.Commentid.
Vì vậy, chúng tôi sẽ tìm thấy rằng bình luận cụ thể,
bởi vì chúng tôi đã được cung cấp ID nhận xét.
Vì vậy, chúng tôi sẽ làm ý kiến findByID req.params.Commentid.
Sau đó, chúng tôi sẽ nói sau đó (bình luận).
Khi bạn cung cấp Req.params.Commentid,
chúng tôi sẽ phải cung cấp một cách rõ ràng tham số thứ hai,
đó là những gì chúng tôi muốn thay đổi.
Vì vậy, chúng ta sẽ nói $set: req.body.
Vì vậy, tham số thứ hai, về cơ bản,
cho bạn biết phần nào bạn đang thay đổi.
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,
chúng tôi sẽ chỉ cập nhật toàn bộ bình luận chính nó.
Sau đó, phần còn lại chúng tôi sẽ yêu cầu là mới: đúng.
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
den của cuộc gọi này để bình luận. FindByidanDupdate.
Vì vậy, chúng tôi sẽ nói sau đó ý kiến.
Khi nhận xét đó được trả lại,
sau đó chúng tôi sẽ nói bình luận. FindByid (bình luận. _id).
Sau đó cư tác giả ở đó.
Chúng tôi sẽ cư tác giả ở đó,
và sau đó chúng tôi sẽ nói sau đó bình luận.
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.
Vì vậy, đó là cách chúng tôi sẽ cập nhật bình luận.
Vì vậy, đây là tình huống mà bình luận không phải là null.
Vì vậy, điều này nếu tuyên bố cho nhận xét không phải là null.
Vì vậy, người khác nếu một phần,
bây giờ điều này là không áp dụng,
vì vậy chúng tôi sẽ nói khác, lỗi.
Lỗi trong trường hợp này.
Vì vậy, nếu bình luận là null,
điều đó có nghĩa là chúng tôi không tìm thấy bình luận trong đó,
vì vậy bạn không thể sửa đổi một bình luận không tồn tại.
Vì vậy, chúng tôi sẽ nói sai lầm,
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.
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,
và sau đó cuối cùng là xóa.
Để xóa, một lần nữa chúng ta sẽ phải tìm
bình luận đầu tiên. FindByid (Req.params.Commentid)
và sau đó bình luận.
Vì vậy, chúng tôi sẽ tìm kiếm nhận xét.
Vì vậy, trước tiên chúng ta sẽ kiểm tra xem bình luận không bằng null.
Điều đó rất quan trọng để kiểm tra ở đây.
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
Chúng tôi đảm bảo rằng người dùng này đang cố gắng để xóa
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.
Nếu không, vì vậy nếu đây là tình huống,
sau đó bạn sẽ thấy 'Bạn không được phép xóa nhận xét này! '
Và sau đó trả lại trạng thái ở đó.
Sau đó, dưới đây,
chúng tôi sẽ nói bình luận. FindByidandRemove đây.
Vì vậy, chúng tôi sẽ nói bình luận .findbyidandRemove (Req.params.Commentid),
sau đó chúng tôi sẽ nhận được một số phản ứng từ nhận xét.
Vì vậy, tại thời điểm này,
chúng tôi sẽ chỉ đơn giản là nói, res.StatusCode.
Vì vậy, chúng tôi sẽ nói bình luận. FindByidandRemove sau đó phản ứng.
Nếu nó được gỡ bỏ một cách chính xác,
chúng tôi sẽ nói 200 và sau đó res.json
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.
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.
Vì vậy, đó là điều đầu tiên mà chúng tôi sẽ kiểm tra.
Chúng tôi sẽ đảm bảo rằng bình luận không bằng null.
Nếu không, vì vậy đây là phần khác.
Vì vậy, đây là phần khác của nếu khác lỗi
mới bình luận req.params.CommentID không tìm thấy và sau đó
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.
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.
Vì vậy, chúng tôi đang xử lý bài get put và xóa cho
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.
Vì vậy, một khi chúng tôi đã hoàn thành điều này,
sau đó chúng ta cần phải bao gồm điều này vào tập tin app.js.
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
var bình luận
yêu cầu Routes/bình luận.
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
xuống vào tập tin app.js xuống dưới đây và
sau đó chúng tôi sẽ nói app.use
dấu gạch chéo ý kiến, bình luận ở đây.
Đó là nó. Vì vậy, bây giờ,
bộ định tuyến nhận xét của tôi đã sẵn sàng.
Vì vậy, chúng ta hãy tiếp tục và lưu tất cả các thay đổi.
Sau đó, máy chủ của chúng tôi bây giờ được cập nhật
để xử lý tất cả các yêu cầu từ khách hàng React của chúng tôi ở đây.
Bây giờ, nếu bạn muốn làm theo cách khác, đó là,
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
đó, sau đó bạn sẽ cần phải cập nhật các khách hàng React
để 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.
Điều đó sẽ được để lại như một bài tập cho bạn.
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ó
hoạt động rất tốt với phiên bản trước
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.
Bây giờ, đó sẽ là một cách thú vị để thực hiện nó.
Tất nhiên, nó phức tạp hơn một chút so với cách chúng tôi
thực hiện React khách hàng nơi chúng tôi giữ ý kiến độc lập của
các món ăn nhưng sau đó công việc bổ sung là trách nhiệm
của phía khách hàng bởi vì bạn cần phải chọn
các ý kiến thích hợp khi bạn đang hiển thị món ăn cụ thể.
Bạn cần phải chọn các ý kiến từ tất cả các ý kiến ở đây.
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ì
thực tế là chúng tôi tách các ý kiến từ các món ăn mình.
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ể
đố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.
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ể
mở rộng ứng dụng khách hàng của bạn để xử lý bất kỳ loại máy chủ,
hai loại máy chủ khác nhau ở đó.
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.
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ủ.
Vì vậy, chúng ta hãy lưu tất cả các thay đổi ở phía máy chủ.
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.
Với điều này, chúng tôi hoàn thành bài tập này.
Trong bài tập này, chúng tôi đã chuẩn bị máy chủ nhanh của chúng tôi
để xử lý các yêu cầu đến từ khách hàng React của chúng tôi.
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 để
hiểu làm thế nào nó được giao tiếp với máy chủ bổ sung này.
Đây là thời điểm tốt để bạn thực hiện
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ủ.