jsx-eslint/eslint-plugin-react

Feature request: abortController + no-leaked-event-listener

Open

#3967 opened on Nov 21, 2025

View on GitHub
 (3 comments) (0 reactions) (0 assignees)JavaScript (8,630 stars) (2,797 forks)batch import
bughelp wanted

Description

i've been using this pattern to clean up event listeners lately:

useEffect(() => {
  const abortController = new AbortController();
  const { signal } = abortController;

  window.addEventListener(
    "click",
    (event) => {
      doSomething();
    },
    { signal },
  );

  window.addEventListener(
    "resize",
    (event) => {
      doSomethingElse();
    },
    { signal },
  );

  return () => {
    abortController.abort();
  };
}, []);

it makes the cleanup function much smaller (and harder to mess up), plus it helps with type inference (i.e. you don't need to explicitly type your event handlers).

i can obviously just disable the no-leaked-event-listener rule, but it would be nice if it could detect this pattern with a heuristic, and maybe even alert you e.g. if you forget to pass signal or forget to call abort().

Contributor guide

Tech stack
javascripttypescriptreact
Domain
developer experiencetooling
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
ESLint rule developmentReact useEffectAST basics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50
Research direction
Examine the existing no leaked event listener rule implementation in the eslint plugin react repository. The rule likely traverses useEffect callbacks and looks for addEventListener with cleanup. To support the AbortController pattern, the rule should be extended to detect when an AbortController is created and its signal is passed to addEventListener, and ensure that abort() is called in the cleanup. Look at the rule's source code and any related pull requests or discussions. Consider adding a heuristic that checks for the abortController.abort() call in the return function and verifies the signal is used.