This adds a test to illustrate the "canceling" behavior we get from the
`Observable` chain in the Router. A new navigation cancels ongoing ones,
and that means also preventing intermediate results in user guards from
executing. This test is important when thinking about future refactors
which might attempt to change the details of how the `applyRedirects`
operator executes.
PR Close#46231
We currently use all the ESM2020 and type sources as inputs for rollup
and type bundle actions, respectively. This is a source of slowness in
Bazel sandboxed builds because many unused files will be linked/made
available for many concurrently-running actions.
We should limit the inputs only to what is assumed to be used. We cannot
know exactly and need to include transitive types from `node_modules`,
but that is an inevitable construct with the current Bazel rules.
Note that the external node modules could still bring in a lot of files,
like in Material where the `.d.ts` files for all locales are brought
into the sandbox (from `@angular/common`). We likely would need to
remove these files in a postinstall for now, to speed up actions,
similar to how we did it for RxJS in all repositories. These are known
to be not used in the components repo.
PR Close#46187
To mitigate the effect of Observables with memory leak, this change clears
the `ChangeDetectorRef` when the `AsyncPipe` is destroyed. This avoids any
leak within the `Observable` to retain the view data. A test has been added
to verify that this change works correctly with promises that resolve _after_
the pipe has been destroyed.
Note: this is not marked as fix as `AsyncPipe` itself is _not_ leaking any
memory.
Closes#17624
PR Close#46128
The field's type does not account for the `null` value that is assigned
in the field's initializer. This commit includes `null` in the type for
better type-safety. Exising reads are updated with a non-null assertion
operation in places where initialization is known to have occurred.
PR Close#46128
Makes the following improvements in the runtime:
* Uses the unique ID of the component definition to keep track of its injector in the `StandaloneFeature`, instead of the definition itself. This reduces the amount of memory we can leak, if something doesn't get cleaned up.
* Changes the naming and description of the `ComponentDef.id` to reflect what it is used for.
PR Close#46093
There's some old logic in the error handler that tries to read an `ngErrorHandler` property off of the errors that are being logged. As far as I can tell, this is a ViewEngine leftover and it isn't actually being used anywhere.
PR Close#46216
In #45445 function inlining had to be disabled on one of our instructions, because Closure wasn't optimizing it correctly, causing an error at runtime. The error has been resolved so we can remove the deoptimization hint.
PR Close#46149
When generating .d.ts metadata for NgModules, by default we emit type
references to their declarations, imports, and exports. However, this
information is not necessarily useful to consumers. References to private
directives (those that aren't exported by the NgModule) for example aren't
at all useful as they can only affect other components declared in the
NgModule. References to imports are of limited usefulness - they might be
helpful for an IDE to understand the DI structure of an application, but
aren't at all used by a downstream compiler.
Generating this metadata is not without cost. When an incremental build
system uses changes in inputs to determine when a rebuild is necessary, any
changes in .d.ts files might cause downstream targets to rebuild. If those
.d.ts changes are in the "private" side of the NgModule (imports or non-
exported directives/pipes), then these rebuilds are wholly unnecessary.
This commit introduces the `onlyPublishPublicTypingsForNgModules` flag for
the compiler. When this flag is set, the compiler will filter the emitted
references in NgModule .d.ts output and only reference those directives/
pipes that are exported from the NgModule (its public API surface). Omitting
the flag preserves the existing behavior of emitting all references, both
public and private.
This is especially useful for build systems such as Bazel.
PR Close#45894
This commit adds the new `@developerPreview` tag to all of the standalone
component related APIs. With this, AIO will show an API status label which
links to the documentation on Developer Preview.
PR Close#46050
This commit updates the `bootstrapApplication` and the `importProvidersFrom` function docs with additional content that includes usage examples.
PR Close#46202
This makes a small update to the example so that it shows a use-case
that's not already covered by the 'enabled' option. The existing example
would get identical behavior to `scrollPositionRestoration: 'enabled'`
with `anchorScrolling: 'enabled'`.
The updated example shows a use-case for when custom scrolling _would_
be needed. For example, when data is fetched because it is not available
immediately or through a resolver. This is one of the cases described in #24547
This update is sufficient to address all of the documentation problems
noted in the aforementioned issue. Another fix should be made to address
the problem that scroll restoration needs to be delayed until after CD
has run so the update block of the activated component's template is
run.
PR Close#46201
This commit adds the Standalone guide link to the `@Component`, `@Directive` and `@Pipe` decorator properties related to standalone functionality to improve discoverability of the guide as well as providing extra context in API docs.
PR Close#46184
This commit updates the `inject` function docs by:
- rephrasing a description to include more usage cases
- adding usage examples
- making a function itself a public API (vs its alias const that was used previously)
PR Close#46168
This commit adds the component name into unknown element/property error message, so that it's easier to find a location of a template where the problem happened.
Closes#46080.
PR Close#46160
The MISSING_INJECTION_CONTEXT runtime error can be thrown when the
inject function is used outside of the class creation context.
Before this change we've only used a vague terms of the
'injection context'. This commit extends the error message to
indicate that we really talk about the class construction context.
PR Close#46166
This commit updates the error message to use correct info depending on whether a component is standalone or not. Previously we were always referring to @NgModules as a place to fix the issue, but not we also mention @Component when needed (for standalone components).
PR Close#46159
Angular generally supports cycles between components in the same NgModule.
We have a mechanism of moving the component scope declaration into the
NgModule file in this case. This ensures that Angular never itself
introduces an import which creates a cycle.
What happens if the cycle already exists in the user's program, though, is a
bit different. In these cases, the "correct" emit for Angular is to generate
the component scope (whether direct or remote) inside of a closure, to
prevent evaluating the scope's references until module evaluation is
complete and all cyclic imports have been resolved. We don't want to do this
for *all* scopes because the code size cost of emitting a function wrapper
is non-zero.
In this fix, we take the presence of a `forwardRef` in a component's
`imports` or in an NgModule `declarations` or `imports` as a sign that
component scopes emitted into those files need to be protected against
cyclic references. In a future commit, we may introduce a warning or error
if cyclic imports are not protected behind `forwardRef` in these cases, but
this will take some time to implement.
PR Close#46139
Prior to this commit, the error message that was produced for the unknown property situation, din't contain extra info on how the problem can be fixed. This commit adds more info to the error message and makes it similar to the one we use during the AOT compilation.
PR Close#46147
improve the error message developers get when adding a standalone
component in the TestBed.configureTestingModule's declarations array,
by making more clear the fact that this error originated from the
TestBed call
resolves#45923
PR Close#45999
This exposes a new function from the router public API that allows
developers to create a `UrlTree` from _any_ `ActivatedRouteSnapshot`.
The current Router APIs only support creating a `UrlTree` from an
`ActivatedRoute` which is both active _and_ materially appears in the
`UrlTree` (it cannot be an empty path named outlet). This is because the
implementation of the current way of creating a `UrlTree` attempts to
look up the `UrlSegment` of the `ActivatedRoute` in the currently active
`UrlTree` of the router. When this doesn't work, the `UrlTree` creation
fails.
Note that this API does not replace the current one. That would actually be a
breaking change but should be done at some point in the future (v15). That is,
`router.navigate` should call this new function. At that point, we can
remove `_lastPathIndex`, `_urlSegment`, and `_correctedPathIndex` from
the `ActivatedRoute`, along with all of the logic associated with
determining what those should be. In addition, this would unblock a fix
for #26081 because the `applyRedirects` and `recognize` operations
could be combined into one. Overall, this would simplify logic in the router
and reduce code size. It also exposes core routing capabilities as a helper function
which were previously private API, which is a necessary step towards #42953.
As a stress test for this new function, it _was_ swapped in as the
default for `UrlTree` creation in #45859 and tested internally. The
results indicate that this function behaves correctly.
resolves#42191 (Tested directly)
resolves#38276 (The test with a guard covers this case)
resolves#22763 (Tested directly)
PR Close#45877
Call tsc_wrapped's fileExists function instead of TypeScript's.
tsc_wrapped (used internally by ngc-wrapped) has an optimization under
bazel to avoid file system calls where possible. It takes advantage
bazelOpts.allowedInputs, which contains a list of all files available
for compilation.
File system calls can be quite slow depending on the file system. In
google3 I saw a 38 seconds compilation, which spent 6 seconds just doing
fs.stat calls during module resolution. Those fs.stat calls are entirely
gone after with this change.
PR Close#46069
This commit improves the reported error when importing e.g. `RouterModule.forRoot()`
from within `Component.imports`. Such import is not supported, as standalone components
can only refer to other standalone entities or NgModules in their `imports` array;
`ModuleWithProviders` are not supported as `Component.imports` is meant to be used
for the compilation scope of the component, _not_ for configuring DI.
Closes#46003
PR Close#46009
This commit moves the foreign function resolver logic for detecting a
`ModuleWithProviders` in a return type position of a function call, as the logic can
then be reused for standalone components in a subsequent commit.
PR Close#46009
tweak the current structural directives guide (currently mainly targeted
at the creation of custom structural directives) so that is more generic
and a point of reference for structural directives in general
this also includes the re-addition of the one-per-element section
removed in PR #40015resolves#44786
PR Close#44895
The formatting of the `babel_ast_host.ts` file is invalid due to a
recently-merged PR. The PR had a passing `lint` state but this seemed
to just appear like this because the Git comparison range on upstream
branches can become invalid (due to a known bug in CircleCI -- reported)
PR Close#46082
update the error message presented during aot compilation when an unrecognized
tag/element is found in a standalone component so that it does not mention
the ngModule anymore
Note: the jit variant is present in PR #45920resolves#45818
PR Close#45919
Currently for cases when an unknown structural directive is applied to `<ng-template>`s, an error message thrown by the framework doesn't contain a tag name, for example:
```
NG0303: Can't bind to 'unknownDir' since it isn't a known property of 'null'.
```
The underlying reason is that the tag name for the `<ng-template>` is not produced (`null` is useed as a value) by the compiler in case of inline templates and runtime logic relies on this effect.
This commit handles this situation when an error message is thrown, as the fastest way to improve the error message. More refactoring would be needed to avoid relying on the mentioned effect at runtime.
PR Close#46068
update the error message presented during jit compilation when an unrecognized
tag/element is found in a standalone component so that it does not mention
the ngModule anymore
Note: the aot variant is present in PR #45919resolves#45818
PR Close#45920
Previously, the code in TestBed didn't take into account the fact that the `cmp.dependencies` array after the AOT compilation might contain regular (NgModule-based) Components/Directive/Pipes. As a result, some NgModule-specific code paths were invoked for non-NgModule types, thus leading to errors.
This commit updates the code to handle AOT-compiled structure of standalone components correctly.
PR Close#46052
This commit updates the NgModule logic to account for a case when a type has more than one generated def. This is a common situation for NgModules which have at least two: ɵmod and ɵinj. Previously, the second def was not stored before applying overrides, thus leaving it modified after the test, leaking the state as a result. This fix ensures that we store all defs before applying any overrides.
PR Close#46049
This commit accounts for the Babel types changes. Some properties
can now also be `undefined` so existing checks/assertions had to
be adjusted to also capture `undefined` (along with `null`).
Additionally, in preparation for a new ECMA proposal, Babel types
seem to have been updated to include private names in object property
keys. This is not necessarily the case for object expressions, but
could be for object patterns (in the future -- when implemented).
More details: https://github.com/babel/babel/pull/14304 and
https://github.com/tc39/proposal-destructuring-private.
PR Close#45967
We recently updated Babel and the Bazel types but this actually
resulted in duplicates, causing differences between what people
seen in their IDE vs. what Bazel builds.
This commit removes the lock file and generates it fully fresh,
deduping dependencies and also fixing the differences between
local IDE and Bazel.
As part of this we also need to update/fixup one assertion on the
Babel node path types, because the node start/end can now also
be `undefined`.
PR Close#45967
DEPRECATED:
It is now deprecated to provide *both* `AbstractControlOption`s and an async validators argument to a FormControl. Previously, the async validators would just be silently dropped, resulting in a probably buggy forms. Now, the constructor call is deprecated, and Angular will print a warning in devmode.
DEPRECATED:
The `initialValueIsDefault` option has been deprecated and replaced with the otherwise-identical `nonNullable` option, for the sake of naming consistency.
In some places, the [@see][1] JSDoc tag was incorrectly used instead of
the [@link][2] inline tag, leading to warnings during doc generation and
the `@see` tags being ignored (and thus shown in the docs as is).
Replace the `@see` tags with the intended `@link` tags.
[1]: https://jsdoc.app/tags-see.html
[2]: https://jsdoc.app/tags-inline-link.html
PR Close#46040
Adds additional tests to verify `enabledBlocking` functionality. The
initial attempt to fix#44355 would have broken the scenario where a new
navigation cancels the initial navigation. We also cannot rely on
`NavigationError` like the example workaround in that issue report is
doing because there won't be one if a guard simply rejects
the initial nav (#16211).
PR Close#45733
This commit fixes a small issue in the logic around the calculation of
template scopes for standalone components. These scopes include a
`Reference` for each dependency of a standalone component, which is used to
generate references to that dependency in various contexts.
Previously, the `Reference` used for a dependency was the one generated from
its own metadata. For example, a referenced directive used the `Reference`
that was created when analyzing the directive declaration itself. This still
works, as the compiler is always able to emit a reference to any valid
`Reference`. However, it's not optimal.
The `Reference` which should be used instead is the one generated from
analyzing the standalone component's `imports` array, which has knowledge of
how the dependency is referenced from within the standalone component's file
itself. This allows the compiler to skip creating a new import for the
dependency when emitting the standalone component, and use the existing,
user-authored import instead. This saves on code size and avoids taxing the
bundler with unnecessary imports.
PR Close#46029
The Angular compiler performs cycle detection when generating imports within
component files. This was previously necessary as reifying dependencies
discovered via NgModules into the component output could add imports that
weren't present in the original component and potentially create cycles.
Doing this could cause order-of-execution issues with existing user imports,
so the compiler detects this case and falls back to an alternative way of
specifying component dependencies that doesn't risk creating cycles.
For standalone components, Angular does not need to add new imports to the
component file as the user has already explicitly referenced dependencies
in the `@Component.imports`. As a result, the cycle detection can be
skipped.
Correctly authoring a program with import cycles is always challenging. One
side of a cyclic import will always initially evaluate to `undefined`, and
this can result in errors in the component definition when this happens
within component `imports`.
Our compiler _could_ detect the cycle and choose to wrap the component
dependencies in an automatic closure instead, avoiding any issues with
`undefined` during an eager evaluation. However, this commit makes an active
choice not to do that as it only serves to mask the problems with cyclic
imports. Future refactorings may cause the "other half" of the cycle to
break. Users should instead be aware of the potential problems with cycles
and explicitly defer evaluations with `forwardRef` where needed. This
ensures that future implementations of Angular compilation which may not be
able to automatically detect import cycles and correct accordingly can still
compile such components.
PR Close#46029
* `FormRecord` jsdocs should now appear on a.io
* The `{@see foo#bar}` syntax previously did not work, and has been replace with backticks
PR Close#46023
Consider a typed group for storing contact information:
```
declare interface ContactControls {
name: FormControl<string|null>;
}
contactForm: FormGroup<ContactControls> = ...;
saveForm(form: FormGroup<ContactControls>) {
service.newContact(contactForm.value);
}
```
What should be the type of `newContact`? The answer, of course, is the value type:
```
declare interface Contact {
name: string|null;
}
class ContactService {
newContact(c: Contact) {}
}
```
This is quite redundant, and therefore, we should allow the value type to be generated automatically. We already have the helper types to do this -- we just need to document and export them. Then, this becomes possible:
```
class ContactService {
newContact(c: RawValue<FormGroup<ContactControls>>) {}
}
```
PR Close#45978
This commit adds the `ngDevMode` check to tree-shake away an error message string (which also retains a reference to an extra function).
PR Close#45994
Andrew Scott