A. useEffect 1. Cập nhật lại state 2. Cập nhật lại DOM (mutate) 3. Render lại UI 4. Gọi clear up fuction khi deps thay đổi 5. Gọi useEffect callback B. useLayoutEffect 1. Cập nhật lại state 2. Cập nhật lại DOM (mutate) 3. Gọi clear up function khi deps thay đổi (sync) 4. Gọi useEffect callback (sync) 5. Render lại UI
Máy ai mà không thấy số 4 thì thêm dòng log(count) trước setCount(0) là có nhé, máy mình do nhanh quá nên không nhìn thấy nên ai bị vậy thì làm như mình là thấy ngay khi render 4 và log ra 4 rồi thì mới setCount về 0
À anh làm ví dụ để nêu ra vấn đề thôi. Trong thực tế cũng ít gặp, useEffect được dùng trong hầu hết mọi trường hợp xử lý side effect. Sau gặp tình huống chớp nháy như ví dụ thì dùng useLayoutEffect để giải quyết
@@F8VNOfficial à dạ, ý em là em hiểu anh làm ví dụ để hiểu đc luồng chạy của 2 hook, nhưng mà em thấy nếu check điều kiện ở useState trước khi setCount thì cũng ko bị trường hợp chớp nháy mà cũng ko cần đến 2 hook kia á anh. Thông thường em cũng ít khi dùng useEffect cho mấy trường hợp này, thường dùng để gọi api thôi à anh, nên em mới thấy cách xử lý này mới á
Mọi người cho mình hỏi đoạn code trên, tại sao useEffect với dependency là count, trong callback của useEffect lại setCount mà ko bị infinity loop nhỉ ? Ai giải thích giúp mình với.
Callback của useEffect setCount về 0 thì count lúc này luôn = 0 nên [deps] ko thay đổi nên useEffect ko bị gọi lại => k bị infinity. Infinity khi callback của useEffect có đối số là 1 callback làm thay đổi count. Ví dụ setCount(count=>count+1) chẳng hạn
Nếu trong func handleRun viết lại setCount theo kiểu: setCount(prevCount => prevCount + 1) thì cũng giải quyết được vấn đề này mà không cần sử dụng useLayoutEffect. Tại sao lại như vậy ạ? Anh có thể giải thích được đoạn này không ạ?
thì ad cũng có nói là ko cần thiết phải sử dụng useLayoutEffect. Khi nào cần thiết bắt buộc mới phải dùng. Còn admin chỉ demo để mình hiểu cách nó chạy như nào thôi.
mình đã thử và không hề giải quyết được vấn đề, bạn nên xem lại. Vì setCount(prevCount => prevCount + 1) và setCount(count + 1) kết quả đều là setCount(4) và render lại UI.
Nó là ví dụ cho trường hợp cần dùng useLayoutEffect thôi bạn. Trong bài học mình khó để bê một ví dụ phức tạp trong thực tế vào được nên tạo ví dụ như vậy. Bạn đừng hiểu theo cách setCount về 0 là xong, mà hãy hiểu khi thay đổi data ở một hàm handle rồi ở một useEffect tiếp tục thay đổi nó thì sẽ xảy ra vấn đề đó. Đôi khi bạn làm dự án sẽ gặp tình huống đó, nó nhiều logic hơn nên được tách ra riêng một useEffect để xử lý. Giống như bạn xem các ví dụ của state management thì ví dụ của nó lúc nào cũng là cộng/trừ counter. Nhưng chúng ta không thể hiểu là state management là để làm counter, chúng ta cần tư duy liên hệ nó với các trường hợp khác.
mình nghĩ là không thay thế được bạn, mỗi thằng nó có chức năng riêng của nó , như layoutEffect mà thay thế useEffect thì ví dụ như một cái gì đó mình cần xử lý logic trong nhiều và mất thời gian không lẽ phải chờ xử lý xong mới render ra UI nên là không thay thế được , ( theo ý kiến cá nhân mình là vậy )
Theo mấy bài trước thì em hiểu là cleanup sẽ được thực thi trước khi unmount DOM, tới bài này thì anh listed ra là render UI rồi mới cleanup. Cho e hỏi là unmount DOM -> render UI -> Cleanup hay là cleanup -> unmount DOM -> render UI vậy ạ
Theo tôi hiểu thì cleanup sẽ được thực thi khi unmount DOM và được gọi trước khi useEffect callback , như bài trước unmount là gỡ nó ra khỏi DOM luôn , còn trường hợp render UI này nó cập nhật lại biến count kia chứ không gỡ khỏi DOM nên cleanup sẽ được chay theo số 3 a Sơn chỉ là thực thi trước useEffect callback nên nó không liên quan gì đến render UI hay sao ấy
Clean up khi component unmount và khi component update, trong trường hợp update lại thì thứ tự như trên đó bạn render UI > clean up > useEffect, tóm lại là nó có 2 case.
Không phải là ít sài , Ví dụ như 1 navigate đi đến có truyền theo params Params default là true alway có dữ liệu thì nên dùng vì khi vào component này params sẽ chạy đầu tiên và có dữ liệu để load vào render nó sẽ hợp lý hơn là render sau đó mới state lại params và đở phải check empty valid cho cái object params được truyền qua đó
A. useEffect
1. Cập nhật lại state
2. Cập nhật lại DOM (mutate)
3. Render lại UI
4. Gọi clear up fuction khi deps thay đổi
5. Gọi useEffect callback
B. useLayoutEffect
1. Cập nhật lại state
2. Cập nhật lại DOM (mutate)
3. Gọi clear up function khi deps thay đổi (sync)
4. Gọi useEffect callback (sync)
5. Render lại UI
Cảm ợn anh, đọc học React trước đó nhưng học lại của anh cảm thấy hiểu được thêm rất nhiều thứ.
bài này hay thật sự, đúng cái em bị bấy lâu nay mà không fix được, hay quá anh ơi
hay quá a ơi, biết thêm dc 1 kiến thức mới
hữu ích lắm idol :D
huhu 😭😭😭 giờ mới xem đc video này .. tối qua mất 4 tiếng ko pix đc lỗi hoá ra dùng thg này
Hay anh ơi !!
hên, hnay ms vào thế, mai có solution để fix r :v
Hay quá
Hay a
Máy ai mà không thấy số 4 thì thêm dòng log(count) trước setCount(0) là có nhé, máy mình do nhanh quá nên không nhìn thấy nên ai bị vậy thì làm như mình là thấy ngay khi render 4 và log ra 4 rồi thì mới setCount về 0
Anh Sơn ơi, khi nào có khóa NodeJS ạ
Cmt đầu
react": "^18.2.0", ở 3p50s không bị trường hợp nhấp nháy từ 4 về 0.
vẫn có mà b
Sao mình ko check điều kiện ở handleRun để setCount về 0 vậy anh, thực tế có làm vậy ko anh?
bạn xem ko kỹ rồi, ổng cố tình làm vậy để cho lúc render bị nháy => xem sự khác nhau giữa useEffect và useLayoutEffect mà
À anh làm ví dụ để nêu ra vấn đề thôi. Trong thực tế cũng ít gặp, useEffect được dùng trong hầu hết mọi trường hợp xử lý side effect. Sau gặp tình huống chớp nháy như ví dụ thì dùng useLayoutEffect để giải quyết
@@F8VNOfficial à dạ, ý em là em hiểu anh làm ví dụ để hiểu đc luồng chạy của 2 hook, nhưng mà em thấy nếu check điều kiện ở useState trước khi setCount thì cũng ko bị trường hợp chớp nháy mà cũng ko cần đến 2 hook kia á anh. Thông thường em cũng ít khi dùng useEffect cho mấy trường hợp này, thường dùng để gọi api thôi à anh, nên em mới thấy cách xử lý này mới á
em cũng bị khi fillter sản phẩm
hyhy
Mọi người cho mình hỏi đoạn code trên, tại sao useEffect với dependency là count, trong callback của useEffect lại setCount mà ko bị infinity loop nhỉ ? Ai giải thích giúp mình với.
sao mà infinity loop đc bạn . VD count updated là 2 , vậy 2 thì sao lớn hơn 3 để thoã điều kiện mà setCount đc thực thi
Callback của useEffect setCount về 0 thì count lúc này luôn = 0 nên [deps] ko thay đổi nên useEffect ko bị gọi lại => k bị infinity.
Infinity khi callback của useEffect có đối số là 1 callback làm thay đổi count. Ví dụ setCount(count=>count+1) chẳng hạn
Nếu trong func handleRun viết lại setCount theo kiểu: setCount(prevCount => prevCount + 1) thì cũng giải quyết được vấn đề này mà không cần sử dụng useLayoutEffect. Tại sao lại như vậy ạ? Anh có thể giải thích được đoạn này không ạ?
thì ad cũng có nói là ko cần thiết phải sử dụng useLayoutEffect. Khi nào cần thiết bắt buộc mới phải dùng. Còn admin chỉ demo để mình hiểu cách nó chạy như nào thôi.
mình đã thử và không hề giải quyết được vấn đề, bạn nên xem lại. Vì setCount(prevCount => prevCount + 1) và setCount(count + 1) kết quả đều là setCount(4) và render lại UI.
@@thangnguyenhuu5076 trong hàm callback bạn phải kiểm tra xem nó có >3 không, nếu có thì set nó thành 0 luôn. thì count sẽ mãi mãi không >3 được.
Cá nhân mình lại thấy useLayoutEffect hữu ích hơn :)
Anh làm thế nào để biết cái luồng bên dưới chạy sao vậy a?
Đọc trên reactjs.org nha em
vậy tại sao không dùng 1 cái if để kiểm tra ở trong method handleRun để có thể setCount trực tiếp về 0 luôn mà lại dùng thêm useEffect ấy
Nó là ví dụ cho trường hợp cần dùng useLayoutEffect thôi bạn. Trong bài học mình khó để bê một ví dụ phức tạp trong thực tế vào được nên tạo ví dụ như vậy. Bạn đừng hiểu theo cách setCount về 0 là xong, mà hãy hiểu khi thay đổi data ở một hàm handle rồi ở một useEffect tiếp tục thay đổi nó thì sẽ xảy ra vấn đề đó. Đôi khi bạn làm dự án sẽ gặp tình huống đó, nó nhiều logic hơn nên được tách ra riêng một useEffect để xử lý.
Giống như bạn xem các ví dụ của state management thì ví dụ của nó lúc nào cũng là cộng/trừ counter. Nhưng chúng ta không thể hiểu là state management là để làm counter, chúng ta cần tư duy liên hệ nó với các trường hợp khác.
@@F8VNOfficialem hiểu rồi, em cảm ơn admin ạ,
liệu useLayoutEffect có thay thế luôn thằng useEffect k nhỉ thấy hàm này kiểu như tối ưu hơn ý nhở làm xong hết mới render ra cho client
mình nghĩ là không thay thế được bạn, mỗi thằng nó có chức năng riêng của nó , như layoutEffect mà thay thế useEffect thì ví dụ như một cái gì đó mình cần xử lý logic trong nhiều và mất thời gian không lẽ phải chờ xử lý xong mới render ra UI nên là không thay thế được , ( theo ý kiến cá nhân mình là vậy )
Theo mấy bài trước thì em hiểu là cleanup sẽ được thực thi trước khi unmount DOM, tới bài này thì anh listed ra là render UI rồi mới cleanup. Cho e hỏi là unmount DOM -> render UI -> Cleanup hay là cleanup -> unmount DOM -> render UI vậy ạ
Theo tôi hiểu thì cleanup sẽ được thực thi khi unmount DOM và được gọi trước khi useEffect callback , như bài trước unmount là gỡ nó ra khỏi DOM luôn , còn trường hợp render UI này nó cập nhật lại biến count kia chứ không gỡ khỏi DOM nên cleanup sẽ được chay theo số 3 a Sơn chỉ là thực thi trước useEffect callback nên nó không liên quan gì đến render UI hay sao ấy
Clean up khi component unmount và khi component update, trong trường hợp update lại thì thứ tự như trên đó bạn render UI > clean up > useEffect, tóm lại là nó có 2 case.
Không phải là ít sài ,
Ví dụ như 1 navigate đi đến có truyền theo params
Params default là true alway có dữ liệu
thì nên dùng vì khi vào component này params sẽ chạy đầu tiên và có dữ liệu để load vào render
nó sẽ hợp lý hơn là render sau đó mới state lại params và đở phải check empty valid cho cái object params được truyền qua đó
Nếu luôn có dữ liệu thì đẩy vào view luôn sao phải dùng layout effect làm gì bạn nhỉ?
vậy túm lại là useEffect thì render xong mới gọi callback còn thần useLayoutEffect thì gọi callback trước mới render :))
Gọi trước nhưng gọi đồng bộ. Túm lại như này làm sao giải thích đc case ở trên?