Using useEffect Effectively - David Khourshid, React Advanced London 2022

React Advanced London 2022 #ReactAdvanced #GitNation
Website - reactadvanced.com/
Follow the link to watch the full version of all the conference talks, QnA’s with speakers and hands-on workshop recordings → portal.gitnation.org/events/r...
Talk: Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
This event would not take place without the support of sponsors:
🏆 Platinum Sponsors
Sourcegraph → about.sourcegraph.com/
Ag Grid → www.ag-grid.com/
Toptal → www.toptal.com/freelance-jobs
🥇 Gold Sponsors
Kontent.ai → kontent.ai/
Shopify engineering → jobs.smartrecruiters.com/
Prisma → www.prisma.io/
Launchdarkly → launchdarkly.com/
Storyblock → www.storyblok.com/
AWS Amplify → docs.amplify.aws/
🥈 Silver Sponsors
Formidable → formidable.com/
Stream → getstream.io/
imgIX → imgix.com/
Callstack → www.callstack.com
Modus Create → moduscreate.com/
Chromatic → www.chromatic.com/
Softescu → softescu.com

[@mdaverde]

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

[@kanz831021]

Thanks for the excellent presentation !

[@huang47tw]

great sharing, thanks davidk🎹

[@judegao7766]

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. kzbin.info/www/bejne/m3eqloaqpp2XkNE

[@cmlttnts4906]

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.)

[@coolemur976]

When you have whole talk dedicated to one callback function, that means it's not a great design.