Anh return thẳng luôn uniqueID + i, không gọi IIFE cũng được luôn nếu khai báo let i = 0 trong for-loop, tại bản chất closure là lưu tham chiếu đến biến, mà trong vòng lặp for với let thì mỗi lần lặp nó sẽ tạo 1 binding mới (Lexical env) nên thằng closure nó sẽ tham chiếu đến binding ở từng thời điểm lặp
Cảm ơn bạn đã đọc bài và góp ý
Mình tìm hiểu các khái niệm này từ góc độ của tester, nên không đi sâu vào cách triển khai cụ thể trên BE. Rất mong bài viết giúp bạn phần nào có cái nhìn tổng quan. ^^
@TranChien2112 đúng rồi e nhé, ở Middleware thì mình k có cách nào lấy được thông tin của handler tiếp theo, còn Guard thì được. Khái niệm này a lấy nguyên văn từ docs của NestJS nên đôi khi hơi khó hiểu, khi dùng thì e sẽ dễ phân biệt hơn 😁
@ntngoc96wd Vâng em cũng hiểu "handler ở đây là route handler" ạ , nhưng trước giờ e vẫn nghĩ: app.use("/", middleware, router handler) thì khi gọi hàm next() của middleware, ứng dụng sẽ chuyển tiếp tới router handler đặt sau nó để xử lý tiếp mà ạ ? Câu: "Middleware sẽ k biết được handler nào được gọi sau nó" tức là khi xử lý xong công việc, nó gọi next(), còn ứng dụng chuyển tới handler nào xử lý thì nó không biết đúng không ạ ? E vẫn chưa rõ lắm 🥲
Nếu mình khai báo ví dụ trên Sw 1 link sang Sw3 : interface range fa0/3-7 ; channel-group 1 mode active liệu có được k hay phải khai Etherchannel trên từng interface như trên?
Sorry e chỗ này chắc a chưa ghi rõ: handler ở đây là route handler ấy e, ở góc độ run-time(khi chương trình thực thi) thì Middleware sẽ k biết được handler nào được gọi sau nó, còn Guard thì sẽ biết được nhờ vào Execution Context. Điển hình là context.getHandler() hay thấy khi chúng ta viết authentication.
@tuananhtd09 cái comment này tôi trả lời cho câu hỏi "còn bạn" ở cuối bài á ông.
Còn Visual Studio và VScode là 2 sản phẩm khác hẳn về bản chất, tên hơi giống xí thôi.
"Khi không tồn tại thuộc tính city, trước hết nhờ ?. nó trở thành undefined, tiếp theo, toán tử ?? sẽ set nó thành toán hạng bên phải "City not provided"." Đâu phải nhờ ?. thì nó mới undefined đâu, thằng customer2 bên trong nó không có prop city thì việc truy cập đến mặc nhiên nó sẽ undefined mà bác, thằng ?. nó chỉ ngăn access đến hành vi tiếp theo kể từ trước đó nếu như không tồn tại (null / undefined) thôi chứ
THẢO LUẬN
Bạn ơi ra phần 2 chưa
Anh return thẳng luôn uniqueID + i, không gọi IIFE cũng được luôn nếu khai báo let i = 0 trong for-loop, tại bản chất closure là lưu tham chiếu đến biến, mà trong vòng lặp for với let thì mỗi lần lặp nó sẽ tạo 1 binding mới (Lexical env) nên thằng closure nó sẽ tham chiếu đến binding ở từng thời điểm lặp
Đồng ý luôn, mình từng làm cả 2 dự án và thực tế Bloc để làm màu xịn hơn GetX. Chỉ có vậy thôi!
@lgdark Thank anh
uk, anh nói đúng. Cái này là điểm yếu rất lớn của Postgres.
các bạn có bài tiểu luận về UML cho mình tham khảo với
Có login được bằng usernam thay cho email không ạ
Cảm ơn bạn đã đọc bài và góp ý
Mình tìm hiểu các khái niệm này từ góc độ của tester, nên không đi sâu vào cách triển khai cụ thể trên BE. Rất mong bài viết giúp bạn phần nào có cái nhìn tổng quan. ^^
chúc e thành công 😍
Tuyệt vời quá, thanks anh. Em đang nghiên cứu về xử lý ảnh.
@ntngoc96wd Okie anh 😘
@TranChien2112 thanks e đã dành thời gian đọc nhé 😁 có gì thắc mắc cứ comment nha
@ntngoc96wd E cảm ơn anh nha! Series hay lắm ạ 🥰
@TranChien2112 đúng rồi e nhé, ở Middleware thì mình k có cách nào lấy được thông tin của handler tiếp theo, còn Guard thì được. Khái niệm này a lấy nguyên văn từ docs của NestJS nên đôi khi hơi khó hiểu, khi dùng thì e sẽ dễ phân biệt hơn 😁
@ntngoc96wd Vâng em cũng hiểu "handler ở đây là route handler" ạ , nhưng trước giờ e vẫn nghĩ: app.use("/", middleware, router handler) thì khi gọi hàm next() của middleware, ứng dụng sẽ chuyển tiếp tới router handler đặt sau nó để xử lý tiếp mà ạ ? Câu: "Middleware sẽ k biết được handler nào được gọi sau nó" tức là khi xử lý xong công việc, nó gọi next(), còn ứng dụng chuyển tới handler nào xử lý thì nó không biết đúng không ạ ? E vẫn chưa rõ lắm 🥲
Nếu mình khai báo ví dụ trên Sw 1 link sang Sw3 : interface range fa0/3-7 ; channel-group 1 mode active liệu có được k hay phải khai Etherchannel trên từng interface như trên?
Rất hay ạ
Sorry e chỗ này chắc a chưa ghi rõ: handler ở đây là route handler ấy e, ở góc độ run-time(khi chương trình thực thi) thì Middleware sẽ k biết được handler nào được gọi sau nó, còn Guard thì sẽ biết được nhờ vào Execution Context. Điển hình là
context.getHandler()hay thấy khi chúng ta viết authentication.@tuananhtd09 cái comment này tôi trả lời cho câu hỏi "còn bạn" ở cuối bài á ông. Còn Visual Studio và VScode là 2 sản phẩm khác hẳn về bản chất, tên hơi giống xí thôi.
"Khi không tồn tại thuộc tính city, trước hết nhờ ?. nó trở thành undefined, tiếp theo, toán tử ?? sẽ set nó thành toán hạng bên phải "City not provided"." Đâu phải nhờ ?. thì nó mới undefined đâu, thằng customer2 bên trong nó không có prop city thì việc truy cập đến mặc nhiên nó sẽ undefined mà bác, thằng ?. nó chỉ ngăn access đến hành vi tiếp theo kể từ trước đó nếu như không tồn tại (null / undefined) thôi chứ