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?
THẢO LUẬN
bài viết chi tiết nhưng mà bạn viết nhiều lỗi chính tả quá @@
nếu trong context chứa 2 bean outfit thì girl sẽ được tiêm outfit nào nhỉ? Khi có 2 class implement outfit.
test cmt
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 ạ