AbortController beyond API calls: cleaner code and fewer bugs

🚦 AbortController — most devs use it for API calls… but it can do more Most developers use AbortController to cancel an API request. That’s usually where the story ends. But recently, while cleaning up a useEffect, I realized something interesting 👀 AbortController isn’t limited to fetch. You can pass its signal to event listeners too. One controller. Multiple events. One clean cleanup. ✨ 💡 Why this feels good No removeEventListener Cleaner useEffect cleanup Fewer bugs & memory leaks Very React-friendly #JavaScript #ReactJS #WebDevelopment #Frontend #CleanCode #AbortController #ReactHooks #DeveloperTips 🚀

  • text

I pefer Rxjs: const sub = new Subscription(); const resize$ = fromEvent<UIEvent>(window, "resize"); const scroll$ = fromEvent<Event>(window, "scroll"); const keyDown$ = fromEvent<KeyboardEvent>(window, "keydown"); sub.add(resize$.subscribe(() => console.log("resize"))); sub.add(scroll$.subscribe(() => console.log("scroll"))); sub.add(keyDown$.subscribe((e) => console.log(e.key))); return () => { // one call -> all Listeners cleaned up sub.unsubscribe(); }, []); return null;

That’s an interesting one, Pradip! I am someone who had used it for “fetch” only but never thought of this use case. Appreciate your knowledge sharing on this topic. Cheers 🙌

We can use removeListener as well I guess 🤔

Interesting approach using AbortController. For some useEffect cases it can greatly reduce boilerplate, thanks for sharing!

Like
Reply

Interesting to learn that AbortController works with event listeners too, not limited to cancelling fetch requests.

That is really great share.

See more comments

To view or add a comment, sign in

Explore content categories