Yeah I watched about half of this and at no point did they actually disagree, Theo just made up some imaginary argument based on where he felt the presentation was going and then ranted against that lol
Exactly, it's like please stop pausing to argue condescendingly about a point no one ever made. I'm a subscriber and I like a lot of this content, but man you should almost take this video down and repost one where you don't spend half the video totally in left field.
The irony is that Theo's assuming argument was _actually_ in bad faith. To my understanding, David brought up the React lifecycle methods _only_ to explain them in order to showcase how folks are applying useEffect to mirror lifecycle methods when they should NOT be doing so.
About "doing youtube well", as another very opinionated person with a big mouth I can relate but IMO (here *I* go) live streaming these videos is a bad idea for you. I'm sure if you'd watched his entire video first, kicked around your thoughts with some friends over lunch, then made the video, you would have spent a lot less time reacting to points he never made, could have built on the points you agreed with (all of them I think), come up with more interesting things you didn't think of on first reaction, realized that character attacks because of 1 line in one example are probably unwarranted (although calling them out as mistakes is fair), and generally made a video *way* more interesting and less frustrating for your viewers.
Idk why everyone is saying you have such a different perspective. I think overall David’s talk was pretty good and imparted the correct mental model and strategies to help a lot of people struggling with useEffect hell, and that you largely agreed
Aspiring junior dev here. Really glad this was recommended to me as I got to hear an opposing view. As a newbie I'm prone to blindly accept info I get from presenters with more experience. Great content - very confrontational for my liking 😅😂 but great nonetheless 💯 Edit: to be fair, after listening to the Twitch team rant... that does sound pretty stupid 🤷♂️ justified rant imo lol
@@DanKaschel you're not wrong, but my point was that it's nice be able to view the presentation from the perspective of "this is debatable" rather than a non-opposable standard.
I love the call out on `If you are doing something inline in your component that has a bunch of complexity to it ie utilising multiple hooks, external state and computing new state'. Exposing the state of a loading modal/spinner comes to mind. Abstract it into its own hook and call it something that makes sense. It Keeps your JSX/TSX code leaner. Makes testing easier (testing hooks and functions is easier than testing components) and makes switching technologies easier. This is good stuff.
I wrote a chatbot engine SDK with xstate, which is now used in production. The issue with xstate according to my former colleagues using xstate configs is clearly developer experience. The biggest pain point to me is that is incredibly hard to follow state transitions in xstate, because of everything is tied together with strings. You can't just simply jump with your IDE from one state to another by clicking around in the state machine config. If the config grows with your app it quickly becomes hard to maintain. You will also need a lot of helper substates, which confused a lot of devs. My take on it: use state machines for simple or mature stuff. Don't use it when you need to heavily iterate over the code base for feature adaption
This was annoying since he assumed so early on that the presenter was saying it was better with life cycle function. He never says that. Half of the video comments were a waste of time.
I think one of things that should have been disclosed at the very beginning of David's talk is that he's a founder and a major promoter of XState, so he will take each and every opportunity to convince you that you need it in your project. So yeah - built-in hooks are bad, XState is good. I find it rather hard to believe that he's very objective in his talk, it feels like he just uses it as a space to promote and find use case for his library.
I fully agree. He's using examples with poorly written code, barely functional code I might add, just so he can make XState look better. The issues that exist within React are more often than not due to asynchronous events and people simply not understanding the framework. You can't save yourself from idiocy. Even less so when you're the idiot yourself. That's part of why I dislike React however, because some hooks seem like what you should use when it's not at all what should be used. I want to add that this dislike is honestly easily fixed through better naming conventions.
I am glad you came with this. I criticized the talk with a comment on his video. Since he is only telling not to use useEffect but he did not come up with any!! solution how to do better, !... So literally the question everbody was waiting for in the talk... "How the f+"*ç should we fetch data"? (At least I expected something like react-query) or what else?
The speaker’s `ComponentDidMount()` + coverage of the legacy LC methods were unnecessary, since everyone agrees they sucked. The criticisms of `useEffect()` had some good points, but the examples were generally oversimplified, and served disingenuous at times. I think the talk was poisoned by hyperbole. The speaker was trying too hard to be sensational instead of making simple good points.
Hey Theo. Love your vids, they resonate a lot with my work as a webdev. I am really interested in knowing how would you have re-architectured the ad section so that issue does not happen? Maybe make a video about it?
Is this video (that pretends "reacting" about the another video) paid by Facebook to justify the anoying changes made to the API each year? Their marketing is so good, I know because we have been fooled multiple times that their library and approach is best, even when they had software patterns not removed from license they still managed to make us use it anyway. They should be more fair with the community rather than compensate it by convincing us through marketing. It seems that now their best defense is mocking the people that criticize them. When we will switch to Vue, Angular or Svelte they will finally figure out that marketing instead of fairness towards community was a bad strategy.
"I always remind myself to not forget--it's all these similarly bizarre, and unique choices, that make React...React" ruclips.net/video/lGEMwh32soc/видео.html With Svelte and Solid coming up, and Vue 3's super composability (similar to React/Solid) and amazing, Svelte-like DX, devs no longer have to be held hostage by a React that really doesn't see the need to treat its dev community with care, love, and respect because it is so dominatingly popular. My prediction: React will have a presence for a long time, like jQuery, but also like jQuery, no one will want to learn it in about a year and a half or two. Vue will keep rising, a ton of talent will move over to Solid, and Svelte will be especially popular at the web site end of the website-web app spectrum. It's sad to see React devs' inner conflict with how much they hate how React makes their lives miserable, then trying to convince them that React was the right choice. Maybe at the time it was right, but things have moved on, while React keeps doing crazy stuff like rolling out good docs 3-4 years after hooks were released. That's insane. Oh yeah, and it looks like Vue Vapor (no v-dom strategy like Solid/Svelte) coming up, Vue will become even faster (Vue 3 got a lot faster). And, as one can see with the Vue 2 to Vue 3 migration, they will do a lot to make that migration smooth and as pain-free as possible.
I love the idea of xstate but in practice modelling every state of your app with a name is probably too much. Narrow down to just a component and you should have at most a few named states and values that go with them. You can manage it with form state and a few overall enum/constants without injecting another state library.
Hi Theo, could you recommend a React app example (or video / tutorial perhaps) to orient with for state management? I agree that state machines can be overkill, but not sure how to use the alternatives correctly.
Thank god I use other UI frameworks rather than React, people are still debating useEffect vs class based components? LOL No wonder you love React. You like to use the f*** while _Reacting_
Can anyone explain why useEffect should be used rarely and what should be done instead? If I want some state to change because some other state changed, should it just occur on every render (until it is no longer performant, where useMemo could be used)?
Why do you want to change state because of other state? Usually, state changing is because of an action, i.e. clicking a button. If clicking a button increases `count` by 1, and we want to display `count` squared, we can redefine `squareCount` every render for cheap. If you're waiting for data to come back and then transforming that data i.e. `fetch().then(d => setState(d))`, transforming and re-storing via Effect is a NASTY anti-pattern. All state that an action changes should be changed in the action. That's the part both David and I agree on here
Theo, can you please react to the "Looking at Xstate's source code" video on the channel by KevinGhadyani ? David is on there and I think the example picked there explains a much more valid use case for XState. It seems like he picked an example at the end that is probably better served by things like rtk query, react query etc. But this kind of rich, complex client side UI feature like presented in the conversation with Kevin, is where Xstate and react (as an app not just a "website") can really shine. I also think the video Kevin made about hooks and especially the useEffect hook deserves a lot more attention. He explains the useEffect hook as "memoization for side effects". That is a very unique way of looking at things, but it is essentially what is happening. Why apply the concept of memoization only to data structures and function calls? In the end an effect is also just an async function. This mental model can turn effects from this scary alien thing into something known and manageable. TLDR: maybe the critique of useEffect isnt in good faith. The audience probably knows it is not that serious, because it just serves as stylistic device to carry the conversation from the wider react ecosystem to the topic of XState. 😅 There are better examples for presenting the use case of XState. Please take a look at them tooo 😀👍
i wished i have learned react first rather than vue,. learning react after vue makes react a mess. everything a LOT easier with vue. a lot flexible too. well these learning curve i have to take :^)
It feels to me like you misinterpreted the initial part of the talk as preferring component lifecycle hooks to useEffect; your rant(s) on that, while fun and quite correct, felt unneeded. No hate though, as I totally agree with your overall conclusion, and it's probably a good example of why his framing and presentation choices were ill-advised.
As a beginner I didn't even notice there was a problem with useEffect... I did notice sometimes it triggers more than one time, so I use the flag workaround. Question. I use useEffect to fetch data when the page first loads "useEffect(( )=> { fetch( ) }, [ ])" and put a spinner up while it fetches. Is this bad? I can't think of a way to do it without useEffect.
This is why reaction videos are almost always a bad idea, specially if you feel very passionate about the topic, since you'll tend to rant before having the whole picture
I know you have a video on Solidjs, but I curious as you mentioned: "Svelte will only be as good as what Rich feels like doing" , what's your opinion on Solid Js?
Spicy video, thanks for sharing your thoughts. I'm certain that a lot of people are learning things from this, myself included, even if you might feel like you are just ranting
As a relatively early dev, I think the tip on when to use useEffect at 12:45 is super useful. I totally agree that you should always have a variable in the dep array to better control when the hook triggers, but considering where you’re placing the hook is also important too.
The react-query counter-example doesn't hold up for me. You aren't using effects and you are putting the state mutation in event handlers, which seems to be the whole point of the talk. Perhaps I am misunderstanding.
Hi Theo! I've been watching you since the pokemon video came out. You're perhaps my favorite dev so far, like a chunk of fresh air in suffocating world of frontend (and React ecosystem especially). I am React dev myself, and it's really exhausting to see dozens of wheel inventions for even the simplest things, trying to glue together all of them, project to project. For the past year I've been working on a project with a lot of features, states, async logic and 100+ API endpoints. Things I struggle the most with are state and complex effects (which I have a lot). I use RTK and sagas, try to keep models apart from views, but I don't like how it turns out, the project is still a huge dump in my eyes. I don't even know what I wanted to ask at this point (probably "how would you manage big amounts of complex async logic that is spread among components"). Just wanted to complain a bit and say that you're a legend and your videos help me a lot. ❤
What I don't understand is why so many people think useEffect is anything but a convenient variable change listener. That's literally all it does. The only thing that warrants a "huh?" is that there's a dismount part that happens, which is obvious since your variable is yeeted and deleted when the component goes byebye. It's not so obvious that it happens and is why I believe the useEffect hook should require a cleanup function, just as it should require a dependency array.
I'm a junior front-end developer from South Africa and I love your content, I'm still trying to understand a lot of the concepts you brush over but it's definitely increasing my knowledge base. I've been working with React for about a year and a half now, about 3 months into NextJs. I'm still not comfortable with TypeScript but hope to get there soon.
David's most arguments are like: "bread is shit, because its not butter" and "electric stove is shit, because it doesn't have a fire". Some conclusion: "electri stove doesn't burn"
45:14 this really triggered me and I started to aggressively type a comment and almost just closed the video but by the end of the rant you walked it back to distinguish sites and apps. All calm now, but I hope you work on your delivery because with the multiple instances of immediate condemnation and shit talk it was walking the line of unbearable.
I died a little when he said "this is not haskell, what are we doing?". Javascript in a functional style is so good wym a function inside a functions is bad?
Confused why you fixated on the class components slide and kept repeating “bad faith” claims. It was mentioned for like 30 seconds of the talk, not at all the main point. Felt like you were arguing with strawman points no one was making
I am so confused by ur point of view, at some point u imply that useEffect is bad (but the old alternative is worse) and almost in the same sentence u order us to be happy with it? Disclosure, i am the author of xania view library (see krausest js benchmark) heavily inspired by react and I am looking for the good parts of react and 'useEffect' does not seem like it.
Whilst I agree with most of David's talk, Theo touches on almost all the parts of the talk that I took issue with, especially the good use cases that useEffect was intended for. Yes, there are some points David brought up that useEffect shouldn't be used for, but it feels like a lot of the other points he brought up were made either in bad faith or the alternative use-cases were not made clear beforehand. Loved this video Theo!
I have been developing for web for 25 years. Everything I worked with in frontend so far has been more of a bandaid for a broken system. And unfortunately for me React is no exception. I won't be shilling something else but there are much better technologies out there in means of developer experience. Honestly the name of the hook useEffect derives from handling side effects. Even that should be telling for an entire generation of puppeteering requirements of state management.
It was about here when in the original talk I couldn't take David's BS anymore. XState is cool, but react itself is already a kind of state machine, so for normal use cases, you really really don't want to use it
I am fascinated. Please elaborate on how I could useEffect for something like a data fetch without a deps array of some form in a way that is more “readable”
I've said exactly this, you never want the case do something on every render. It's almost like it should be a different hook useRender and useEffect(() => something) should strict equal useEffect(() => something, []). Apart from that I hate the use of the closure like this, it causes spaghetti code. In most systems passing variables explicitly is much better, react even demonstrates this with props...
Just cause the lifecycle components were bad doesn’t mean useEffect is good. Why should you keep your own dependencies? Can you possibly be better at that than a computer. At work that’s all I see all day after we moved to react, issues with useEffect. It’s complete trash.
Effects aren't for fetching data!!! Unlike Angular, you don't have to use every piece they give you for every problem you have. React Query is a great library for managing your fetches, async calls, etc Tbh it sounds like you need help managing that so def check it out :)
Can someone change my mind on state machines? I think they are backwards evolution in some way. They do exactly the same thing if else statements do in every programming language. I can imagine an alternative universe where state machines were invented before if else statements, and in that universe, if someone was able to invent if else statements their pitch would be: 'it's just like state machines, but look at how much less stuff you can write.'
Didn't realize if-else statements were async 😂 Seriously though, it sounds like the things you're building aren't particularly interactive. When an "action" or "event" (external, user-triggered, etc) can interrupt your logic, handling that isn't if-else-able. 90%+ of the time, React-Query handles the async case well enough to bring you back into if-else land. For websockets, chat servers, video call apps, games, and pretty much everything other than "fetch", state machines are essential. You should try building a game :)
@@t3dotgg That is very true. Apps I've been working on don't often rely on websockets so much that it would cause a problem like that. I'll keep that use case in mind next time I read about state machines. Thanks Theo for replying.
Unrelated but I've been binging your videos the whole day. I feel like your content is exactly what I was craving at this point in my career. Keep It up!
I watched David K's talk like days ago and after watching this I have some different thoughts: Class component is easier for most of the developers to understand, just to know the apis and you are almost good to go; While functional component requires not just the mental model of [state] => UI, but also annoying re-renders when logic goes complex. I don't think it's about good or bad, cause they both serve well when needed. But yes I do agree it's much better from a code architectural perspective transitioning from class component to functional component. So I actually like how he represents at the first minutes by showing the not totally right but really easily understandable comparisons. And by the way what's the use cases that useSWR are bad? And what is the difference with useReactQuery? @44:44
If you create an API and name is useEffect(), then get mad if people use it for side effect management, you are doing something wrong. React has the most idiotic function names. Sometimes I feel like, we get these names from someone who just really want to show off how much jargon they know. While not even being correct on their meaning.
![Eminem - Somebody Save Me (feat. Jelly Roll) [Official Music Video]](http://i.ytimg.com/vi/Vwa0HenQMi4/mqdefault.jpg)
The thing that drove me craziest about this presentation was the font that made parenthesis look like square brackets.
I literally wrote up an example with brackets just to make sure I wasn't losing my mind that it was an impossible syntax lmao
Double brackets are p sweet
OMFG that's what that was, I was tripping real hard on that, that font is nasty.
That's what he should've ranted about. I mean, who does that? I hope it's not his theme font.
That was driving me nuts 🤣🤣🤣
His round brackets sure look squary
Ikr that bothers me
Yeah he probably has never actually coded before
i also was confused
red flag
Never trust a squircle
did I miss something? when did the presenter suggest old class components lifecycle effects were better? I don't see any bad faith argument
Yeah I watched about half of this and at no point did they actually disagree, Theo just made up some imaginary argument based on where he felt the presentation was going and then ranted against that lol
100%. I think there was a misunderstanding with what the presenter was saying and then kept going back to it for the whole video
Exactly, it's like please stop pausing to argue condescendingly about a point no one ever made. I'm a subscriber and I like a lot of this content, but man you should almost take this video down and repost one where you don't spend half the video totally in left field.
The irony is that Theo's assuming argument was _actually_ in bad faith. To my understanding, David brought up the React lifecycle methods _only_ to explain them in order to showcase how folks are applying useEffect to mirror lifecycle methods when they should NOT be doing so.
About "doing youtube well", as another very opinionated person with a big mouth I can relate but IMO (here *I* go) live streaming these videos is a bad idea for you. I'm sure if you'd watched his entire video first, kicked around your thoughts with some friends over lunch, then made the video, you would have spent a lot less time reacting to points he never made, could have built on the points you agreed with (all of them I think), come up with more interesting things you didn't think of on first reaction, realized that character attacks because of 1 line in one example are probably unwarranted (although calling them out as mistakes is fair), and generally made a video *way* more interesting and less frustrating for your viewers.
Hey. Love the no bullshit energy you give off in space like this where i feel everyone just follows or keeps quiet. Subbed to the channel.
I feel like I've seen this guy and his free flowing hair before, but not on this small channel.
Idk why everyone is saying you have such a different perspective. I think overall David’s talk was pretty good and imparted the correct mental model and strategies to help a lot of people struggling with useEffect hell, and that you largely agreed
Aspiring junior dev here. Really glad this was recommended to me as I got to hear an opposing view. As a newbie I'm prone to blindly accept info I get from presenters with more experience. Great content - very confrontational for my liking 😅😂 but great nonetheless 💯
Edit: to be fair, after listening to the Twitch team rant... that does sound pretty stupid 🤷♂️ justified rant imo lol
In fairness, the views didn’t really oppose much. They mostly agreed except on some details and on how the information should have been presented.
@@DanKaschel you're not wrong, but my point was that it's nice be able to view the presentation from the perspective of "this is debatable" rather than a non-opposable standard.
@@DanKaschel I thought the same thing. Lots of rage only to mostly agree. 😂
I love the call out on `If you are doing something inline in your component that has a bunch of complexity to it ie utilising multiple hooks, external state and computing new state'. Exposing the state of a loading modal/spinner comes to mind. Abstract it into its own hook and call it something that makes sense. It Keeps your JSX/TSX code leaner. Makes testing easier (testing hooks and functions is easier than testing components) and makes switching technologies easier. This is good stuff.
He wasn't saying old style component lifecycle events were better than hooks. Was merely giving context, history and highlighting limitations.
I wrote a chatbot engine SDK with xstate, which is now used in production. The issue with xstate according to my former colleagues using xstate configs is clearly developer experience.
The biggest pain point to me is that is incredibly hard to follow state transitions in xstate, because of everything is tied together with strings. You can't just simply jump with your IDE from one state to another by clicking around in the state machine config. If the config grows with your app it quickly becomes hard to maintain.
You will also need a lot of helper substates, which confused a lot of devs. My take on it: use state machines for simple or mature stuff. Don't use it when you need to heavily iterate over the code base for feature adaption
Reactathon 2023: Theo makes live calls from the Announcer's box...
Wait I’m so down for something like this tho
I'm a junior web dev, and I _can't believe_ senior devs complain this much about the dependency array, cringe.
This was annoying since he assumed so early on that the presenter was saying it was better with life cycle function. He never says that. Half of the video comments were a waste of time.
I think one of things that should have been disclosed at the very beginning of David's talk is that he's a founder and a major promoter of XState, so he will take each and every opportunity to convince you that you need it in your project. So yeah - built-in hooks are bad, XState is good. I find it rather hard to believe that he's very objective in his talk, it feels like he just uses it as a space to promote and find use case for his library.
I fully agree. He's using examples with poorly written code, barely functional code I might add, just so he can make XState look better.
The issues that exist within React are more often than not due to asynchronous events and people simply not understanding the framework. You can't save yourself from idiocy. Even less so when you're the idiot yourself. That's part of why I dislike React however, because some hooks seem like what you should use when it's not at all what should be used. I want to add that this dislike is honestly easily fixed through better naming conventions.
I am glad you came with this. I criticized the talk with a comment on his video.
Since he is only telling not to use useEffect but he did not come up with any!! solution how to do better, !... So literally the question everbody was waiting for in the talk... "How the f+"*ç should we fetch data"? (At least I expected something like react-query) or what else?
You were missing the point because David is NOT advocating using ComponentDidMount instead of useEffect LOOL
You're missing the point right now :^)
@@t3dotgg Okay guys, let’s put together some linting to highlight all these missing points. 🙃
The speaker’s `ComponentDidMount()` + coverage of the legacy LC methods were unnecessary, since everyone agrees they sucked. The criticisms of `useEffect()` had some good points, but the examples were generally oversimplified, and served disingenuous at times. I think the talk was poisoned by hyperbole. The speaker was trying too hard to be sensational instead of making simple good points.
Hey Theo. Love your vids, they resonate a lot with my work as a webdev. I am really interested in knowing how would you have re-architectured the ad section so that issue does not happen? Maybe make a video about it?
I learn a lot from your channel, thanks for that!
came for the rant - stayed for it! Much love
Is this video (that pretends "reacting" about the another video) paid by Facebook to justify the
anoying changes made to the API each year?
Their marketing is so good, I know because we have been fooled multiple times that their library and approach is best, even when they had software patterns not removed from license they still managed to make us use it anyway.
They should be more fair with the community rather than compensate it by convincing us through marketing. It seems that now their best defense is mocking the people that criticize them.
When we will switch to Vue, Angular or Svelte they
will finally figure out that marketing instead of
fairness towards community was a bad strategy.
I think about this comment a lot
"I always remind myself to not forget--it's all these similarly bizarre, and unique choices, that make React...React" ruclips.net/video/lGEMwh32soc/видео.html With Svelte and Solid coming up, and Vue 3's super composability (similar to React/Solid) and amazing, Svelte-like DX, devs no longer have to be held hostage by a React that really doesn't see the need to treat its dev community with care, love, and respect because it is so dominatingly popular. My prediction: React will have a presence for a long time, like jQuery, but also like jQuery, no one will want to learn it in about a year and a half or two. Vue will keep rising, a ton of talent will move over to Solid, and Svelte will be especially popular at the web site end of the website-web app spectrum. It's sad to see React devs' inner conflict with how much they hate how React makes their lives miserable, then trying to convince them that React was the right choice. Maybe at the time it was right, but things have moved on, while React keeps doing crazy stuff like rolling out good docs 3-4 years after hooks were released. That's insane. Oh yeah, and it looks like Vue Vapor (no v-dom strategy like Solid/Svelte) coming up, Vue will become even faster (Vue 3 got a lot faster). And, as one can see with the Vue 2 to Vue 3 migration, they will do a lot to make that migration smooth and as pain-free as possible.
I love the idea of xstate but in practice modelling every state of your app with a name is probably too much. Narrow down to just a component and you should have at most a few named states and values that go with them. You can manage it with form state and a few overall enum/constants without injecting another state library.
Hi Theo, could you recommend a React app example (or video / tutorial perhaps) to orient with for state management? I agree that state machines can be overkill, but not sure how to use the alternatives correctly.
Thanks for sharing your thoughts on David K's talk, really insightful review. I like how you tell us at the end of the video to watch the video lol.
How do i stay up to date with when these conforences are happening so i can watch live?
Thank god I use other UI frameworks rather than React, people are still debating useEffect vs class based components? LOL
No wonder you love React. You like to use the f*** while _Reacting_
Junior react dev here. Why isn't it just mounted(handler), updated([deps...], handler) and unmounted(handler)? wouldn't this be more concise?
Can anyone explain why useEffect should be used rarely and what should be done instead? If I want some state to change because some other state changed, should it just occur on every render (until it is no longer performant, where useMemo could be used)?
Why do you want to change state because of other state?
Usually, state changing is because of an action, i.e. clicking a button. If clicking a button increases `count` by 1, and we want to display `count` squared, we can redefine `squareCount` every render for cheap.
If you're waiting for data to come back and then transforming that data i.e. `fetch().then(d => setState(d))`, transforming and re-storing via Effect is a NASTY anti-pattern.
All state that an action changes should be changed in the action. That's the part both David and I agree on here
@@t3dotgg Nice :) Thanks for the response! I'll keep this in mind next time I start importing useEffect hah
I think you talk about derive state?
Theo, can you please react to the "Looking at Xstate's source code" video on the channel by KevinGhadyani ? David is on there and I think the example picked there explains a much more valid use case for XState. It seems like he picked an example at the end that is probably better served by things like rtk query, react query etc. But this kind of rich, complex client side UI feature like presented in the conversation with Kevin, is where Xstate and react (as an app not just a "website") can really shine.
I also think the video Kevin made about hooks and especially the useEffect hook deserves a lot more attention. He explains the useEffect hook as "memoization for side effects". That is a very unique way of looking at things, but it is essentially what is happening. Why apply the concept of memoization only to data structures and function calls? In the end an effect is also just an async function. This mental model can turn effects from this scary alien thing into something known and manageable.
TLDR: maybe the critique of useEffect isnt in good faith. The audience probably knows it is not that serious, because it just serves as stylistic device to carry the conversation from the wider react ecosystem to the topic of XState. 😅 There are better examples for presenting the use case of XState. Please take a look at them tooo 😀👍
I have David coming on next week - gonna watch this video to prep for it 🙏
i wished i have learned react first rather than vue,. learning react after vue makes react a mess. everything a LOT easier with vue. a lot flexible too. well these learning curve i have to take :^)
Sincerely I wish I had Learnt vue before react
@@magical692 believe me its the other way around 😁
@@deecee2204 one man's food is another's poison 😹
The fact that you got mad at this guy who you eventually realized you agree with I think shows you were the one arguing in bad faith.
It feels to me like you misinterpreted the initial part of the talk as preferring component lifecycle hooks to useEffect; your rant(s) on that, while fun and quite correct, felt unneeded.
No hate though, as I totally agree with your overall conclusion, and it's probably a good example of why his framing and presentation choices were ill-advised.
Man, this guy is the type of guy people call as "toxic". "...because one person I don't like..." etc etc ... I like him. Acid. No bullshit.
He like complaining and it's funny, sometimes is right others not.
Not sure if is "toxic"
How are we suppose to handle unmount scenario if not with useEffect?
As a beginner I didn't even notice there was a problem with useEffect... I did notice sometimes it triggers more than one time, so I use the flag workaround.
Question. I use useEffect to fetch data when the page first loads "useEffect(( )=> { fetch( ) }, [ ])" and put a spinner up while it fetches. Is this bad? I can't think of a way to do it without useEffect.
Google search "react query" - let me know how it goes :)
Or use Suspense and react swr
This is why reaction videos are almost always a bad idea, specially if you feel very passionate about the topic, since you'll tend to rant before having the whole picture
I know you have a video on Solidjs, but I curious as you mentioned: "Svelte will only be as good as what Rich feels like doing" , what's your opinion on Solid Js?
Spicy video, thanks for sharing your thoughts. I'm certain that a lot of people are learning things from this, myself included, even if you might feel like you are just ranting
As a relatively early dev, I think the tip on when to use useEffect at 12:45 is super useful. I totally agree that you should always have a variable in the dep array to better control when the hook triggers, but considering where you’re placing the hook is also important too.
The react-query counter-example doesn't hold up for me. You aren't using effects and you are putting the state mutation in event handlers, which seems to be the whole point of the talk. Perhaps I am misunderstanding.
In the execute on mount only once example 41:23, I tend to use this pattern for analytics.
i love this channel. im learning alot AND get to see those beautiful rants? subbed
25:54 Thanks for sharing this story!
Hi Theo! I've been watching you since the pokemon video came out. You're perhaps my favorite dev so far, like a chunk of fresh air in suffocating world of frontend (and React ecosystem especially).
I am React dev myself, and it's really exhausting to see dozens of wheel inventions for even the simplest things, trying to glue together all of them, project to project.
For the past year I've been working on a project with a lot of features, states, async logic and 100+ API endpoints. Things I struggle the most with are state and complex effects (which I have a lot). I use RTK and sagas, try to keep models apart from views, but I don't like how it turns out, the project is still a huge dump in my eyes.
I don't even know what I wanted to ask at this point (probably "how would you manage big amounts of complex async logic that is spread among components"). Just wanted to complain a bit and say that you're a legend and your videos help me a lot. ❤
Join the discord if you haven’t already!!! We talk about problems like this a lot, just did a whole rant about sagas yesterday
@@t3dotgg where's the discord link?
I have heard of this button issue from streamers before, when it came back. It was a nightmare
Please make a whole video talking about svelte
Love the format! 🖤
Lost some respect for Theo in this video :( Too much hate for his old coworkers.
What I don't understand is why so many people think useEffect is anything but a convenient variable change listener. That's literally all it does.
The only thing that warrants a "huh?" is that there's a dismount part that happens, which is obvious since your variable is yeeted and deleted when the component goes byebye.
It's not so obvious that it happens and is why I believe the useEffect hook should require a cleanup function, just as it should require a dependency array.
32:20 oh ELM TEA all over again
Can someone link to the "use event" hook that's mentioned?
Thank you for the video, I was really mad myself for this guy being crazy on useEffect!
I think engineering is about trade offs, we trade a set of problems with another set of problems that we are more comfortable to deal with.
Get Luke from LTT on to dive into Ping as a product
Damn, Theo 9 month ago was WILD lmao
great content, thanks for the thoughts!
Can you please do a video on memoization in React?
I'm a junior front-end developer from South Africa and I love your content, I'm still trying to understand a lot of the concepts you brush over but it's definitely increasing my knowledge base. I've been working with React for about a year and a half now, about 3 months into NextJs. I'm still not comfortable with TypeScript but hope to get there soon.
Here i was thinking i wnet crazy watching this , thank god im not the only one !
how about null instead of [] for no dependency
David's most arguments are like: "bread is shit, because its not butter" and "electric stove is shit, because it doesn't have a fire". Some conclusion: "electri stove doesn't burn"
I think I've made the infinite loop mistake like twice maybe. It's not a big deal
I’m glad I found you
45:14 this really triggered me and I started to aggressively type a comment and almost just closed the video but by the end of the rant you walked it back to distinguish sites and apps. All calm now, but I hope you work on your delivery because with the multiple instances of immediate condemnation and shit talk it was walking the line of unbearable.
Where does useMutate come from. I'm new AF.
I died a little when he said "this is not haskell, what are we doing?". Javascript in a functional style is so good wym a function inside a functions is bad?
It’s because the lifecycle shit was easy to reason with. It was obvious to the human brain.
Confused why you fixated on the class components slide and kept repeating “bad faith” claims. It was mentioned for like 30 seconds of the talk, not at all the main point.
Felt like you were arguing with strawman points no one was making
Do you write unit test? or is it only when you know the code is fuckt and you want people to stop making a mistake?
37:15 isn't this kind of Redux?
love this dude
For me the thought process goes… oh I wrote a function and now the page doesn’t load, I better put it in useEffect lol
can you do a video on useEffect? Thank you!
Lol, by the time I finished to watch this video Honeypot posted "Reactjs the documentary"
Saved me some shitt I didn't grasp ❤️
😬 teams could get this uncomfortable? Oof
Your website is 🔥
subbed for the rant
28:08 hahaha I’m definitely wouldn’t like to work with this guy in the same team 😂
I am so confused by ur point of view, at some point u imply that useEffect is bad (but the old alternative is worse) and almost in the same sentence u order us to be happy with it?
Disclosure, i am the author of xania view library (see krausest js benchmark) heavily inspired by react and I am looking for the good parts of react and 'useEffect' does not seem like it.
Whilst I agree with most of David's talk, Theo touches on almost all the parts of the talk that I took issue with, especially the good use cases that useEffect was intended for. Yes, there are some points David brought up that useEffect shouldn't be used for, but it feels like a lot of the other points he brought up were made either in bad faith or the alternative use-cases were not made clear beforehand. Loved this video Theo!
I have been developing for web for 25 years. Everything I worked with in frontend so far has been more of a bandaid for a broken system. And unfortunately for me React is no exception. I won't be shilling something else but there are much better technologies out there in means of developer experience. Honestly the name of the hook useEffect derives from handling side effects. Even that should be telling for an entire generation of puppeteering requirements of state management.
It was about here when in the original talk I couldn't take David's BS anymore. XState is cool, but react itself is already a kind of state machine, so for normal use cases, you really really don't want to use it
Require the deps array!? I think it's a bad idea. You can make any effect work properly WITHOUT a deps array(and it's far more readable).
I am fascinated. Please elaborate on how I could useEffect for something like a data fetch without a deps array of some form in a way that is more “readable”
@@t3dotgg Just tried to share a comment with a code sandbox link that might have been blocked. Let me know if you're able to see it
He is mainly focused on second arg in useEffect. like `useEffect(callback, deps
I've said exactly this, you never want the case do something on every render. It's almost like it should be a different hook useRender and useEffect(() => something) should strict equal useEffect(() => something, []). Apart from that I hate the use of the closure like this, it causes spaghetti code. In most systems passing variables explicitly is much better, react even demonstrates this with props...
I think the same
Thank you for the content. It's exciting
Been waiting to catch you live to sub my twitch prime! Thanks for the good content as always theo man.
Do you have more videos on not using useEffect? I've never heard this argument but love what you said here. Interested in seeing it in practice.
Not yet - will do more React Query-esque content. I post snippets about this on twitter a lot - search my @ and "React query" for some :)
13:40 Svelte
Just cause the lifecycle components were bad doesn’t mean useEffect is good. Why should you keep your own dependencies? Can you possibly be better at that than a computer. At work that’s all I see all day after we moved to react, issues with useEffect. It’s complete trash.
Yeah... some of these talks make me wanna go back to Angular...
i still dont know how use use effect to fetch data ONE TIME in a component. dude angular is so good at this point
Effects aren't for fetching data!!! Unlike Angular, you don't have to use every piece they give you for every problem you have. React Query is a great library for managing your fetches, async calls, etc
Tbh it sounds like you need help managing that so def check it out :)
@@t3dotgg POGGER
@@t3dotgg So, when developing with React, we have to use yet another external library for a making a simple request, LOLLLLLLL
Can someone change my mind on state machines?
I think they are backwards evolution in some way. They do exactly the same thing if else statements do in every programming language. I can imagine an alternative universe where state machines were invented before if else statements, and in that universe, if someone was able to invent if else statements their pitch would be: 'it's just like state machines, but look at how much less stuff you can write.'
Didn't realize if-else statements were async 😂
Seriously though, it sounds like the things you're building aren't particularly interactive. When an "action" or "event" (external, user-triggered, etc) can interrupt your logic, handling that isn't if-else-able.
90%+ of the time, React-Query handles the async case well enough to bring you back into if-else land. For websockets, chat servers, video call apps, games, and pretty much everything other than "fetch", state machines are essential.
You should try building a game :)
@@t3dotgg That is very true. Apps I've been working on don't often rely on websockets so much that it would cause a problem like that.
I'll keep that use case in mind next time I read about state machines. Thanks Theo for replying.
Unrelated but I've been binging your videos the whole day. I feel like your content is exactly what I was craving at this point in my career. Keep It up!
this guy is such a kid mate.
i love when u speed up video 0:51
Theo makes great vids but he doesn't rant well. Should ask Prime for some tips
I watched David K's talk like days ago and after watching this I have some different thoughts:
Class component is easier for most of the developers to understand, just to know the apis and you are almost good to go; While functional component requires not just the mental model of [state] => UI, but also annoying re-renders when logic goes complex. I don't think it's about good or bad, cause they both serve well when needed. But yes I do agree it's much better from a code architectural perspective transitioning from class component to functional component.
So I actually like how he represents at the first minutes by showing the not totally right but really easily understandable comparisons.
And by the way what's the use cases that useSWR are bad? And what is the difference with useReactQuery? @44:44
Should have gone with Svelte.
if you could show a piece of code while you rant next time, otherwise I lost your trail of thought
Love a good rant!
It's better than class component but it's still kinda meh.
If you create an API and name is useEffect(), then get mad if people use it for side effect management, you are doing something wrong. React has the most idiotic function names. Sometimes I feel like, we get these names from someone who just really want to show off how much jargon they know. While not even being correct on their meaning.
useTransition 😅
nothing wrong with useEffect.