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
Reworks the compiler to use the API introduced in #51816 to match triggers to the element nodes they point to. This will be used to generate the new instructions for `on interaction` and `prefetch on interaction`.
PR Close#51830
The `NoopAnimationDriver` as static property of `AnimationDriver` prevents it from being removed by tree shaking. This commit deprecates it and exposes the `NoopAnimationDriver` on the public API to replace its usage.
DEPRECATED:
The `AnimationDriver.NOOP` symbol is deprecated, use `NoopAnimationDriver` instead.
PR Close#51843
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 type assertions.
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 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 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 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 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
We control most flags via Starlark and therefore limit configuration
options via `tsconfig` to a minimum. We do not intend to support the
enabled block types option via Starlark, so this commit allows for
the option to be picked up.
(This is useful for benchmarking the new control flow blocks).
PR Close#51862
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 an option to the view transition feature to skip the first transition.
This option is not available in RouterModule.forRoot.
resolves#51815
PR Close#51825
The `setupTestingRouter` function is a factory function for creating a
new instance of the `Router`. This function is effectively a no-op.
Developers should use `RouterModule.forRoot` or `provideRouter` in tests
instead.
BREAKING CHANGE: The `setupTestingRouter` function has been removed. Use
`RouterModule.forRoot` or `provideRouter` to setup the `Router` for
tests instead.
PR Close#51826
This PR moves the Observable subscription of toSignal outside of the
reactive context. As the result the toSignal calls are allowed in the
computed, effect and all other reactive consumers.
This is based on the reasoning that we already allow signals creation
in a reactive context. Plus a similar change was done to the async pipe
in the https://github.com/angular/angular/pull/50522Fixes#51027
PR Close#51831
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
So far this docs extraction has pulls API info from all exported symbols in the program. This commit changes to extracting only symbols that are exported via a specified entry-point. This commit also exports the docs entities through the compiler-cli `index.ts`.
PR Close#51828
This commit refactors the loadChildren callback execution of the router config loader
into a function that can be used with SSR for the purposes of route extraction.
PR Close#51818
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 the compiler in local mode assumes that the standalone component imports are array expressions. This is not always true as they can be const variables as well. This change allow non-array expressions for standalone component imports field and passes that expression to the downstream tools such as deps tracker to compute the component's deps in runtime.
PR Close#51819
Current implementation assumes that NgModule imports/exports fields are always arrays and thus it concats them for the injector definition. But this is not always the case and imports/exports could be non-arrays such as const variable. Such pattern happens in g3 and so must be addressed.
PR Close#51819
Adds support for template type checking of the `track` expression of a `for` loop block. Tracking expressions are treated as any other expression for type checking, however we have some special validation that doesn't allow them to access template variables and local references.
PR Close#51690
Adds support for template type checking inside `for` blocks. It is implemented by generating a JS `for...of` statement inside the TCB. The various loop variables (e.g. `$index`) are implemented by declaring a local number variable.
PR Close#51690
Adds support for template type checking inside `if` blocks. It is implemented by generating a JS `if` statement inside the TCB which allows us to do type narrowing of the expression. The `as` parameter is implemented by declaring a variable inside the `if` statement.
PR Close#51690
Adds support for template type checking inside `switch` blocks. It is implemented by generating a JS `switch` statement inside the TCB which allows us to do type narrowing of the expression.
PR Close#51690
The browserUrlTree is only used to support the onSameUrlNavigation: 'ignore' logic. We can achieve this functionality without having this state tracked inside the Router. Instead, we can re-examine what ignore means: We don't want to rerun the matching logic, guards, or resolvers when we already know that nothing is changing.
Outside of the "navigated", there are two things that constitute a "change":
1. The browser URL might change. Because of skipLocationChange, the browser URL might not always match the internal state of the Router (we can navigate to a path but skip updating the browser URL). If we're navigating to a place that would change the browser URL, we should process the navigation. Theoretically, all we need to really do is update the browser URL instead of processing the whole navigation w/ guards, redirects, and resolvers. But this doesn't matter that much because the default value for runGuardsAndResolvers will skip all of this anyways.
2. The internal state of the Router might change. That is, we're navigating to a new path and may or may not be updating the updating the browser URL.
If either of the above are true, we process the navigation. If both are false, we aren't changing anything so we can safely ignore the navigation request (as long as onSameUrlNavigation === 'ignore').
Why is this change important?
* Simplification of Router internals. The Router has a lot of special case handling and one-offs to handle a limited set of scenarios. Removing these when possible makes the code easier to follow
PR Close#48065
Adds a utility to the `BoundTarget` that helps with resolving which element a deferred block is pointing to. We need a separate method for this, because deferred blocks have some special logic for where the trigger can be located.
PR Close#51816
When the `TargetBinder` was written, the only embedded-view-based nodes were templates, but now we have `{#if}`, `{#switch}` and `{#defer}` which have similar semantics. These changes rework the binder to account for the new nodes.
PR Close#51816
Content project allows the content to specify its own selector for matching against content projection slots, using the `ngProjectAs` special attribute. We can now treat this attribue specially, and generate the appropriate flag in the consts array, followed by the parsed CSS selector.
PR Close#51544
Supporting content projection requires us to emit three new kinds of output:
1. An `ngContentSelectors` field on the component metadata, which points to an array in the constant pool with all of the `select` attributes from `<ng-content>` elements.
2. One `projectionDef` instruction at the beginning of each root view template function for a component. That `projectionDef` points to a constant pool expression, which contains *parsed* selectors for all `<ng-content>` elements in the root's entire view tree.
3. A `projection` instruction for each `<ng-content>` slot in the view tree. These each get a data slot, a monotonically increasing "content slot", and a pointer to the tag's attributes in the component const array.
We support the first two features entirely within a new compilation phase.
The third feature, collection of processed attributes, is a bit trickier. We now treat `<ng-content>` tags as element-like ops, and use the normal attribute ingestion pipeline to process any attributes, and assign the appropriate `ConstIndex`.
**Note**: We also split up a number of the tests into two expectations files, one for the view functions, and one for other const listerals from the constant pool. This is because `TemplateDefinitionBuilder` emits the literals in a quirky order (mixed in with the view functions) due to how it lazily generates view functions. Our eager ordering is totally different, but by splitting the expectations, we can still share the same tests with `TemplateDefinitionBuilder`.
PR Close#51544
The new built-in control flow design includes calls to the `template` instruction with fewer arguments. This was previously handled implicitly, but it's more extensible to add an explicit flag to the template op to handle this case.
PR Close#51544
The `malformedUriErrorHandler` is used as a recovery mechanism for when the `UrlSerializer`
throws an error when parsing a URL string. If custom error handling is
desired for this, it should instead be done inside the
`UrlSerializer.parse` method itself. There's no reason to have an entire
feature option built around what can otherwise just be `try...catch`.
BREAKING CHANGE: `malformedUriErrorHandler` is no longer available in
the `RouterModule.forRoot` options. URL parsing errors should instead be
handled in the `UrlSerializer.parse` method.
PR Close#51745
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
Today in local compilation mode the NgModule bootstrap definition is moved as it is into the runtime `ɵɵdefineNgModule`. This runtime was initially made for AoT full compilation mode and assumes that the bootstrap info is already flattened and resolved. This is not the case in local compilation where the bootstrap is the raw expression coming from the NgModule decorator and can be a nested array. To get around this problem we move the bootstrap along with other scope info (e.g., declarations, imports, exports) to the runtime`ɵɵsetNgModuleScope` to be further analyzed and flattened in runtime.
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
