Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prefer-takeuntil Rule Should Not Trigger for HTTP Requests #24

Open
manickam1999 opened this issue Jul 1, 2024 · 1 comment
Open

prefer-takeuntil Rule Should Not Trigger for HTTP Requests #24

manickam1999 opened this issue Jul 1, 2024 · 1 comment

Comments

@manickam1999
Copy link

Issue: prefer-takeuntil Rule Should Not Trigger for HTTP Requests

Description:
The prefer-takeuntil rule currently triggers when subscribe is called within a component, requiring the use of the takeUntil-destroyed pattern. However, this rule should not be triggered for HTTP requests, since HTTP requests clean up themselves, such as the one shown below:

Example Code:

this.http.post(url, value).subscribe();

Reason:
For specific HTTP requests, especially those that are one-time operations and do not need to be unsubscribed from when the component is destroyed, enforcing the takeUntil pattern is unnecessary and adds unnecessary complexity to the code.

Proposed Solution:
Modify the prefer-takeuntil rule to allow exceptions for certain HTTP request patterns, such as http.patch, http.post, http.put, etc. This could be controlled through additional rule options or by recognizing common HTTP request patterns that do not require unsubscription.

Example Configuration:

{
  "rxjs-angular/prefer-takeuntil": [
    "error",
    {
      "alias": ["untilDestroyed"],
      "checkComplete": true,
      "checkDecorators": ["Component"],
      "checkDestroy": true,
      "allows": ["http.patch", "http.post", "http.put"]
    }
  ]
}

@e-oz
Copy link

e-oz commented Aug 7, 2024

No, you are wrong.
Example: HTTP request updates globally shared data.
The first request was initiated and took 25 seconds to execute.
After 10 seconds, the user navigates to another URL, causing a similar request (that updates the same data).
This second request takes 14 seconds to execute, and the data is updated. After just 1 second it will be updated by the first request.

The first request had to be canceled on navigation (when the component is destroyed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants