Adjusts the code we generate for HMR so that it passes in the HMR ID and `import.meta` to the `replaceMetadata` call. This is necessary so we can do better logging of errors.
PR Close#59854
This change removes some code and logic duplication by
re-using the existing functionality. It also pulls some
code into separate methods for clarity.
PR Close#59806
In this commit, we check whether the application is destroyed before printing hydration stats. The application may be destroyed before it becomes stable, so when the `whenStableWithTimeout` resolves, the injector might already be in a destroyed state. As a result, calling `injector.get` would throw an error indicating that the injector has already been destroyed.
PR Close#59716
Make extractAttrsAndClassesFromSelector to return TAttributes directly to
simplify the overall logic and remove unecessary code.
PR Close#59678
PR Close#59735
We already have a function called `isDetachedByI18n` which checks whether a `tNode` is in `isDetached` state; as thus, there's no reason to apply those checks manually.
PR Close#59668
The `type_checks` module already exposes a utility function that checks whether `TNode.componentOffset` is greater than -1. There is no need to check that property manually in other places, as we can reuse the helper function.
PR Close#59611
The `type_checks` module already exposes a utility function that checks whether `LView` is marked as a root view. There is no need to check flags in other places, as we can reuse the helper function.
PR Close#59614
If a file ends up in multiple programs, the unused imports migration was counting it twice. This was fine since the string replacements were handling it correctly, but it was printing out incorrect data.
These changes rework the migration to de-duplicate the replacements and produce the data from the de-duplicated results.
PR Close#59656
The component ID collision check tries to account for components being replaced by checking for the `type`, however that might not work during SSR.
These changes disable the warning since it's primarily useful on the browser anyways.
PR Close#59625
Currently during HMR we swap out the entire module definition (e.g. `MyComp.ɵcmp = newDef`). In standalone components and most module-based ones this works fine, however in some cases (e.g. circular dependencies) the compiler can produce a `setComponentScope` call for a module-based component. This call doesn't make it into the HMR replacement function, because it is defined in the module's file, not the component's. As a result, the dependencies of these components are cleared out upon replacement.
A secondary problem is that the `directiveDefs` and `pipeDefs` fields can save references to definitions that later become stale as a result of HMR.
These changes resolve both issues by:
1. Performing the replacement by copying the properties from the new definition onto the old one, while keeping it in place.
2. Preserving the initial `directiveDefs`, `pipeDefs` and `setInput`.
Fixes#59639.
PR Close#59644
When a component is created with shadow DOM encapsulation, we attach a shadow root to it. When the component is re-created during HMR, it was throwing an error because only one shadow root can be attached to a node at a time.
Since there's no way to detach a shadow root from a node, these changes resolve the issue by making a shallow clone of the element, replacing it and using the clone for any future updates.
Fixes#59588.
PR Close#59597
If a component injects `ViewContainerRef`, its `LView` gets wrapped in an empty `LContainer` and the container's host becomes the `LView`. The HMR logic wasn't accounting for this which meant that such components wouldn't be replaced.
Fixes#59592.
PR Close#59596
In this commit, we clean up the reference to the function set by the environment initializer, as the function closure may capture injected elements and prevent them from being properly garbage collected.
PR Close#59598
This change refactor how the dynamically created component
deals with attributes in order to reuse the existing
setupStaticAttributes logic (instead of having specific
and similar code).
PR Close#59572
In this commit, we delete `_ejsa` when the app is destroyed, ensuring that no elements are still captured in the global list and are not prevented from being garbage collected.
PR Close#59492
These changes aim to resolve the issue that prompted #59514. The animations module is a bit tricky for HMR, because it schedules the destruction of its renderer after the currently-running animations are done. If there are no running animations, the renderer gets destroyed next time around. This is a problem, because it means that the styles can stay around for a long time.
These changes resolve the issue by:
1. Moving the cleanup of the renderer to after the destruction of the old view. This ensures that the usual clean up flow has been kicked off.
2. Flushing the animations when a component is replaced to ensure that the renderer is cleaned up in a timely manner.
PR Close#59574
When the reactive `request` of a resource() notifies, it transitions to the
Loading state, fires the loader, and eventually transitions to Resolved.
With the prior implementation, a change of the `request` will queue the
effect, but the state remains unchanged until the effect actually runs. For
a brief period, the resource is in a state where the request has changed,
but the state has yet to update.
This is problematic if we want to use resources in certain contexts where we
care about the state of the resource in a synchronous way. For example, an
async validator backed by a resource might be checked after an update:
```
value.set(123);
if (validator.value()) {
// value is still valid, even though the resource is dirty and will soon
// flip to loading state (returning value(): undefined) while revalidating
}
```
To address this timing concern, `linkedSignal()` is used within the
`resource()` to synchronously transition the state in response to the
request changing. This ensures any followup reads see a consistent view of
the resource regardless of whether the effect has run.
This also addresses a race condition where `.set()` behaves differently on a
`resource()` depending on whether or not the effect has run.
PR Close#59024
Originally the `T` in `Resource<T>` represented the resolved type of the
resource, and `undefined` was explicitly added to this type in the `.value`
signal. This turned out to be problematic, as it wasn't possible to write a
type for a resource which didn't return `undefined` values. Such a type is
useful for 2 reasons:
1. to support narrowing of the resource type when `Resource.hasValue()`
returns `true`.
2. for resources which use a different value instead of `undefined` to
represent not having a value (for example, array resources which want to
use `[]` as their default).
Instead, this commit changes `resource()` and `rxResource()` to return an
explicit `ResourceRef<T|undefined>`, and removes the union with `undefined`
from all types related to the resource's value. This way, it's trivially
possible to write `Resource<T>` to represent resources where `.value` only
returns `T`.
`hasValue()` then actually works to perform narrowing, by narrowing the
resource type to `Exclude<T, undefined>`.
PR Close#59024
Prevent leaking signal reads and exceptions from a custom `equal`
function of a producer `computed()` to a consumer.
Upstream https://github.com/tc39/proposal-signals/pull/90 with a notable
change: Angular does **not** track reactive reads in custom `equal`
implementations.
PR Close#55818
Fixes that in some cases the HMR replacement function was being run outside the zone which meant that change detection would break down after a replacement.
Fixes#59559.
PR Close#59562
This is first of a series of refactorings that moves code
around such that logic from the shared instruction file
is dispatched to the relevant functional parts.
PR Close#59453
Currently when we swap out the component during HMR, we remove the renderer from the cache, but we never destroy it which means that its styles are still in the DOM. This can cause the old styles to leak into the component after they're replaced. These changes add a `destroy` call to ensure that they're removed.
PR Close#59514
We change the `enum` to a plain `const` to eliminate extra bytes, as `enum` is not really required. We might not be able to switch to `const enum` due to single-file compilation restrictions.
PR Close#59469
We previously did count forcibly ignored queries as incompatible. This
resulted in incorrect migration stats that are printed upon migration
completion.
See: #58657
PR Close#59463
This ensures the migration works for these TypeScript versions. The
migration is very sensitive to the TS version and its internals; so it
makes sense to test all of these.
PR Close#59463
In this commit, we switch from decorators (which also produce redundant metadata, such as in the
`declareFactory` instruction) to the `inject` function to drop the `BROWSER_MODULE_PROVIDERS_MARKER`
token in production. This token is actually provided only in development mode but is still
referenced in the constructor due to the `@Inject(BROWSER_MODULE_PROVIDERS_MARKER)` decorator.
PR Close#59412
Kristiyan Kostadinov