Why I Don’t Use useEffect In My React Components

[@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.

[@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

[@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.

[@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().

[@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.

[@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

[@JulianHarris]

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

[@ken_bekov]

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

[@hexada_ghostemane]

ya, pure javascript for the win!

[@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.

[@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.

[@superchrishovids]

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

[@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 }

[@FirstYokai]

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

[@harmez7]

yeah, you can find this nasty disease everywhere

[@SurajSingh-fg6eq]

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

[@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?

[@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.

[@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.

[@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...

[@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

[@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]

похуй

[@DaveTheDeveloper]

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]

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

[@vlaxis3359]

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

[@artificialsoundwaves]

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

[@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

[@troygooden2525]

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

[@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.

[@ranadenish]

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

[@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.

[@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.

[@andiyonotandang656]

I'm checking my playback speed while watching this.

[@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

[@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.

[@nickwoodward819]

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

[@loktar00]

The first component he shows is a monster needs to be broken up closed the video right after. Poor recommendation.

[@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.

[@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

[@truceheat1671]

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

[@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.

[@nandantyagi]

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

[@seyiobafemi6915]

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

[@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🙏

[@seondongkim]

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

[@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.

[@unlomtrash]

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

[@dbred67]

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

[@Bluesourboy]

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

[@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 👍

[@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!

[@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.

[@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

[@unknownguywholovespizza]

​@@ninhdang1106or just write comments?

[@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.

[@蘇冠庭-k8y]

You got the point

[@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 🎉

[@Cloud9er]

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.

[@wrux]

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

[@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.

[@jorisebbelaar]

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.

[@pontiacgtx4801]

the custom hooks arent reusable at times because there might be a different data source aswell?would typescript allow that generic contraint?

[@sivasankara7467]

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

[@thecyberhobbit]

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

[@japanified]

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

[@thedigitalceo]

“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

[@heddshot87]

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

[@KeganVanSickle]

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

[@petarkolev6928]

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.

[@pawsomegreatdanes9380]

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?

[@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.

[@sanoaakha]

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.

[@mohdshahzaib4094]

Did you make this video in the early morning😀?

[@samuelabiodun2256]

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

[@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?

[@davi-alves]

Huge components should break down IMHO

[@NotesNNotes]

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.

[@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

[@drimodramo6567]

So you DO use useEffect, just not in the main component but in the custom hooks. Got it.

[@mr.mike678]

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

[@ret-si]

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.

[@AngusMcIntyre]

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

[@kylebillings3587]

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.

[@HaxxBlaster]

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.

[@melchizedek79]

Kyle has reached a point of understanding that he should come up with his own framework or library. 😂

[@GMPGIRI]

He actually has a tutorial for creating our own Javascript framework

[@janpawedwa4590]

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

[@iury664]

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

[@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.

[@cojsaideptrai3999]

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.

[@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?

[@iewebdevdes]

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

[@domjurkus5805]

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.

[@ProtectedClassTest]

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.

[@marcjoyce765]

@@ProtectedClassTest those dammed copy pasta's

[@Dev-Siri]

​@@ProtectedClassTest What do you mean? I think his points are valid, there is not really that much of a consistency in the code.

[@Saru-Dono]

True, looks kinda sloppy

[@adambickford8720]

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

[@ThatMadOne]

sugoiii

[@gearmeout]

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

[@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

[@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

[@MiguelFelipeCalo]

Next level is to modularize that, angular.

[@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 ?

[@erikoffenbach3044]

This codebase looks not very Clean. Before moving use effect out, start making your components dry and clean

[@SithLordBishop]

useEffect made me hate react. 100% agree it is so easy to overuse useEffect especially when starting with react hooks.

[@SidneiMV]

Web Dev Simplified. the king of clickbait.

[@vincend]

It's a good advice. Thank you

[@Kris96431]

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!!

[@NphiniT]

I'm currently experiencing this. About to refactor some code thanks to this video. Will make this a habit from now on

[@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.

[@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 ?

[@nabinsaud4688]

Is this a new project coming in KZbin ??