Thanks to visit codestin.com
Credit goes to github.com

Skip to content

docs(core): mark after{Next,Every}Render overloads as stable #62153

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rdamazio
Copy link

Your blog post signaled that afterNextRender and afterEveryRender are now stable:
https://angular.love/angular-20-whats-new#Signal%20related%20APIs

However, only 1 of the overloads of those was marked as stable.

I detected this because angular-eslint errors on calls even to to the publicApi overload - and while that should probably be fixed on their end, your announcement wasn't specific about only one overload being stable, so I assume this was an oversight.

angular-eslint related issue:
angular-eslint/angular-eslint#2534

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.dev application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

The spec overloads of afterNextRender / afterEveryRender are marked as developer preview.

Issue Number: N/A

What is the new behavior?

They're marked as public APIs.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Your blog post signaled that afterNextRender and afterEveryRender
are now stable:
https://angular.love/angular-20-whats-new#Signal%20related%20APIs

However, only 1 of the overloads of those was marked as stable.

I detected this because angular-eslint errors on calls even to
to the publicApi overload - and while that should probably be
fixed on their end, your announcement wasn't specific about only
one overload being stable, so I assume this was an oversight.

angular-eslint related issue:
angular-eslint/angular-eslint#2534
@pullapprove pullapprove bot requested a review from mmalerba June 20, 2025 02:43
@angular-robot angular-robot bot added area: docs Related to the documentation area: core Issues related to the framework runtime labels Jun 20, 2025
@ngbot ngbot bot added this to the Backlog milestone Jun 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: core Issues related to the framework runtime area: docs Related to the documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant