Why I Don’t Use useEffect In My React Components

useEffect is one of the greatest additions to React. It is so much nicer than using component lifecycle methods, but it comes with one huge problem. The API for useEffect sucks. Not only that, but having tons of useEffects in your components makes your code harder to parse and understand. This is why I try to minimize if not remove all useEffects from my components. This makes my code easier to read/write and makes sure all the ugliness of useEffect is hidden away in custom hooks.
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:35 - Project overview
01:23 - Hiding useEffect in custom hooks
05:00 - How not to use useEffect
08:24 - How to do fetching
#useEffect #WDS #ReactJS

[@Thelukkest]

This one is kinda a clickbait. You still use it but just in custom hooks.

[@Leon-bb8fc]

@@christenw.1726 gz, u just described what clickbait means

[@Thelukkest]

@@christenw.1726 I mean if you say you don't do something, do you still do it just because you didn't use the word ever?

[@andrillaf]

@Thelukkest Maybe, but if you said “This is why I don’t drink coffee,” with an explanation, I would understand, what you mean.

[@cvemwanda]

I agree, title and thumbnail are misleading

[@hevans900]

Yeah this is a non-video. Not up to your usual standard.

[@ultragigachader]

For the newbies out there : my personal opinion is you should absolutely use useEffect, do not fall into the trap of applying syntactic sugar or makeup for the sake of hiding stuff that you may not like to see in your code. Keep it simple, extract code that you will repeat often accross components and most importantly keep your code readable ( name functions, variables and add comments where necessary ). That's it.

[@xjfw2]

I agree, i dont like to maping code and also if you see abstracted code like this you expect that its being used on at least more components, this video can be actually an anti-pattern.

[@alhazred3555]

based

[@roydondecastro]

When Ultra Giga Chad speaks, we listen. WebDevSimp doesn't use useEffect but he uses useEffect, kinda sus. But i'm just a noob so what do I know.

[@petarkolev6928]

One should use useEffect only if the logic requires it, but talking about "you should absolutely use useEffect" - who said one shouldn't? Kyle is explaining how when one need to use useEffect he/she needs to write it in a separate custom hook related to that component which needs the logic in that useEffect, and I totally agree with this approach :) I use it all the time, except I have only one small useEffect, then I write in the component, but when I have two or more, I immediately move it to a separate file.

[@ultragigachader]

@@petarkolev6928 read "my personal opinion". Also, I'm right.

[@yoni532s9M5w]

2016: Stop using jQuery 2018: Stop using Angular 2020: Stop using class components 2030: Stop using your PC, return to monke

[@lambmaster]

2040: use jQuery

[@Mr505505]

🤣🤣🤣🤣

[@chonkyboy3597]

:v 2022 stop using CRA

[@KeganVanSickle]

I definitely still prefer Angular. :)

[@reactdom.render]

Angular will be deprecated soon in the future because it's no longer maintain. React will wrapped to the world

[@wlockuz4467]

Corrected to avoid confusion. Please -don't stop using useEffect- don't stop using useEffect in your components just because WDS told you not to, useEffect exists for a reason. Codebases are different in nature and what works for him may or may not work for you. Do some research, understand the trade-offs, then make a decision.

[@francarloscastillorobles3618]

He says don’t I don’t use it because it’s being used in a costume hooks, kind of stupid things just to make content

[@_HappyHippo]

He isn't really saying to not use useEffect. The point of the vid just appears to be: "keep your components easy to read". The title and a good portion of the video is misleading because what he is actually saying is, that you should put your useEffects into custom hooks to hide them from your components, and not to straight up stop using useEffect.

[@francarloscastillorobles3618]

@@_HappyHippo but we all know that component should be easy to read, not just component with useEffect hooks.

[@_HappyHippo]

@@francarloscastillorobles3618 Yes it is obvious.

[@joegaffney8006]

how to hide that you are using useEffect

[@Shibzzeg]

Clickbait title, I'd say this is not about useEffect per se, but more about the value of abstracting more complex logic that relies on state/side effects behind a custom hook. Otherwise, I agree with your thoughts on this approach.

[@khaledsanny4817]

No it's not clickbait ... he explicitly said "he doesnt use it inside react components"... Hooks are not react components as far as I know... he is just abstracting useEffectwith custom hooks...

[@onuralpbicer887]

@@khaledsanny4817 Hooks are definitely extensions of react components

[@tapiwakundishora6195]

I wouldnt call it click bait but even if it was, he needed to get your attention and he provided useful information which is okay in my eyes

[@TamNguyen-vj4sq]

He is RIGHT, he said dont use it in REACT COMPONENTS.

[@warodomwerapun6417]

I agree that he provides useful information in my view, however, this title leads newbies to misleading of the useEffect().

[@Aman-Verma]

:( Please update the title of this video. It’s misleading

[@pixiedev]

You said absolutely right. He should change it to "You are using useEffect in wrong way" and In my opinion If (he's providing any good thing) { it's not a clickbait. } else { it's a clickbait }

[@JulianHarris]

TL;DR “wrap useEffect in custom hooks for better separation of concerns”. Much easier to understand and use.

[@javajoint]

A better title for this would have been "why I squirrel my useEffect calls away in utility functions". When we used to do Class based components (pre-hooks), we would reach for the lifecycle method of componentDidMount(). That's how I approach useEffect() these days: I'm loading a page, and it depends on dynamic data. The fact that useEffect() is being called automatically gives me a great spot to do my fetch. It's not a complex operation, and the timing is perfect. I think Jack Herrington does a great job on his channel of explaining many hooks gotchas.

[@JaradDeLorenzo]

Thank you. Came here to say this.

[@aaronmotacek9343]

Does JH have a specific video about hook gotchas? Discovered him recently and really like his videos.

[@javajoint]

@@aaronmotacek9343 First off: I think Kyle does a good job most of the time :) I wont post videos for other channels here. I would recommend searching within the channel.

[@aaronmotacek9343]

@@javajoint Understandable, I think the same. I subscribe to Kyle's newsletter and always try to check out his latest videos.

[@miggu]

yeah but I wouldn't have clicked through probably, so by creating a clickbait he has earned more viewers, I knew there was some gotcha anyway.

[@ken_bekov]

Can't wait for the next video named "Stop using React in your React projects". This one is not clickbait enough 😉

[@LSDsuperfruit]

ya, pure javascript for the win!

[@theropoy9371]

Why I Don’t Use useEffect ... uses useEffect

[@harmez7]

yeah, you can find this nasty disease everywhere

[@LeungWong]

So basically use libraries which uses useEffect for you behind the scene. Or create custom hooks which uses useEffect. All because you don’t want to clutter your component with direct use of useEffect.

[@TarasovFrontDev]

I think it's enough. UseEffect makes uncertain rerender. And it's for good to avoid it.

[@natalieeuley1734]

useEffect is my go to for components. It just makes the most sense. Callbacks and memos seem so finicky, but useEffect always just works exactly how you expect. When these things change, do this. It really doesn't get any simpler than that.

[@dzajakeks5539]

*sees title* wtf is meaning of this now?

[@yakmoon]

most of his vids are for dumb people who don't know what they are doing, some people take him seriously.

[@KingTMK]

@@yakmoon Not true at all...

[@superchrishovids]

Would be great if you also did a followup video on how to extract the useEffect and create a custom hook

[@jr-hp7er]

This is a great example, One more thing I would like to do in addition with the abstraction of the useEffect, is like creating a adapter pattern which can just define an interface and then via the contextprovider, we can provide that interface, and hide the actual implementations

[@florianvo7616]

So essentially you‘re just putting the useEffects elsewhere into a custom hook. The main concern for custom hooks isn’t increasing readability but avoiding code repetition. That’s a good idea if the custom hook is gonna be used in multiple components but it’s a bad idea if it’s only gonna be used in a single component as all it does is forcing you to look into another file to understand what’s happening which actually makes the readability worse then.

[@flowerofash4439]

exactly what is in my head after watching the vid. readability is number one, and only then everything else

[@panicbox4609]

Not if you have like 5 useeffects on the page all doing different stuff, if it's a custom hook its easier to see dependencies and also know what the custom hook is used for

[@florianvo7616]

@@panicbox4609 I Stay to my point: You only benefit from a custom hook when it gets reused. Otherwise you are better off to not encapsulate your logic in other place than you use it. Only when you reuse you are simplifying and avoiding code repetition. Otherwise you are just spreading code without benefit and make program unnecessarily spread and complex

[@florianvo7616]

@@panicbox4609 also when you have 5 super complex use effects in a component, maybe the component is doing too much?

[@DevMadeEasy]

Great Content, as usual, thank you so much for sharing it with us, I know how hard is to build a project then edit it, post... Thanks🙏

[@DeepTitanic]

Is having a file that large best practice? Personally I'd prefer to have a component folder with everything broken down into smaller files. What's everyone's opinion on this?

[@tima1301]

похуй

[@dueft4479]

I have a comment component that is about 300+ lines bc of a lot of event handlers and other stuff. I extracted it into several sub-components and created a hook for modifying server state. But there is somewhere a limit where I don't want to code-split it anymore. The only thing I could do further is to divide it into sections. But for me personally, that's not neccessary and I like to have it in one file. So my answer is as long as it is maintainable for you. Large components can be well maintained too.

[@jeffreyjdesir]

I think it's ultimately best to make components as small, dumb and error resistant as possible, then build HOC from them as possible. Also hooks and controller logic should be separated into files completely I think, then used. Same with configs, types, and data. This can be a little tedious makes my code so much easier to think about and reuse in the future. Tailwind FTW

[@DeepTitanic]

@@jeffreyjdesir I totally agree although I wasn't sure if it was something I was over focusing on.. I just cant stand scrolling through multiple screens of code. Have to disagree on TW though I prefer writing plain CSS Modules. I've been waiting 10 years for CSS to get this good.. now no one wants write it anymore ;-)

[@DeepTitanic]

@@dueft4479 Yeah there was definitely a point where I took it too far with too many imports and abstractions. Overall though I like to have each file only doing a couple of things at a time.

[@benjaminthorne4157]

Personally I like opening a component and immediately seeing the logic that is execute on-mount. I totally get the idea of hiding your useEffects in custom hooks but doesn’t this have the potential to make debugging quite tedious?

[@narnigrin]

That's my immediate thought as well.

[@the-iter8]

I think kyle made this video for cleaning up the code and just structuring it properly.

[@andresmontero7481]

@@the-iter8 100% clickbait

[@the-iter8]

@@andresmontero7481 Of course it is

[@subhamjaiswal8382]

But it will components very reusable. The logic layer and ui layer separated in twi pieces.

[@MintAIO]

If anything, I'd argue having the useEffect related to a component in a different file is harder to read since you have to go and find that extra file.

[@HaxxBlaster]

It all comes down to if you will reuse the custom hooks or not. But yeah, what you are talking about is unnecessary indirection. One could argue that components should be small enough that specific hook logic to that component should not be put in another file. Having big components so you make a custom hook only make the component look smaller is an indication that the component is wrongly designed and should be split up.

[@Sammysapphira]

No it doesn't. Writing a semantically titled hook lets you know exactly what the hook does.

[@jonathan.watson]

Kyle any chance you will publish the code shown in the video? the project looks interesting and as a beginner i'd love to take a look.

[@nickwoodward819]

would love to see you do a walk through of one of these projects explaining the code, that would be a great course

[@JoaoPaulo-ox6pr]

I thought on a way to remove some of those with OOP yesterday, together with functional components which will only use these classes together with custom hooks, like by using getter methods, cause most of times we have a state that depends on another, then, we need to update this state when the another one changes, as the time passes, you'll have these useEffects executing when they shouldn't run, also, triggering other useEffects in the way, maybe even causing an infinite loop in the project. making the code so hard to write, i have this problem in my project now, but it's so big that it has become hard to even think in removing one useEffect.

[@rv264]

But what if you need to render the page/ run a fetch if a state or the use effect dependencies changes ? The basic use of useEffect , I.e loading of page when required shouldn’t be discarded too right ?

[@robwatson826]

That was a really interesting video. I’m fairly new to React and use useEffect basically on every page to handle first load stuff but abstracting it to nice clean custom hooks looks like a very cool idea. I shall be looking to implement this myself. A question though, how would you go about extracting a useEffect that sets multiple pieces of state that the component uses? I would really like to see a video of you refactoring that admin page you mentioned to move those useEffects out of the component. Keep up the great videos Kyle, hope you’re feeling better after your recent illnesses ❤

[@TabuHana]

I think what you want is context. I would look up 'react useContext'. I'm not 100% sure, but even so it would be good to know! :)

[@robwatson826]

@@TabuHana Aah good shout, so the custom hook can access a Context that holds some global state?

[@israelfagundes2]

@@robwatson826 ofc

[@pragmaticcodeodyssey]

I just don't think they hiding your useEffect is necessary in custom hooks or otherwise some other way. I mean, we understand what useEffect does. This seems to be a biased suggestion of architecture that doesn't truly solve any problems. If you're having trouble reading them or feel like it is being misused, that's not to say the best logical move is to hide them or use them in a way that just overcomplicated things and makes debugging a nightmare. Perhaps a mixture of comments or just working on the readability of your code is the sufficient move to make here.

[@richestofthejews8845]

correct me if i'm wrong, but components shouldn't be that large and contain so much functionality, logic and jsx in single component (like component at the start of the video). it should be decomposed into smaller helper functions and more smaller components

[@harmez7]

right, Kyle is noob

[@gbroton]

@@harmez7most of the Internet teacher haven't seen properly written production code, as they only are Internet teachers

[@SurajSingh-fg6eq]

The way you explain things and your voice….. bro your amazing!!! Keep up the good work

[@thesickandwounded]

So i've never heard this before and it is intressting but i dont really get why.. why i should put my useEffect in a costom hook inside the component if it's only being used there.. like why? Ok yea it looks better to just have a costom hook like checkUserLogin(user), instead of having a bunch of useEffects. But to understand what that costom hook does you still need to look through the very same useEffect code that you would if you just used it "inline" as u put it.

[@Kayotesden]

I use to think the same. Then I listened to a few videos by Uncle Bob. Highly recommended. The idea is to make your code easy to read & understand. While (I feel for f/e coding) its not realistic to write 5-6 lines of code per function, the idea remains that you should abstract out the logics into individual funcs/ components whenever possible. Its not always about making the code reusable, but also comprehensible.

[@stephenbetley9596]

So basically this is another form of encapsulation. As the codebase increases this is a sensible methodology whether it's functional programming with React or OOP with PHP. The primary reason for useEffect seems to be in state change when aggregating data. The more reusable the better.

[@HKRazieL]

just another clickbait video

[@TabuHana]

Would using a context be better or is that different in some way?

[@con.x]

I am interersted in this topic, I have a Leaflet Map. My Map uses 10!! useEffects. 10 separate state variables that handle 10 different marker types on the map. This map has been bothering me for WEEKS... because I know its too cluttered. While this goes over what should be done, it doesnt really take a solid example of how to do it. Some of these are pretty long useEffects that set multiple types of elements on the map. Id love to see a good way to convert my useEffect into a custom Hook, taking a useState, the data from /resources/ and placing them into a /hook/ ... I have one that "looks" at one variable but sets two state variables, one that "looks" at two different state variable but only updates one. like these are all over the place. I really would love to clean this up and tidy it up. this project is massive, and the technical debt is only growing. What do you suggest? Do you have a video that could help show me a clear direction to convert this properly?

[@geosystems2106]

I wish you had a simpler example for conversion, rather than the mega content you showed ;) yet, I will monitor the idea of using minimal hooks directly and use custom hooks instead 👍

[@truceheat1671]

Just almost thought it's something new .. this is just use effect with extra steps

[@noorulamin2652]

I think it depends on the use-cases. For instance in our case there are about 100 different pages and in every page there is a network request and in every page there are forms and in a lot places there are dependencies between form fields to check if one value exists then do this thing and vice versa. How are we gonna handle such a use case without useEffect?

[@kipa_chu]

yea. His advice only works for dumb web pages

[@thecyberhobbit]

WDS.... "Why I Don't Use useEffect In My React Components" Also WDS.... "I use useEffect 16 times in this entire project"

[@feralaca123]

This are just opinions. In real life, the time to spend on this is not always given. Creating customs hooks for everything may be unnecessary. Usage of useEffect is fine and you should use it until the need for a custom hook makes itself evident.

[@unlomtrash]

it's rather a question about the splitting of your business logic from your html, just like you split styles from one

[@thusithameedeniya9953]

can you provide the github link for this repo

[@vlaxis3359]

I think CoderOne's approach on writing a video title is much better. SOLID

[@troygooden2525]

Looking @ some of the comments you quickly realize that.... having an opinion will always offend somebody. Thanks for the video and interesting take.

[@seyiobafemi6915]

This actually makes sense and is worth considering. Side note: Can we also see you play that guitar though 👍

[@skkaushik7795]

Do we get a chance to see the project. As to know what are best practices and how real world project is Structured and developed. Make some tutorials on things like this 🎉

[@maurobagnoli3415]

why do you use relative imports?

[@MrRaj-qv7pg]

Can I get this full src?

[@robocopfarmer2879]

while the title is true, i felt it a bit misleading. I was kind of expecting to know why useEffect is not good within components because for example - causing multiple re-renders etc. But you are primarily referring to code refactoring and code reuse technique. Still, good tips.

[@mateusz1486]

For me it only makes sense to create custom hook if you are gonna use it in multiple places

[@The14Some1]

Another reason is to give the hook a meaningful name. "useEffect" itself does not tell what exactly effect we're using and what is the idea behind it. Here you can observe, how the author uses wrapping hooks to encapsulate and name distinct logical units.

[@josefaguilar2955]

"I wrote this all in one day" The perfect use case for useEffect: determining whether a dev had enough time to solve a problem or not.

[@alanthomasgramont]

This is exactly why i prefer using react-query instead of Redux. The logic is well hidden, easy to control and easy to implement.

[@ninhdang1106]

No more useEffect just to fetch data. Sadly it's still pretty much underrated with companies insisting on hiring people with Redux experience 😴

[@alanthomasgramont]

@@ninhdang1106 I just completed a contract using react-query and now I'm dreading using Redux again.

[@davidbroadhurst8107]

Responding to events in event handlers and using react query mostly reduces the need for useEffect even in custom hooks.

[@viraj_singh]

It’s mostly style preference, hiding useEffect in custom hooks, but maybe good for large scale typescript applications with multiple developers of different seniority level.

[@ninhdang1106]

It should be the standard. Imagine walking into an existing project and you have to read every line of the useEffect to figure out what it does

[@heddshot87]

Alternate title: why I always refactor what's inside my useEffects

[@TopBagon]

BS. No point in taking out useEffect from a component if you're still gonna use it in a custom hook. The syntax for it is actually pretty amazing and not hard to read at all + you know exactly when the code block will run just by looking at the dependency array.

[@figloalds]

Kinda relief to see that I'm not an outliar making some eventual HUMONGOUS components, people speak so much about "you should split everything until you have a bazillion 6-liner files!!!!" and I'm like, boi, I have all context here, everything is like two slaps of mouse wheel away from each other instead of fucking file navigation!

[@romanmed9035]

useEffect is used to run some actions once and probably repeat them later when the dependency changes. how can a custom hook do this if it runs every time the page is rendered?

[@iury664]

the point is to not stop using useEffect, but put them in a hook out of the component ?

[@ruwantharatnayake5004]

Its it a standard best practice to have ' ; ' to mark end of statement. I do not see nay on your code?

[@Dev-Siri]

Its your preference, although I agree that using `;` is a good practice

[@nomanmkhan]

Please make a video of full lage scale app with multiple endpoints using very less useffect

[@jeffreyjdesir]

Lol. Y'all so savage 😂 he's technically abstracting the useEffect hook into HOFs that bring semantic context and separation to the reactive bits (solid.js makes this antiquated btw). It's part of SOLID, personally, I couldn't stand seeing a bunch of imperative logic in some function that I didn't make so I've used a similar pattern since I got comfortable with reactive UI. But I get the grievances, if you want literally no hook like reactivity (which really isn't reactive) then check out SolidJS

[@eliyahutarab4862]

Question:do you use Redux in this app

[@nandantyagi]

Kyle rocks! Keep up the good work man! (I learned a lot from the comments as well :)

[@petersouthwell5971]

OR just use a Parent component that loads and handles the effects... And your components become view panels with properties. The properties get set by the "Loader" parent.

[@stevendu06]

I disagree, not everything has to be syntactic sugar, especially if you plan on using these hooks just once in your entire application. Hooks are great, should they be reused.

[@louis-emmanuelisnardon8308]

Good practice ! Separate the effect logic from the component that uses it, to divide and rule. I will do it all the time now. Thank you !

[@hazeion]

Debugging sucks this way. And having to jump around to see where the code is sucks too if you are coming from the outside. Sure it looks clean but you'll eventually have to see that code somewhere anyway.

[@vincend]

It's a good advice. Thank you

[@seondongkim]

"Use custom hooks when possible" wouldn't have gotten my attention. Well done.

[@kal9421]

I don't know useEffect is a great tool and I think you are using it the right way since you are synchronizing the state of a web api with your react state. I think what you mean is not to not use useEffect but simply to refactor your code and I advise you to give react query a shot. it's by far the best thing in react ecosystem

[@mr.madushan]

It's "I don't kill people, but I hire someone else to do it for me" kind of situation.

[@japanified]

Ahhh yes the newbish "if I hide it under the covers it is easier!" horror.

[@ionutsandu5913]

What I understood from this video is that you don't use useEffect in your components but create a custom hook whenever you need a useEffect. I don't see what differece that would make in terms of functionality although I agree it could improve code readablity

[@The14Some1]

Yeah, to me the only reason is to give effects meaningful titles

[@bullcodeprogramacion1493]

This is going to be a solid principle, isn't it? thank you for the video

[@KeganVanSickle]

So, in short, you prefer to abstract them away and write more declarative style. Good video, some considerations to think about.

[@nabinsaud4688]

Is this a new project coming in KZbin ??

[@ranadenish]

Didn't expected a clickbait from you Kyle!!! Turning off notifications until you prove yourself worthy once again!

[@mohdshahzaib4094]

Did you make this video in the early morning😀?

[@Deccoyi]

So it is readability thing and you are not acutally "not using" useffect. You are just hiding it inside a hook. Does it effect performance ?

[@sandrinjoy]

great insight broooo

[@sivasankara7467]

Hi Kyle. I came to know that you were sick. Everything clear, right? By the way, Great video.

[@samuelabiodun2256]

"Why I don't use useEffect" yet there's a bunch of useEffect in your code - Hilarious

[@thielicious2156]

This is not a clickbait like some people think here. If you misunderstood that then it's because you didn't grasp the right context. He clearly mentioned why we shouldn't use it freely in components without wrapped up in a custom hook. It's about useEffect() in "React COMPONENTS" like stated in the title and not react in general. Also he said using fetch libs like for Firebase or React Query kinda takes a lot of work from you as those libs already do the useEffect()s for you under the hood and you don't have to code all the bloated request/fetch conditions by yourself. That's all there is to say to it, no clickbait.

[@user-cd2vj8vh2z]

You got the point

[@sarahjeannexd]

man I learned useEffect from Kyle, so I sincerely hope I'm not doing it wrong 😂

[@EricWilliamsCG]

You're not. This is a code clean up video, not a don't use useEffect video.

[@wrux]

That’s a massive component and the t looks like a mess

[@josevsebastian2909]

1:56 Not to be a buzzkill, but you might wanna memoize those find on lists because otherwise you'd be searching the list on every single re-render. Not great for performance and definitely not needed, and easily rectified using useMemo

[@koko5498]

So what about React Query?

[@luiscazares8678]

Great vid!

[@muhayminkhan7063]

Can anyone tell actually what is the main issue in using useEffect in a component and why do we need to move them in custom Hooks ? Is it because of a performance issue ?

[@davorjovanovic7174]

No, just better readability.

[@muhayminkhan7063]

@@davorjovanovic7174 Okay that's great

[@awekeningbro1207]

a good react developer hides implementation behind hooks

[@awekeningbro1207]

a dirty react developer spams useEffect wherever they please

[@andiyonotandang656]

I'm checking my playback speed while watching this.

[@AngusMcIntyre]

Is it fair to say that the golden rule is still 'wrap infrastructure code in domain abstractions'?

[@Trazynn]

Can you shed some light on random image galleries?

[@Stormface16]

UseEffect queues? Is there any reason why useQuery was not used for this?

[@iewebdevdes]

You're using Chakra-ui 😃. Nice!!

[@multiwebinc]

Wow, lots of hate for this one. I actually think it's a good idea extracting your useEffect calls to custom hooks for better separation of concerns and code readability.

[@janpawedwa4590]

This video should be named "how to obfuscate your code for job security".

[@allanperalta7984]

I think the context of the tutorial is confusing. First of all, useEffect is one of the most useful hooks in React, in fact it is used to connect to an external systems such as DOM api(s) or third party libraries. The author probably trying to convey to refactor codes such that calling custom hook encapsulates implementation details of useEffect, but still doing so, developer needs to understand these details in order to utilise correctly.

[@thatsinteresting8479]

Please make a video on react query to that would be very helpful

[@davi-alves]

Huge components should break down IMHO

[@thechoosenman]

Actually, an appropriate title would be Custom Hooks in my React Component would sound the best. best practice of any programming starts with the naming as it will open the readability of the code base and the product domain.

[@user-jn8eh1sq9g]

Although a lot of people in this comment section didn't really get it, sometimes on KZbin you need polarizing titles like this for exposure. It's immature to be triggered by clickbait nowadays that the KZbin algorithm is completely screwed up. But I do think it can be somewhat misleading for beginnners. Imho this pseudo-clickbait can be forgiven by the fact this video is actually good, it's showing separation of concerns and nicely demonstrates how to abstract useEffect into reusable calls. For the naysayers, if you splatter repeated useEffect calls for the same basic code structure all over your codebase you're not very much respecting the DRY principle. Don't be that guy... if you're repeating the same useEffect structure, do your team and yourself a favor and create a custom hook goddamn it.

[@dbaby3288]

Brb going to remake my web app

[@smally5739]

thats one gigantic project