Straight up had to take a breather 5 minutes into this talk because Khourshid rehashed every single traumatic devex pain point the React core maintainers have subjected us since we adopted the library
The isCancelled pattern in useEffect should continue work even if React is unmounting + remounting the effect. Your remounted copy will simply cancel the first effect but will run the second promise. If you change the dependency array, the second effect will simply cancel the remounted effect. Then the second remounted effect cancels the second original effect. You ended up with the result from the second remounted effect. Hence the page shows the intended results. Sorry I don't see any incorrectness stemming from running effects twice with this pattern. ua-cam.com/video/eFGeStq8dZo/v-deo.html
Yes. Fetching data is a synchronization with outside of React, I want my initial state to sync with server data, it seems the definition of useEffect. I wouldn't say "fetching data in useEffect is wrong", it is misleading, because you can argue the same points for other useEffect examples: - Connecting to socket => connect as render, don't connect in useEffect.. - addEventListener type of logic => start listening as you render, dont use useEffect... The difference is fetching data takes more time and probably constitutes a big part of your UI that optimizing is very beneficial. Also, caching is hard ( not a problem of useEffect) So, fetching after render is a waste of time ( like any other examples of "correct" useEffect usage, except more important/bigger waste of time ) Also it leads to waterfall situations => parent fetching => wait for parent to load => child fetching => .... ( you can fix it so parents don't block if they are independent) If your app is fully client side, you only know what to fetch from your component tree(what you want to show)... ( you can map those fetch requests to page URL and fetch early, kind of like Remix) But I think there is also value in a component owning the data requirement ( fetching, showing data/error etc.)
Straight up had to take a breather 5 minutes into this talk because Khourshid rehashed every single traumatic devex pain point the React core maintainers have subjected us since we adopted the library
Thanks for the excellent presentation !
When you have whole talk dedicated to one callback function, that means it's not a great design.
great sharing, thanks davidk🎹
The isCancelled pattern in useEffect should continue work even if React is unmounting + remounting the effect. Your remounted copy will simply cancel the first effect but will run the second promise. If you change the dependency array, the second effect will simply cancel the remounted effect. Then the second remounted effect cancels the second original effect. You ended up with the result from the second remounted effect. Hence the page shows the intended results. Sorry I don't see any incorrectness stemming from running effects twice with this pattern. ua-cam.com/video/eFGeStq8dZo/v-deo.html
Yes. Fetching data is a synchronization with outside of React, I want my initial state to sync with server data, it seems the definition of useEffect.
I wouldn't say "fetching data in useEffect is wrong", it is misleading, because you can argue the same points for other useEffect examples:
- Connecting to socket => connect as render, don't connect in useEffect..
- addEventListener type of logic => start listening as you render, dont use useEffect...
The difference is fetching data takes more time and probably constitutes a big part of your UI that optimizing is very beneficial.
Also, caching is hard ( not a problem of useEffect)
So, fetching after render is a waste of time ( like any other examples of "correct" useEffect usage, except more important/bigger waste of time )
Also it leads to waterfall situations => parent fetching => wait for parent to load => child fetching => .... ( you can fix it so parents don't block if they are independent)
If your app is fully client side, you only know what to fetch from your component tree(what you want to show)... ( you can map those fetch requests to page URL and fetch early, kind of like Remix)
But I think there is also value in a component owning the data requirement ( fetching, showing data/error etc.)