thấy console.log every where thật sự là 1 cách fix bugs ugly. Mình nghĩ nên dùng debugger hơn là dùng console, đọc code nhiều chỗ thấy thừa, lên production rồi mà chỗ nào cũng thấy console.
Value của input thì lấy ở state, nhưng lúc edit lại muốn fill value từ store vào phải ko? sao ko fill thẳng value của input từ store vào, đừng dùng state nữa
Em xin phép có một số góp ý như sau. Theo em đoạn này của anh: "Mỗi khi Component được wrap bởi React.memo nó sẽ so sánh giá trị lần cuối được render lưu trong bộ nhớ của React với lần render kế tiếp, nếu như giống nhau thì nó sẽ bỏ qua việc render component và sử dụng lại kết quả được render cuối cùng" là một đoạn cực kỳ mơ hồ, đặc biệt là "so sánh giá trị lần cuối render được lưu trong bộ nhớ của React", "giá trị lần cuối render" là giá trị gì? "so sánh" là so sánh như thế nào?
Theo em khi nhắc đến React.memo thì có 2 cái quan trọng cần phải nhấn mạnh là so sánh "props", và cách thức so sánh là "shallow compare". Chi tiết hơn đã có một bạn trên viblo viết rồi: https://viblo.asia/p/reactmemo-Ljy5VM7Glra.
Còn bài viết hay và chi tiết nhất em đọc được trên internet về chủ đề tối ưu số lần render trong React là bài của tác giả Kent C. Dodds: https://kentcdodds.com/blog/usememo-and-usecallback/. Bài này rất hay và đáng tham khảo, nếu anh có thời gian và muốn chia sẻ thì dịch bài này đăng trên viblo cũng rất hữu ích. Peace ^^
THẢO LUẬN
Anh viết bài quá hay. Cảm ơn anh. Chúc anh luôn luôn thành công ạ.
xem log xong phải xóa đi chứ ai lại để lên prodution
phần kết nối các container thì ở thời điểm hiện tại docker compose đã có network, user-defined bridge thay cho dùng link, default bridge.
Khắc phục được nhược điểm mà bạn nói là không thể xóa liên kết mà ko chạy lại tất cả container kết nối đến nó.
Còn phần publish port thì nó thực tế không phải là 1 cách để kết nối các container đâu.
https://docs.docker.com/network/bridge/##differences-between-user-defined-bridges-and-the-default-bridge
@quachphuc typo mistake:
difer->deferthấy console.log every where thật sự là 1 cách fix bugs ugly. Mình nghĩ nên dùng debugger hơn là dùng console, đọc code nhiều chỗ thấy thừa, lên production rồi mà chỗ nào cũng thấy console.
ngưỡng mộ quá
@minhnv em cũng k biết nosql có ăn được k. n mà em biết em ăn được bimbim ớ (tat)
Thích thì ăn thuôi bạn huhuhihi 😘 😘 😘
À mình khen xã giao ý mà =))
hhihihi
Hay quá bạn ei
Đọc xong bài mình vẫn chưa biết NoSQL có ăn được không
Value của input thì lấy ở state, nhưng lúc edit lại muốn fill value từ store vào phải ko? sao ko fill thẳng value của input từ store vào, đừng dùng state nữa
Chất như nước cất, thanks bạn đã chia sẻ. Hi vọng nếu có thời gian thì b chia sẻ thêm vụ Docker và CI/CD, thật sự mấy vụ này khá là ngu.
cảm ơn bạn bh mình mới biết tmux và byobu nhìn có vẻ ngon hơn screen nhiều
@devil_boom_129 cũng bt mà
Anh viết bài hay quá ! Hy vọng sẽ gặp lại anh trong bài mới
@jonyu thì?
Em xin phép có một số góp ý như sau. Theo em đoạn này của anh: "Mỗi khi Component được wrap bởi React.memo nó sẽ so sánh giá trị lần cuối được render lưu trong bộ nhớ của React với lần render kế tiếp, nếu như giống nhau thì nó sẽ bỏ qua việc render component và sử dụng lại kết quả được render cuối cùng" là một đoạn cực kỳ mơ hồ, đặc biệt là "so sánh giá trị lần cuối render được lưu trong bộ nhớ của React", "giá trị lần cuối render" là giá trị gì? "so sánh" là so sánh như thế nào? Theo em khi nhắc đến React.memo thì có 2 cái quan trọng cần phải nhấn mạnh là so sánh "props", và cách thức so sánh là "shallow compare". Chi tiết hơn đã có một bạn trên viblo viết rồi: https://viblo.asia/p/reactmemo-Ljy5VM7Glra. Còn bài viết hay và chi tiết nhất em đọc được trên internet về chủ đề tối ưu số lần render trong React là bài của tác giả Kent C. Dodds: https://kentcdodds.com/blog/usememo-and-usecallback/. Bài này rất hay và đáng tham khảo, nếu anh có thời gian và muốn chia sẻ thì dịch bài này đăng trên viblo cũng rất hữu ích. Peace ^^