For one, even with useEffect, you still have to write code to remove the event listener, so it's not like you can actually forget about it. It just takes a little bit less boilerplate, but that's just code size.
Also, custom elements can do this too. They have a connectedCallback and disconnectedCallback that you can actually rely on for cleanup if you need that.
And in fact, you could easily build a simple helper function like this.whileConnected(window, "scroll", onScroll) that adds an event listener and sets it up to be removed again, and it would be trivial to implement both on top of useEffect and custom element callbacks.
But most importantly,
this isn't about components. I used a custom element because it's a convenient example, but you may well need this sort of cleanup for a plain javascript object. Frameworks won't help you with that.
And lastly, although this is a matter of preference, I honestly find that the more imperative version using browser APIs looks a lot less complicated. It's a very step-by-step kind of setup that's a lot easier to follow than a function that takes a function which returns a function.
EDIT: It's also kinda boring to just have a framework take care of everything. Useful on the job, but dreadfully uninteresting to think about. It might be interesting how react et al. do these things under the hood, but just the usage isn't something I want to think or write about in my free time. Weak references and garbage collection callbacks are interesting. useEffect is not.
Comment hidden by post author - thread only visible in this permalink
It might be very interesting for devs to reinvent the wheel, but it's not efficient.
And yes, it is about components. A custom element is also a component. It's a matter of perspective and definition.
By the way, a function that returns a function that returns a function is something very common in programming languages. Have you ever heard about Functional Programming? Have you ever heard about functors? Time to learn!
You don't have to write code to remove the event listener
Yes, you literally did. And now your counter-argument seems to be that there's a library for that? Congratulations, you've proven the point I didn't even make.
And yes, it is about components.
I wrote it. Between you and me, one is qualified to say what that post is about, and the other one is you.
A custom element is also a component. It's a matter of perspective and definition.
Did you discover this recently, or why did you feel the need to point this out? Sorry, but this isn't news; the group of features that custom elements is a part of is literally called "web components". You're wrong about it being a matter of perspective. They just are.
I also point out how "but you may well need this sort of cleanup for a plain javascript object.", so I'm assuming you think {} is also a component? You can google why that's wrong, I'm not interested in explaining basics like that. Or maybe you just didn't understand even that simple sentence, which would probably be because you're not interested in having an honest discussion and just want to talk down to people.
By the way, a function that returns a function that returns a function is something very common in programming languages.
Yes, congratulations, you've discovered yet another super basic concept: higher order functions. Take a while to understand the basics, then come back and I can teach you about partial application, currying, closures, etc.
Also, I'm sorry to tell you, but FP is kind of old news? Maybe you discovered it recently and are all excited about it, but most of us have known that's a thing for years now; some even before the recent renewed interest in the style. If you haven't already, I suggest you also check out OOP; I personally don't like it as much, but it's interesting to read about. I'm sure there's lots for you to learn.
Setting the sarcasm aside though; I'm gonna be honest: I probably know more than you about most of the topics you've mentioned other than the frameworks which I don't use. I wrote a post about fundamentals because to some of us, understanding the basics is either just fun, or a necessity for performance reasons.
If you don't have any interest in lower level concepts, and are happy having the complexity taken away by a framework, all the power to you, but if you're going to go around trying to devalue content that doesn't pander to your specific tastes, I suggest unplugging your internet and keeping your toxic BS to yourself.
So with that being said; do you have anything of actual value to add to this conversation? Or are we done here?
It might be toxic to you personally. I am sorry about that. I also feel sorry because you know so much more than me (and probably anyone reading any article you wrote) and I didn't realise because I don't care and none of the readers do.
When I said "yes, it's about components" I tried to nicely answer to your
But most importantly,
this isn't about components. I used a custom element because it's a convenient example, but you may well need this sort of cleanup for a plain javascript object. Frameworks won't help you with that.
Just like the rest of steps of my answer.
And there was a tiny bit of really valuable thing in my previous comment that you overlooked in your rageous read of my comment:
And I will paste it here so you can read it very well:
A conforming JavaScript implementation, even one that does garbage collection, is not required to call cleanup callbacks. When and whether it does so is entirely down to the implementation of the JavaScript engine. When a registered object is reclaimed, any cleanup callbacks for it may be called then, or some time later, or not at all.
I'm not even going to address any of your BS anymore.
You've shown very clearly that you're not interested in having a constructive discussion and are just here to show how much better you are than me for not caring about browser APIs.
So to make this very clear, since you didn't pick up on it from my last message:
Leave me the fuck alone, I'm not interested in having this kind of conversation.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a few problems I have with this.
For one, even with
useEffect, you still have to write code to remove the event listener, so it's not like you can actually forget about it. It just takes a little bit less boilerplate, but that's just code size.Also, custom elements can do this too. They have a
connectedCallbackanddisconnectedCallbackthat you can actually rely on for cleanup if you need that.And in fact, you could easily build a simple helper function like
this.whileConnected(window, "scroll", onScroll)that adds an event listener and sets it up to be removed again, and it would be trivial to implement both on top ofuseEffectand custom element callbacks.But most importantly,
this isn't about components. I used a custom element because it's a convenient example, but you may well need this sort of cleanup for a plain javascript object. Frameworks won't help you with that.
And lastly, although this is a matter of preference, I honestly find that the more imperative version using browser APIs looks a lot less complicated. It's a very step-by-step kind of setup that's a lot easier to follow than a function that takes a function which returns a function.
EDIT: It's also kinda boring to just have a framework take care of everything. Useful on the job, but dreadfully uninteresting to think about. It might be interesting how react et al. do these things under the hood, but just the usage isn't something I want to think or write about in my free time. Weak references and garbage collection callbacks are interesting.
useEffectis not.Come on...
You don't have to write code to remove the event listener. You can use nice hooks like the ones from usehooks-ts.com/react-hook/use-eve...
It might be very interesting for devs to reinvent the wheel, but it's not efficient.
And yes, it is about components. A custom element is also a component. It's a matter of perspective and definition.
By the way, a function that returns a function that returns a function is something very common in programming languages. Have you ever heard about Functional Programming? Have you ever heard about functors? Time to learn!
Can you actually read?
Yes, you literally did. And now your counter-argument seems to be that there's a library for that? Congratulations, you've proven the point I didn't even make.
I wrote it. Between you and me, one is qualified to say what that post is about, and the other one is you.
Did you discover this recently, or why did you feel the need to point this out? Sorry, but this isn't news; the group of features that custom elements is a part of is literally called "web components". You're wrong about it being a matter of perspective. They just are.
I also point out how "but you may well need this sort of cleanup for a plain javascript object.", so I'm assuming you think
{}is also a component? You can google why that's wrong, I'm not interested in explaining basics like that. Or maybe you just didn't understand even that simple sentence, which would probably be because you're not interested in having an honest discussion and just want to talk down to people.Yes, congratulations, you've discovered yet another super basic concept: higher order functions. Take a while to understand the basics, then come back and I can teach you about partial application, currying, closures, etc.
Also, I'm sorry to tell you, but FP is kind of old news? Maybe you discovered it recently and are all excited about it, but most of us have known that's a thing for years now; some even before the recent renewed interest in the style. If you haven't already, I suggest you also check out OOP; I personally don't like it as much, but it's interesting to read about. I'm sure there's lots for you to learn.
Setting the sarcasm aside though; I'm gonna be honest: I probably know more than you about most of the topics you've mentioned other than the frameworks which I don't use. I wrote a post about fundamentals because to some of us, understanding the basics is either just fun, or a necessity for performance reasons.
If you don't have any interest in lower level concepts, and are happy having the complexity taken away by a framework, all the power to you, but if you're going to go around trying to devalue content that doesn't pander to your specific tastes, I suggest unplugging your internet and keeping your toxic BS to yourself.
So with that being said; do you have anything of actual value to add to this conversation? Or are we done here?
It might be toxic to you personally. I am sorry about that. I also feel sorry because you know so much more than me (and probably anyone reading any article you wrote) and I didn't realise because I don't care and none of the readers do.
When I said "yes, it's about components" I tried to nicely answer to your
Just like the rest of steps of my answer.
And there was a tiny bit of really valuable thing in my previous comment that you overlooked in your rageous read of my comment:
And I will paste it here so you can read it very well:
A conforming JavaScript implementation, even one that does garbage collection, is not required to call cleanup callbacks. When and whether it does so is entirely down to the implementation of the JavaScript engine. When a registered object is reclaimed, any cleanup callbacks for it may be called then, or some time later, or not at all.
I'm not even going to address any of your BS anymore.
You've shown very clearly that you're not interested in having a constructive discussion and are just here to show how much better you are than me for not caring about browser APIs.
So to make this very clear, since you didn't pick up on it from my last message:
Leave me the fuck alone, I'm not interested in having this kind of conversation.