According to the promise specification, promises are not cancellable by default.
Once a promise is created, it will either resolve or reject, and it doesn't
provide a built-in mechanism to cancel it.
There may be situations where a promise is provided, and it either resolves after
the pipe has been destroyed or never resolves at all. If the promise never
resolves — potentially due to factors beyond our control, such as third-party
libraries — this can lead to a memory leak.
When we use `async.then(updateLatestValue)`, the engine captures a reference to the
`updateLatestValue` function. This allows the promise to invoke that function when it
resolves. In this case, the promise directly captures a reference to the
`updateLatestValue` function. If the promise resolves later, it retains a reference
to the original `updateLatestValue`, meaning that even if the context where
`updateLatestValue` was defined has been destroyed, the function reference remains in memory.
This can lead to memory leaks if `updateLatestValue` is no longer needed or if it holds
onto resources that should be released.
When we do `async.then(v => ...)` the promise captures a reference to the lambda
function (the arrow function).
When we assign `updateLatestValue = null` within the context of an `unsubscribe` function,
we're changing the reference of `updateLatestValue` in the current scope to `null`.
The lambda will no longer have access to it after the assignment, effectively
preventing any further calls to the original function and allowing it to be garbage collected.
If Chrome is built with additional flags and run with `--allow-natives-syntax --track-retaining-path`,
we could use `%DebugTrackRetainingPath` to see the distance from the root for `updateLatestValue`
if it's passed directly to async.then, e.g.:
```js
%DebugTrackRetainingPath(updateLatestValue);
// Distance from root 4: 0x123456789abc <JSPromise (sfi = 0x1fbb02e2d7f1)>
```
PR Close#58041
This commit (25cae4555a) introduced an error throw when the directive definition is not defined. We can guard it with `ngDevMode` and throw the error only in development mode.
PR Close#61075
Replaces `PLATFORM_ID` checks with `ngServerMode` within the `HttpXsrfCookieExtractor`. It is not part of the public API, and thus this change should not affect consumers who may have called the constructor directly.
PR Close#59810
This refactor removes the unnecessary `runOutsideAngular` call in the
view transition helper. The resolved promise re-enters the zone in the
transition, so that will trigger the Angular zone anyways. If it didn't do that,
it risks activated the route outside the zone, which is a bigger risk.
Regardless, this function is only run once per navigation, so even if it
_did_ result in an extra promise/timeout inside the zone, this is not
excessive. Using ZoneJS to trigger rendering is known to overreact to events.
Using `OnPush` or zoneless is more effective at mitigating this issue.
PR Close#61068
The inifinite loop test is a real infinite loop and runs until a stack
overflow happens. In addition, all the promise and observable tests are
just duplicates of the other redirects and don't test any additional
logic. Instead, this change updates one test to return an observable and
another to return a promise
PR Close#61076
Adds `__PURE__` annotations to `PROPAGATION_STOPPED_SYMBOL` to enable tree-shaking, even if is is not referenced. This variable is not dropped when Angular is imported from a module that has `sideEffects` set to `true`.
PR Close#61004
The stash event listener is a global function that might be unsafely overridden if multiple microfrontend applications exist on the page.
In this commit, we create a map of `APP_ID` to stash event listener functions. This map prevents conflicts because multiple applications might be bootstrapped simultaneously on the client (one rendered on the server and one rendering only on the client).
I.e., the code that might be used is:
```ts
// Given that `app-root` is rendered on the server
bootstrapApplication(AppComponent, appConfig);
bootstrapApplication(BlogRootComponent, appBlogConfig);
```
Two bootstrapped applications would conflict and override each other's code.
PR Close#59635
As the function in the factory was named `httpResourceRef`, error NG0203 had with the following message:
```
Error: NG0203: httpResourceRef() can only be used within an injection context such as a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`. Find more at https://angular.dev/errors/NG0203
```
PR Close#60022
Currently, the error thrown in `getNgModuleDef` is guarded by `throwIfNotFound`, which is only set to `true` when `ɵɵsetNgModuleScope` is called in production. In all other cases, `throwIfNotFound` is never used in production. This means that if NgModules aren't used, `getNgModuleDef` is never called with the second argument. We can split it into two functions to allow tree-shaking of the error when NgModules aren't used at all.
PR Close#60339
Renderer2 and ElementRef didn't mention the Security-DomSanitizer method, this will add clarity for potential user what to expect. Also swap deprecated "callout" class to docs-alert
Fixes#51208 , #46904
PR Close#60708
This commit wraps the `fn` invocation with `try-finally`, ensuring that the pending task (added in [this commit](d5c6ee432f)) is always removed.
Prior to this commit, if a subscriber threw an error, it would prevent the application from becoming stable — though this shouldn't happen under normal scenarios because the error should be handled by the RxJS error handler or Angular's error handler.
Errors should not silently prevent the application from being rendered on the server.
PR Close#61028
This commit adds the support for defer block in the Angular DevTools.
@defer block are now visible in the directive tree and give access to defer & hydration details.
This feature also brings support of incrementation hydration.
PR Close#60629
This commit ensures that errors from the `NgZone.onError` subscription
in bootstrap are reported to the internal application error handler.
Practically speaking, this should not affect anything today, as the
application handler goes directly to the `ErrorHandler` from the root.
While TestBed installs an application error handler that rethrows,
`TestBed.createComponent` does not create components through this
bootstrap function.
PR Close#60946
The `ComponentHandler.resolve` method is ~500 lines and is a bit hard to follow due to some very long `if` statements. These changes split the functionality across several smaller methods to make it easier to manage.
PR Close#61018
Currently to create an `R3TargetBinder`, we have to pass some sort of directive matcher, however we also have a couple of use cases where we use the binder to do analysis that's unrelated to directives (e.g. resolving the `@defer` blocks). In these cases having to create a dummy matcher adds some slight overhead and makes the code harder to reason about since it looks like directive matching may be happening.
These changes update the `R3TargetBinder` to allow for `null` to be passed as the directive matcher.
PR Close#61018
An earlier commit that introduced tracking of selectorless directives to the template binder made it so `getDirectivesOfNode` returns _all_ of the matched directives while a new method called `getOwnedDirectives` would return only the ones brought in by the specific node.
In hindsight, this is likely to cause bugs in the future, because it's unclear whether to reach for `getDirectivesOfNode` or `getOwnedDirectives`. These changes remove `getOwnedDirectives` and make it so in selectorless `getDirectivesOfNode` accepts the directive AST node itself.
Another goal of this refactor is that the TCB shouldn't have to check the `selectorlessEnabled` config option.
PR Close#61018
