thắc mắc Tại sao ReactJS lại hot đến vậy ạ?
- Người tạo chủ đề Celsius
- Ngày bắt đầu
cba
Member
Toán và toán nhé.
Các node nối với nhau + binding theo các giải thuật.
teeeeeeeee
Senior Member
Bữa giờ không check threadShallow compare chứ có deep compare đâu nhỉ? Chưa hiểu bottleneck thế nào?. Như fen nói thì react nó đã lưu ý vấn đề hiệu năng rồi. so sanh compare a === b thì chậm thế nào nhỉ?
Còn hiện tại ai đang ko làm theo document của React thì biết rồi. Fen cũng chả đưa ra được dẫn chứng nào chứng minh của fen nói cả. Tại sao phải tin lời của fen so với cái document nói? Ko lẽ mấy thằng core team nó dốt hơn fen?
Còn mấy cái lưu ý này trong document đều có nói đến, thậm chí còn tốn sức tạo ra cái eslint rule cho mấy thằng dev xài, mà hóa ra cơ số mấy anh giỏi trên đây ignore ko thèm xài luôn
rảnh vô chém gió với fence chơi
thật ra thì bottleneck nó đâu có nằm ở cái compare
nó nằm ngay cái callback ấy chứ, tưởng tượng một expensive function nằm trong callback r useEffect được trigger vì một dependency nào đó không mong muốn đi
Tất nhiên là dependency đó vẫn được dùng đúng như docs React đã chỉ nhé
không violate rules of hook
via theNEXTvoz for iPhone
binpham17
Senior Member
Yeah đồng ý vs bác.Bữa giờ không check thread
rảnh vô chém gió với fence chơi
thật ra thì bottleneck nó đâu có nằm ở cái compare
nó nằm ngay cái callback ấy chứ, tưởng tượng một expensive function nằm trong callback r useEffect được trigger vì một dependency nào đó không mong muốn đi
Tất nhiên là dependency đó vẫn được dùng đúng như docs React đã chỉ nhé
không violate rules of hook
via theNEXTvoz for iPhone
Nhiều ông cứ máy móc bỏ hết vào deps mà hổng biết nó dùng làm gì.
Thậm chí có 1 số thứ còn chẳng thèm nhét vào useCallback vs useMemo cơ :v
Với lại trong 1 số trường hợp chi phí để tạo lại 1 object mới có khi còn ít hơn chi phí để memorize nó :v
nntgwww
Member
Có usecase cụ thể thì lôi ra xem có thuộc 1% ko nào. Còn mấy ông này tự tin mình top 1% thì ok fine. Còn ko nhét vào useCallback hay useMemo thì tôi có nhắc đến 1 case trên kia rồi, nhưng vấn đề là useEffect deps array.
Sửa lần cuối:
nntgwww
Member
Thế bottleneck do tốn memory hay do tốn CPU. Rồi cpu với memory thì cái nào ảnh hưởng perf user trước tiên.Bữa giờ không check thread
rảnh vô chém gió với fence chơi
thật ra thì bottleneck nó đâu có nằm ở cái compare
nó nằm ngay cái callback ấy chứ, tưởng tượng một expensive function nằm trong callback r useEffect được trigger vì một dependency nào đó không mong muốn đi
Tất nhiên là dependency đó vẫn được dùng đúng như docs React đã chỉ nhé
không violate rules of hook
via theNEXTvoz for iPhone
Code tốt thì phải giảm được lượng dependency là chuyện bt.
Nói chung mấy cái expensive của a gì đẫy cũng chỉ dc 1 % thôi. Tôi thà guide mấy ông junior nó theo eslint này nọ chứ exp ko có nghe lời mấy ông dụ dỗ ko cần fill đủ deps thì code bug còn nát hơn.
Mà thôi giờ nhé, lúc nào cũng skip deps array hay chỉ đôi lúc thôi. Fen nói thẳng đi.
Sửa lần cuối:
teeeeeeeee
Senior Member
Là sao ta
cái nào hết trước thì ảnh hưởng trước th, hay ý fence là memory xài 5% nhưng mà CPU xài tới 99% vẫn chưa gọi là ảnh hưởng 
lúc nào cũng skip deps thì disable cái rule lun cho r chứ thêm code làm gì cho nặng
Giờ ví dụ một thứ tại sao expensive function lại quan trọng nhé
Chắc fence biết browser xác định một task được gọi là long running task là thế nào mà đk, nếu long running task đó chiếm dụng main thread ko thả ra cho browser render thì lúc đó user còn muốn xài nữa không
Code tốt là code lôi kéo và giữ chân đc user
còn lý do vì sao tôi dị ứng autofill full deps, đơn giản là vì lúc review code làm sao biết đc context của ticket đó thế nào mà đoán đc là hook có được sử dụng đúng cách hay chưa? Chỉ khi nào thấy bottleneck r thì mới chui đầu vô mà debug th, mà tới lúc như vậy thì có khi codebase đã quá to, người fix ko nắm được tất cả context để xử lý cho phù hợp
oke chưa
quandoanzombie
Senior Member
Cái deps trong useEffect là để quản lý khi nào cần làm gì, trong trường hợp bất kì biến nào nằm ở cái deps đó được update, đâu nhất thiết phải fill hết vào deps đâu 
.
Nếu sợ callback không lấy được value mới nhất vì miss biến trong deps, thì tạo một cái useEffect riêng với chỉ duy nhất biến đó trong deps thôi, rồi update value vào một cái useRef ở trong đấy, dùng cái useRef đó ở useEffect phía trên là xong.
.Nếu sợ callback không lấy được value mới nhất vì miss biến trong deps, thì tạo một cái useEffect riêng với chỉ duy nhất biến đó trong deps thôi, rồi update value vào một cái useRef ở trong đấy, dùng cái useRef đó ở useEffect phía trên là xong.
nntgwww
Member
Là sao ta
lúc nào cũng skip deps thì disable cái rule lun cho r chứ thêm code làm gì cho nặng
Giờ ví dụ một thứ tại sao expensive function lại quan trọng nhé
Chắc fence biết browser xác định một task được gọi là long running task là thế nào mà đk, nếu long running task đó chiếm dụng main thread ko thả ra cho browser render thì lúc đó user còn muốn xài nữa không
Code tốt là code lôi kéo và giữ chân đc user
còn lý do vì sao tôi dị ứng autofill full deps, đơn giản là vì lúc review code làm sao biết đc context của ticket đó thế nào mà đoán đc là hook có được sử dụng đúng cách hay chưa? Chỉ khi nào thấy bottleneck r thì mới chui đầu vô mà debug th, mà tới lúc như vậy thì có khi codebase đã quá to, người fix ko nắm được tất cả context để xử lý cho phù hợp
Vấn đề của các cụ trên đây là k biết điền cái gì vào anh à.
Cái auto fill chính là hint để điền vô cho các cụ ấy.
Còn bây giờ project dí ngâp mặt thay vì lo phải optimzie tìm mọi cách skip deps này nọ thì trước mắt cứ follow đúng rule đã tính gì rồi tính. Còn hơn điền thiếu bug lúc đó ko thấy anh nói có tốn công debug hay không. Ngay cả việc điền đủ cũng đã dạy cách hiểu về deps array work thế nào. còn tôi dị ứng mấy thằng ko pass eslint thôi.
Rõ ràng điền đủ đó chính là cái dễ nhất. Tiếp theo suy nghĩ giảm bớt deps thế nào. Cái nào nó cũng đi theo quá trình. exp chưa có đòi giảm deps, skip như mấy anh thì best quá.
Còn bây giờ expensive function ở đây là expensive về mem hay cpu? Nếu cpu tôi memo chả có gì sai cả vậy thôi. Chả hiểu bottle neck cm gì luôn. Hay anh muốn nói cái function callback của effect nó expensive? Nếu nói run effect expensive thì anh tự xem lại code của anh đó là về optimize chả liên quan lắm skip deps. Vì code sao nó chậm là lỗi anh thôi, code dởm chống chế phải skip deps. Or lúc này a tự nghĩ mình thuộc 1% mà skip deps cũng dc.
Sửa lần cuối:
teeeeeeeee
Senior Member
Oke giờ thêm một ví dụ nữa nha, giờ expensive task đó không phải do mình code mà là của một library nào đó (cách dùng làm y chang docs nhé). Lúc này code chậm là lỗi do mình luôn pkVì code sao nó chậm là lỗi anh thôi, code dởm chống chế phải skip deps. Or lúc này a tự nghĩ mình thuộc 1% mà skip deps cũng dc.
a không thấy chậm thì không có nghĩa là client ko thấy chậm, có bao giờ bật tab performance r thử throttle network với CPU xem thử code nhìn clean mà sao nó lại block main thread quá lâu hem
Một website đâu phải chạy ở localhost đâu, cũng đâu phải lúc nào cũng đc chạy trên Macbook pro M1 32GB RAM đâu
vậy nha fence cứ giữ cái quan điểm như vậy chả ảnh hưởng gì tới tôi, chủ yếu lên đây chém gió th
P/S: À mà tôi cũng ko đưa ra được example đâu, tại đâu có biết đâu mà đưa ra
nntgwww
Member
Anh em nào làm dc cái web ngốm ram như đỉa đói thì chắc ko còn vô voz chém gió đâu tôi nói thật. (ko tính web nào cùi hủi do memory leak)Oke giờ thêm một ví dụ nữa nha, giờ expensive task đó không phải do mình code mà là của một library nào đó (cách dùng làm y chang docs nhé). Lúc này code chậm là lỗi do mình luôn pk
a không thấy chậm thì không có nghĩa là client ko thấy chậm, có bao giờ bật tab performance r thử throttle network với CPU xem thử code nhìn clean mà sao nó lại block main thread quá lâu hem
Một website đâu phải chạy ở localhost đâu, cũng đâu phải lúc nào cũng đc chạy trên Macbook pro M1 32GB RAM đâu
vậy nha fence cứ giữ cái quan điểm như vậy chả ảnh hưởng gì tới tôi, chủ yếu lên đây chém gió th
P/S: À mà tôi cũng ko đưa ra được example đâu, tại đâu có biết đâu mà đưa ra
Ko đưa ra example code nào chậm thì biết gì đâu. Chậm đến mức đó có thể dùng đến web worker để đỡ block mainthread nhất. Nhưng túm váy cũng chỉ thuộc 1% thôi.
Quan điểm của tôi khi nào chậm thì optimize tiếp. Author react cũng đã nói mấy vụ này rồi, lo mà code khi nào chậm thì optimize, đừng có có gắng optimize đến mức perfect ngay từ đâu. Ban đâu làm gì có cái fn nào block main thread đâu mà suy nghĩ tương lai chắc có rồi phải skip deps. Sao ko nghỉ bỏ full deps nhưng vẫn control dc khi nào nó run đi như thế k phải pro hơn à.
Vậy thôi nhé chứ mấy ông jr gi đấy ko biết điền cái gì vô deps thì cứ theo chuẩn của linter auto fill rồi run code xem effect chạy ổn ko, có bị loop hay ko. Từ đó xem lại chỗ sai, có thể sửa lại props phải memo, useCallback ntn nào đó.
Cuối cùng gặp dc case 1% như mấy anh trên kia thì hãy sn skip deps, tự tin gắn vô ignore eslint this line or tháo mẹ luôn linter cho pro. Chứ tôi dev quèn thôi chỉ làm 99% case thôi.
Sửa lần cuối:
nntgwww
Member
Chắc useRef ko tốn memo như useCallback quá fen. Làm vậy chi cho cực? Kiểu né cái này qua cái kia cũng y chang mà còn cực lòi ass ra nữa.Cái deps trong useEffect là để quản lý khi nào cần làm gì, trong trường hợp bất kì biến nào nằm ở cái deps đó được update, đâu nhất thiết phải fill hết vào deps đâu
Nếu sợ callback không lấy được value mới nhất vì miss biến trong deps, thì tạo một cái useEffect riêng với chỉ duy nhất biến đó trong deps thôi, rồi update value vào một cái useRef ở trong đấy, dùng cái useRef đó ở useEffect phía trên là xong.
Đã bảo chú rồi đừng có tranh luận với mấy thằng kia mà.
Hồi xưa có 1 diễn đàn React tôi lên phàn nàn chất lượng dev React thấp quá còn bị bọn nó ban nick cơ. Nói chung chất lượng dev React thảm hại lắm. Cãi nhau với mấy ông trình kém làm gì.
nammegai
Senior Member
Hi các bác, là em hôm trước hỏi cái FE đây, có bác nào có thể cứu em ca này với. Em dùng fetch để lấy data từ API, nhưng response trả về bị promise.
Sau khi em dùng async/await vào trả về vẫn bị như thế
Response mong đợi trả về trong postman thì nó đáng lẽ nên như thế này:
Bây giờ làm sao để fix ạ, em stress quá
Sau khi em dùng async/await vào trả về vẫn bị như thế
Response mong đợi trả về trong postman thì nó đáng lẽ nên như thế này:
Bây giờ làm sao để fix ạ, em stress quá
mat.troi.be.con
Member
các bác có thể giải thích tại sao các bank hay hệ thống tài chính lại ưu tiên dùng angular thay vì các fw, lib khác ko
telbook
Senior Member
https://stackoverflow.com/questions/37555031/why-does-json-return-a-promiseHi các bác, là em hôm trước hỏi cái FE đây, có bác nào có thể cứu em ca này với. Em dùng fetch để lấy data từ API, nhưng response trả về bị promise.Xem tệp đính kèm 1777946
Sau khi em dùng async/await vào trả về vẫn bị như thế
Xem tệp đính kèm 1777948
Response mong đợi trả về trong postman thì nó đáng lẽ nên như thế này:
Xem tệp đính kèm 1777951
Bây giờ làm sao để fix ạ, em stress quá
mat.troi.be.con
Member
promise thì dùng then là đc mà nhỉHi các bác, là em hôm trước hỏi cái FE đây, có bác nào có thể cứu em ca này với. Em dùng fetch để lấy data từ API, nhưng response trả về bị promise.Xem tệp đính kèm 1777946
Sau khi em dùng async/await vào trả về vẫn bị như thế
Xem tệp đính kèm 1777948
Response mong đợi trả về trong postman thì nó đáng lẽ nên như thế này:
Xem tệp đính kèm 1777951
Bây giờ làm sao để fix ạ, em stress quá
nguyenduhn
Senior Member
Sonarlint em tưởng là extension trên IDE chứ thím
telbook
Senior Member
Thì nó có cli để chạy ci/cd chứ sao thím
Edit: Mà có vẻ outdated, không biết bác kia nhắc đến là SonarQube hay gì
Chủ đề tương tự
