This commit adds a logic to handle `on immediate` conditions both as a main condition, as well as a prefetching condition (i.e. `prefetch on immediate`).
PR Close#51630
Adds support for `on viewport` and `prefetch on viewport` triggers which will load the deferred content when the element comes into the view.
PR Close#51874
Adds support for `on hover` and `prefetch on hover` triggers. Some code had to be moved around so it could be reused from the `on interaction` triggers.
PR Close#51874
Updates the logic that generates the instructions for the `on interaction` and `prefetch on interaction` triggers to their final shape. Now the instructions take two arguments:
1. `triggerIndex` - index at which to find the trigger in the view where it will be rendered.
2. `walkUpTimes` - tells the runtime how many views up it needs to go to find the trigger element. If the argument is omitted, it means that the trigger is in the same view as the deferred block. A positive number means that the runtime needs to go up X amount of times to find the trigger. A negative number means that the trigger is inside the root view of the placeholder block. Negative numbers are capped at -1 since the placeholder is always in the same position at runtime.
PR Close#51830
The `Writable` type is usefull when we want overwrite readonly properties and we still want to maintain code navigation/reference. It should be use instead of `any` type assertions for example.
PR Close#49754
The `Writable` type is usefull when we want overwrite readonly properties and we still want to maintain code navigation/reference. It should be use instead of `any` type assertion for example.
PR Close#49754
This change simply flip the flag which enables using the deps tracker in JIT compilation (the logic is already implemented in a previous PR). Some tests which depend on the old JIT implementation (e.g., patching the scope info into the type) are modified accordingly.
PR Close#51415
Using verification helpers such as `isComponent` may trigger JIT compilation. Now in some tests such compilation is made purposely to fail, and so in such cases any reference to the `depsTracker.clearScopeCacheFor` method will cause the exception to be thrown earlier than expected which results in teh test failure. Such scenario is the case in the next commit when we enable using the deps tracker in the jit compilation. Note that such failure is only for the framework tests and is a very edge case. The tests in downstream apps will not lead to such scenario of failure at all.
PR Close#51415
This commit adds the necessary mechanisms to perform cleanup of prefetch triggers when resource loading starts. Previously, this logic was missing, which resulted in retaining those triggers.
PR Close#51856
Certain tools in g3 which dynamically bootstrap a component (e.g., custom routers) simply swallow the exception coming from bootstrapping the component and show an empty outlet. Such cases are very difficult to debug as the dev has no clue why the component was not rendered. As bad as this pattern is, fixing all such tools for a better error handling is beyond the scope of our effort. Instead, in this change we print the error messages coming from calculating component dependencies (part of component rendering) to the console for a better visibility into the error. This change only affects local compilation where the component dependencies are calculated in runtime. This change can potentially shed light into many failures of local compilation in g3.
PR Close#51824
Standalone component need to include the imported NgModules as part of their dependencies in order to be able to use the injection tokens coming from these NgModules. To do so, in this change the imported NgModules are included in the standalone component compilation scope.
PR Close#51819
Currently deps tracker includes the exported scope of the exported NgModule only in the exported scope of that NgModule. This is in agreement with what AoT does today. But JIT diverges from this behavior by including these exported scopes into the compilation scope as well. Since deps tracker is going to be used for both AoT (local compilation mode) and JIT, the question might be which behavior the deps tracker should follow? Today it follows the AoT one, but it breaks some tests in Google which seem to depend on this behavior of JIT. So it is better to migrate deps tracker to what JIT does. This leads to a wider compilation scope in local compilation compared to full compilations, but it won't break any existing thing.
PR Close#51791
This change contains runtime logic needed to flatten the NgModule bootstrap field in local compilation mode. While it is quite odd to pass a "nested" array as NgModule bootstrap, it is still required to support this case in local compilation mode since it is supported in full compilation mode.
PR Close#51767
This change flattens the imports info on standalone component decorators in runtime dev mode by adding flattening logic to the deps tracker. Such flattening has no effect in AoT full compilation mode since these arrays are already resolved and flattened by AoT static analysis, but in local compilation mode it is needed since the raw array as appears on the component decorator will be passed to the deps tracker, and so it needs to be flattened.
This change does not affect prod runtime since deps tracker is only used in dev mode.
PR Close#51767
This change flattens the imports/exports/declarations info on ngModule decorators in runtime dev mode by adding flattening logic to the runtime `ɵɵsetNgModuleScope`. Such flattening has no effect in AoT full compilation mode since these arrays are already resolved and flattened by AoT static analysis, but in local compilation mode it is needed since the raw array as appears on the NgModule decorator will be passed to the runtime `ɵɵsetNgModuleScope`, and so it needs to be flattened.
This change has to effect on prod runtime as `ɵɵsetNgModuleScope` is not used in prod.
PR Close#51767
Currently when ESBuild bundles an application importing from
`@angular/core`, the signals library will be discovered during
export analysis. ESBuild will come across the constants for the reactive
signal graph- and end up considering some of these as side-effects given
the pattern of using a spread assignment for extending from e.g.
`REACTIVE_NODE` (a similar issue may occur if we e.g. extend from the
computed reactive node).
See more details on the issue: https://github.com/evanw/esbuild/issues/3392
Even though, ESBuild preserves these constants now, and all of its
dependencies— Terser will consider these as side-effect free and
eliminate these constants. This may require multiple passes though, and
might not be sufficient, depending on the chain of reactive node
extensions. E.g. in the signals branch we noticed some constants
unnecessarily being preserved.
PR Close#51809
Terser does not treat `Symbol` as side-effect free- so if we end up with
a symbol export being loaded, it will result in the symbol being
retained.
We noticed this in the signals prototyping where symbols exported
from `computed` ended up appearing in symbol bundling tests.
PR Close#51776
This commit moves the destroy logic from 'effect' in the lower-level
'watch' so this implementation is shared among varius watch implementations.
PR Close#51757
Certain code patterns and tools in Google (and possibly 3P world) lead to the situation that a component is bootstrapped/rendered without its ng-module being loaded in the browser. Technically speaking this should be an anti-pattern since the ng-module could contain some runtime logic (e.g., providing something, calling some services, etc) and its not being loaded leads to unexpected behaviour. However, in many cases ng-module is an empty class and its only usage is for providing scope, and since in AoT full compilation mode we already hard-code dependencies into components so we can get away with not loading the ng-module. But in AoT local compilation mode it is not possible to get away since the component's dependencies are computed in runtime and the presence of the corresponding ng-module in the browser is needed. For this reason in this change it is forbidden to attempt to render a component without first loading its ng-module in local compilation mode and an explicit error message is created to make this situation clear. This error message can help with catching such cases when running TGP in Google.
It would be an interesting question as to whether to ban this situation in full compilation mode as well, as it is error prone and these errors are sometimes very hard to debug.
PR Close#51726
This commit adds explicit type annotations to the reactive node prototype objects,
such that the prototypes are type-checked against the interface they are supposed
to (partially) implement. This also allows IDEs to better track usages of reactive
node properties, improving code navigation.
PR Close#51722
When a producer is no longer used, the consumer has to update its internal data structure
that keeps track of all producers. There used to be an issue where only half of the stale
producers would actually be removed from this data structure, as the intended upper bound
of the number of producers to remove would decrease with each removed producer, therefore
not reaching all producers that should be removed from the data structure.
This commit fixes the issue by truncating the arrays directly, without going through
individual `pop` operations. An assertion that would catch the inconsistent state in
the internal data structures of the signal graph has been introduced.
PR Close#51722
Adds support for passing in `@Component.styles` as a string. Also introduces a new `styleUrl` property on `@Component` for providing a single stylesheet. This is more convenient for the most common case where a component only has one stylesheet associated with it.
PR Close#51715
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
Previously effects were queued as they became dirty, and this queue was
flushed at various checkpoints during the change detection cycle. The result
was that change detection _was_ the effect runner, and without executing CD,
effects would not execute. This leads a particular tradeoff:
* effects are subject to unidirectional data flow (bad for dx)
* effects don't cause a new round of CD (good/bad depending on use case)
* effects can be used to implement control flow efficiently (desirable)
This commit changes the scheduling mechanism. Effects are now scheduled via
the microtask queue. This changes the tradeoffs:
* effects are no longer limited by unidirectional data flow (easy dx)
* effects registered in the Angular zone will trigger CD after they run
(same as `Promise.resolve` really)
* the public `effect()` type of effect probably isn't a good building block
for our built-in control flow, and we'll need a new internal abstraction.
As `effect()` is in developer preview, changing the execution timing is not
considered breaking even though it may impact current users.
PR Close#51049
Improves the error handling story for after*Render by delegating errors to an ErrorHandler, so that one failure does not break every callback.
PR Close#51662
This commit updates the logic to add `prefetch on idle` support for defer blocks. Previously, the `on idle` logic was already implemented for the main loading and rendering. This commit reuses the same logic to bring it to the prefetching mechanism.
PR Close#51629
This flag allows message event listeners to prevent callbacks from executing within the NgZone if they contain a special `__ignore_ng_zone__` flag.
This functionality is built with Angular DevTools in mind, where it prevents an infinite change detection loop in inspecting applications that have message event listeners:
CD -> Inspected app emits componentTreeDirty event to DevTools -> DevTools emits event to get new component Tree from Inspected app -> Inspected app message event listener fires -> CD
PR Close#51339
These changes build on top of #51514 to add support for advanced expressions inside the `track` parameter of `for` loop blocks. There are two different outputs that the compiler can generate:
1. If the tracking function only references the item or `$index`, the compiler generates a pure arrow function as a constant references in the `repeaterCreate` instruction.
2. If the tracking function has references to properties outside of the `for` loop block, the compiler will rewrite those references to go through `this` and generate a function declaration. The runtime will `bind` the declaration to the current component instance so that the rewritten `this` references are resolved correctly.
Advanced tracking expression come with the following limitations to ensure the best possible performance:
1. They can only reference the item, `$index` and properties directly on the component instance. This means that there'll be an error when accessing this like local template variables and references. While we could get this to work, we would have to traverse the context tree at runtime which will degrade the performance of the loop, because it's a linear time operation that is performed on each comparison. Furthermore, allowing local references would require us re-evaluate the list when any one of them has changed.
2. Pipes aren't allowed inside the tracking function.
3. Object literals and pipes used inside the tracking expression will be recreated on each invocation.
PR Close#51618
Adds an instruction that allows us to access the containing component instance directly instead of having to traverse the context tree. This will be necessary for the tracking function of `for` loop blocks.
PR Close#51618
This commit updates the runtime implementation of defer blocks to avoid their triggering on the server. This behavior was described in the RFC (https://github.com/angular/angular/discussions/50716, see "Server Side Rendering Behavior" section): only a placeholder is rendered on the server at this moment. This commit also updates the logic to make sure that the placeholder content is hydrated after SSR.
PR Close#51530
This commit fixes a bug in the change detection algorithm that would
ignore the `OnPush`/dirty flag of a component's host when it is created
dynamically. That is, `OnPush` components that were not marked dirty but
were created as embedded views would have their host bindings and `ngDoCheck`
function always run even if they were not dirty.
BREAKING CHANGE: `OnPush` components that are created dynamically now
only have their host bindings refreshed and `ngDoCheck run` during change
detection if they are dirty.
Previously, a bug in the change detection would result in the `OnPush`
configuration of dynamically created components to be ignored when
executing host bindings and the `ngDoCheck` function. This is
rarely encountered but can happen if code has a handle on the
`ComponentRef` instance and updates values read in the `OnPush`
component template without then calling either `markForCheck` or
`detectChanges` on that component's `ChangeDetectorRef`.
PR Close#51356
This commit switches the signals library from a bidirectional symmetric
dependency graph using weak references, to a bidirectional _asymmetric_
graph which uses strong references. This is made possible with a reference
counting algorithm which only tracks producer -> consumer references for
effect-like "live" consumers, preventing memory leaks.
The new algorithm should be simpler and faster than the previous
implementation as weak references are fairly slow to create and traverse.
A tradeoff is that non-live consumers must now poll their producers when
read, as they cannot rely on dirty notifications.
As part of this refactoring, the `ReactiveNode` class is replaced with an
interface instead, and methods are moved to standalone functions. This is
paired with instantiating individual signals/computeds via `Object.create`
against a prototype node which contains static or initial values. This
technique, in conjunction with the rest, greatly improves the performance
of node creation.
PR Close#51226
In preparation for adding support for phases to after*Render, which will increase the implementation size, this commit splits out the optional logic so that it can be tree-shaken and dynamically loaded.
PR Close#51541
- Emphasized the importance of using the same InjectionToken instance for both provider and injection call.
- Added examples to illustrate correct usages to prevent NullInjectorError.
PR Close#51386
Fixes that there was code duplication between the primary entry-point,
the testing entry-point and the rxjs-interop entry-point.
This code duplication resulted in additional code size (really
neglibible here because rxjs-interop did not duplicate large parts of
core, and `testing` is not used in production).
On the other hand though, the duplication resulted in a subtle JIT
dependency tracking issue due to the `depsTracker` no longer being a
singleton. This caused test failures as in:
https://github.com/angular/angular/pull/51415.
PR Close#51500
With the new control flow and defer blocks it'll be common for several template instructions to be declare one after another. These changes add support for chaining to the `template` instruction which will allow us to save some bytes.
PR Close#51546
Adds the initial implementation to generate the instructions for the `for` loop block.
**Note:** the expressions we support in the `track` paramateter are currently limited to tracking by identity or index, or a specific property of the item. Supporting more advanced expression will require additional work that I'll do in a follow-up PR.
PR Close#51514
This commit fixes an issue where serialization of a view container fails in case it uses a component host as an anchor. This fix is similar to the fix from #51247, but for cases when we insert a component (that acts as a host for a view container) deeper in a hierarchy.
Resolves#51318.
PR Close#51456
This commit adds runtime implementation of a basic preloading mechanism for defer blocks. The base prefetching logic invokes a dependency loading function (generated by the compiler) when a corresponding `prefetch when` condition is triggered. The `prefetch on` triggers would be implemented in followup PRs.
We plan to explore additional prefetching techniques and will followup with more PRs later (based on the research).
PR Close#51529
