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.
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.
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.
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.
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.
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.
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...
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.
@@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.
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.
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.
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 }
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?
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.
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
@@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 ;-)
@@DaveTheDeveloper 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.
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.
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
@@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
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.
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.
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?
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
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.
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.
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.
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.
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
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 ❤
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.
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.
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
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.
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.
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.
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.
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.
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.
chill bra, this is for illustration purposes only. I assume you're an inexperience programmer who just insta copy pasta. Once you get the idea, you implement it on your own not copy line by line.
i also noticed a ton of... TODO. sometimes you tolerate crap in order to realize the larger feature in order to dogfood the idea before committing to it. basically, using tech debt responsibly. just like real debt, it's a benefit if properly managed
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 👍
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 🎉
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!
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
Great advise, Kyle! Thanks for the video! I am using this approach for 2y now, and I can confirm that moving useEffects into a separate dedicated custom hook files is way cleaner and readable. In a nutshell - move the business logic into a custom hook file, and leave the component be a component, nothing more, just a data consumer.
When a framework provides a feature, I tend to use it to death - otherwise what's the point of using said framework/library. Now after an year working on a react+redux project where I used a lot of useEffect, I regret everything. Imagine having to change the behaviour of a component and having a bunch of effects firing that you have to find manually by sheer luck or brute force. It's hell!!
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.
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.
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?
Just 2 minutes into the video and "useEffect is ugly, is hard to read..." what about that monster component with hundreds of jsx lines and tons of helper functions that could probably live elsewhere, thank you but I'll stay with useEffect, and custom hooks have been out there since day 1 when hooks first came out, did you just discover water is wet?
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.
This is a refactor of useEffect. Not replacing them by another method. I do this at all the time When i work with requesting data, timer… basic things. Nothing special.
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
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?
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
“See I’m not using any useEffects… just a few down here, but that’s all.” 😂 Lol love you still. UseEffects are mandatory, no way around them, until we use server components
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 ?
Your code style gives me anxiety Kyle. Readability is low and file size is big. IMO it gives a sense of dread if you're not familiar with how its structured. I'd prefer smaller files for separation of concerns. I've been writing react for 8 hours a day for 4 years though.
If you have unique hook logic to a component and break it out to a custom hook just to make it less to read in the component, then it suggests that your component is wrongly designed. Components should be small and easy enough to comprehend to have useEffect without being difficult to read. The only reason to make custom hooks is if it is used by multiple components, not one.
Although a lot of people in this comment section didn't really get it, sometimes on TH-cam you need polarizing titles like this for exposure. It's immature to be triggered by clickbait nowadays that the TH-cam 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.
"having tons of useEffects in your components makes your code harder to parse and understand" - I could not disagree more. The useEffect hook is incredibly simple and easy to read in a well-written component because it represents exactly what properties you expect to change. It's also very minimal and forms an easy-to-recognize pattern. Using external helper functions to wrap useEffect removes the simple clarity of that pattern from the component and makes it more difficult for another developer to jump in and work in the codebase. I am all for helper functions, and often I use these inside my useEffect hooks to keep the hooks section of my component light and readable. Idk... Coming up with creative new ways to circumvent common patterns may feel cool but it often does more harm than good for the project and the team working on it.
I usually learn something from your video. This time its nothing :| imo, Abstracting in many cases makes more complicated code (for testing also). If the code complexity is complicated then there is something fundamentally wrong with the code or the business logic. Personally i do move the data fetching part away from the component and try to make it as pure as possible. Mostly when I look at the code you were showing, i am like , man.. i dont want to own that code base
If you don't mind me, I'm interested in details. I'm coming from some video conferences that do embrace abstraction, in fact way more to the point that functions are about 5 lines long and each line has a function with a self describing name. So you wouldn't be into that? And how is testing made harder? I think of it like, the things that will be tested, they have their insides extracted, but they're tested the same way. I can't comment on the methodology because I just tried the short function technique yesterday first time. It relies a lot on jumping to definition with IDE key bindings. But I'm interested in your view, for front end at least.
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.
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.
based
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.
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.
@@petarkolev6928 read "my personal opinion". Also, I'm right.
This one is kinda a clickbait. You still use it but just in custom hooks.
@@christenw.1726 gz, u just described what clickbait means
@@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?
@Thelukkest Maybe, but if you said “This is why I don’t drink coffee,” with an explanation, I would understand, what you mean.
I agree, title and thumbnail are misleading
Yeah this is a non-video. Not up to your usual standard.
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.
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
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.
@@_HappyHippo but we all know that component should be easy to read, not just component with useEffect hooks.
@@francarloscastillorobles3618 Yes it is obvious.
how to hide that you are using useEffect
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.
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...
@@khaledsanny4817 Hooks are definitely extensions of react components
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
He is RIGHT, he said dont use it in REACT COMPONENTS.
I agree that he provides useful information in my view, however, this title leads newbies to misleading of the useEffect().
2016: Stop using jQuery
2018: Stop using Angular
2020: Stop using class components
2030: Stop using your PC, return to monke
2040: use jQuery
🤣🤣🤣🤣
:v 2022 stop using CRA
I definitely still prefer Angular. :)
Angular will be deprecated soon in the future because it's no longer maintain. React will wrapped to the world
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.
Thank you. Came here to say this.
Does JH have a specific video about hook gotchas? Discovered him recently and really like his videos.
@@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.
@@javajoint Understandable, I think the same. I subscribe to Kyle's newsletter and always try to check out his latest videos.
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.
TL;DR “wrap useEffect in custom hooks for better separation of concerns”. Much easier to understand and use.
Can't wait for the next video named "Stop using React in your React projects". This one is not clickbait enough 😉
ya, pure javascript for the win!
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.
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.
I think it's enough. UseEffect makes uncertain rerender. And it's for good to avoid it.
Why I Don’t Use useEffect ... uses useEffect
yeah, you can find this nasty disease everywhere
Would be great if you also did a followup video on how to extract the useEffect and create a custom hook
:( Please update the title of this video. It’s misleading
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
}
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?
похуй
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.
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
@@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 ;-)
@@DaveTheDeveloper 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.
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.
exactly what is in my head after watching the vid.
readability is number one, and only then everything else
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
@@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
@@panicbox4609 also when you have 5 super complex use effects in a component, maybe the component is doing too much?
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.
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.
No it doesn't. Writing a semantically titled hook lets you know exactly what the hook does.
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?
That's my immediate thought as well.
I think kyle made this video for cleaning up the code and just structuring it properly.
@@the-iter8 100% clickbait
@@andresmontero7481 Of course it is
But it will components very reusable. The logic layer and ui layer separated in twi pieces.
The way you explain things and your voice….. bro your amazing!!! Keep up the good work
*sees title*
wtf is meaning of this now?
most of his vids are for dumb people who don't know what they are doing, some people take him seriously.
@@yakmoon Not true at all...
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
right, Kyle is noob
@@harmez7most of the Internet teacher haven't seen properly written production code, as they only are Internet teachers
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.
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.
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.
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.
just another clickbait video
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
I think CoderOne's approach on writing a video title is much better. SOLID
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 ❤
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! :)
@@TabuHana Aah good shout, so the custom hook can access a Context that holds some global state?
@@robwatson826 ofc
Didn't expected a clickbait from you Kyle!!!
Turning off notifications until you prove yourself worthy once again!
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.
Looking @ some of the comments you quickly realize that.... having an opinion will always offend somebody. Thanks for the video and interesting take.
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.
Kyle rocks! Keep up the good work man! (I learned a lot from the comments as well :)
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
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.
You got the point
it's rather a question about the splitting of your business logic from your html, just like you split styles from one
This is exactly why i prefer using react-query instead of Redux. The logic is well hidden, easy to control and easy to implement.
No more useEffect just to fetch data. Sadly it's still pretty much underrated with companies insisting on hiring people with Redux experience 😴
@@ninhdang1106 I just completed a contract using react-query and now I'm dreading using Redux again.
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.
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.
This actually makes sense and is worth considering.
Side note: Can we also see you play that guitar though 👍
would love to see you do a walk through of one of these projects explaining the code, that would be a great course
Responding to events in event handlers and using react query mostly reduces the need for useEffect even in custom hooks.
For me it only makes sense to create custom hook if you are gonna use it in multiple places
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.
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.
Keep using useEffect() like it is meant to, putting it away in custom hooks is going to make your code way more difficult to debug.
the custom hooks arent reusable at times because there might be a different data source aswell?would typescript allow that generic contraint?
Just almost thought it's something new .. this is just use effect with extra steps
WDS is not saying don't use useEffect. He's saying try your best to put them into custom hooks because it affects legibility of components.
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.
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
@@ninhdang1106or just write comments?
Kinda disappointed: hook is not in a separate file, there's a mix of ES6 and no-ES6 syntax, useless fragment wrapping the return statement.
chill bra, this is for illustration purposes only. I assume you're an inexperience programmer who just insta copy pasta. Once you get the idea, you implement it on your own not copy line by line.
@@ProtectedClassTest those dammed copy pasta's
@@ProtectedClassTest
What do you mean? I think his points are valid, there is not really that much of a consistency in the code.
True, looks kinda sloppy
i also noticed a ton of... TODO. sometimes you tolerate crap in order to realize the larger feature in order to dogfood the idea before committing to it. basically, using tech debt responsibly. just like real debt, it's a benefit if properly managed
"Use custom hooks when possible" wouldn't have gotten my attention. Well done.
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 👍
I'm checking my playback speed while watching this.
"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.
"Why I don't use useEffect" yet there's a bunch of useEffect in your code - Hilarious
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 🎉
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!
The first component he shows is a monster needs to be broken up closed the video right after. Poor recommendation.
Alternate title: why I always refactor what's inside my useEffects
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
Yeah, to me the only reason is to give effects meaningful titles
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🙏
Great advise, Kyle! Thanks for the video!
I am using this approach for 2y now, and I can confirm that moving useEffects into a separate dedicated custom hook files is way cleaner and readable.
In a nutshell - move the business logic into a custom hook file, and leave the component be a component, nothing more, just a data consumer.
When a framework provides a feature, I tend to use it to death - otherwise what's the point of using said framework/library. Now after an year working on a react+redux project where I used a lot of useEffect, I regret everything. Imagine having to change the behaviour of a component and having a bunch of effects firing that you have to find manually by sheer luck or brute force. It's hell!!
I'm currently experiencing this. About to refactor some code thanks to this video. Will make this a habit from now on
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.
Hi Kyle. I came to know that you were sick. Everything clear, right? By the way, Great video.
Ahhh yes the newbish "if I hide it under the covers it is easier!" horror.
sugoiii
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.
That’s a massive component and the t looks like a mess
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.
Did you make this video in the early morning😀?
So, in short, you prefer to abstract them away and write more declarative style. Good video, some considerations to think about.
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?
This video should be named "how to obfuscate your code for job security".
It's "I don't kill people, but I hire someone else to do it for me" kind of situation.
Just 2 minutes into the video and "useEffect is ugly, is hard to read..." what about that monster component with hundreds of jsx lines and tons of helper functions that could probably live elsewhere, thank you but I'll stay with useEffect, and custom hooks have been out there since day 1 when hooks first came out, did you just discover water is wet?
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.
You're using Chakra-ui 😃. Nice!!
WDS.... "Why I Don't Use useEffect In My React Components"
Also WDS.... "I use useEffect 16 times in this entire project"
This is a refactor of useEffect. Not replacing them by another method. I do this at all the time When i work with requesting data, timer… basic things. Nothing special.
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
Is it fair to say that the golden rule is still 'wrap infrastructure code in domain abstractions'?
Huge components should break down IMHO
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?
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
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 ?
man I learned useEffect from Kyle, so I sincerely hope I'm not doing it wrong 😂
You're not. This is a code clean up video, not a don't use useEffect video.
“See I’m not using any useEffects… just a few down here, but that’s all.” 😂 Lol love you still. UseEffects are mandatory, no way around them, until we use server components
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 ?
Kyle has reached a point of understanding that he should come up with his own framework or library. 😂
He actually has a tutorial for creating our own Javascript framework
So you DO use useEffect, just not in the main component but in the custom hooks. Got it.
Your code style gives me anxiety Kyle. Readability is low and file size is big. IMO it gives a sense of dread if you're not familiar with how its structured. I'd prefer smaller files for separation of concerns. I've been writing react for 8 hours a day for 4 years though.
the point is to not stop using useEffect, but put them in a hook out of the component ?
This codebase looks not very Clean. Before moving use effect out, start making your components dry and clean
If you have unique hook logic to a component and break it out to a custom hook just to make it less to read in the component, then it suggests that your component is wrongly designed. Components should be small and easy enough to comprehend to have useEffect without being difficult to read. The only reason to make custom hooks is if it is used by multiple components, not one.
Although a lot of people in this comment section didn't really get it, sometimes on TH-cam you need polarizing titles like this for exposure. It's immature to be triggered by clickbait nowadays that the TH-cam 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.
can you provide the github link for this repo
Please make a video of full lage scale app with multiple endpoints using very less useffect
"having tons of useEffects in your components makes your code harder to parse and understand" - I could not disagree more. The useEffect hook is incredibly simple and easy to read in a well-written component because it represents exactly what properties you expect to change. It's also very minimal and forms an easy-to-recognize pattern. Using external helper functions to wrap useEffect removes the simple clarity of that pattern from the component and makes it more difficult for another developer to jump in and work in the codebase. I am all for helper functions, and often I use these inside my useEffect hooks to keep the hooks section of my component light and readable. Idk... Coming up with creative new ways to circumvent common patterns may feel cool but it often does more harm than good for the project and the team working on it.
Would using a context be better or is that different in some way?
It's a good advice. Thank you
I usually learn something from your video. This time its nothing :|
imo, Abstracting in many cases makes more complicated code (for testing also). If the code complexity is complicated then there is something fundamentally wrong with the code or the business logic.
Personally i do move the data fetching part away from the component and try to make it as pure as possible. Mostly when I look at the code you were showing, i am like , man.. i dont want to own that code base
If you don't mind me, I'm interested in details.
I'm coming from some video conferences that do embrace abstraction, in fact way more to the point that functions are about 5 lines long and each line has a function with a self describing name.
So you wouldn't be into that?
And how is testing made harder? I think of it like, the things that will be tested, they have their insides extracted, but they're tested the same way.
I can't comment on the methodology because I just tried the short function technique yesterday first time. It relies a lot on jumping to definition with IDE key bindings. But I'm interested in your view, for front end at least.
I don't see the value in hiding the effects