`inject()` originated as a private API and was made public to support
`InjectionToken` factories in Ivy. For code-size and performance reasons,
when we code generate `inject()` calls we use a bit field to indicate the
various injection modes (optional, skip-self, etc). However, this doesn't
make for a very nice public API.
This commit introduces an alternative object-based API for options. All 4
flags are supported as `boolean` fields on an options object, and converted
to bit flags internally. If TypeScript can prove that `optional` injection
is not requested, it can narrow the return type and remove the `null` type.
DEPRECATED:
The bit field signature of `inject()` has been deprecated, in favor of the
new options object. Correspondingly, `InjectFlags` is deprecated as well.
Fixes#46251
PR Close#46649
The test apps are bundled using their production ESM JS output using
`esbuild`. ESBuild warns about any CJS usages, like `module.exports.`
```
INFO: From Bundling Javascript packages/core/test/bundling/todo_i18n/index.ts [esbuild]:
▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected
bazel-out/k8-fastbuild/bin/packages/core/test/bundling/todo_i18n/index.mjs:494:0:
494 │ module.exports = {
╵ ~~~~~~
This file is considered to be an ECMAScript module because the file name ends in ".mjs".
```
Some bundling tests currently use `module.exports` to make
functions/symbols available to specs later requiring the bundle (in
order to run the bundle). Instead of using the CJS global here, the
logic can be attached consistently to `window` (there is currently a
mismatch of window vs. module.exports anyway..).
PR Close#46642
This commit introduces a new API on `EnvironmentInjector` to run a function
in the context of the injector. This makes `inject()` available within the
body of the function to inject dependencies. We expect this functionality to
be very useful for designing ergonomic APIs both in and out of Angular, as
it should allow for a smaller and more functional API style.
Note that it's possible to implement nearly identical functionality in user
code already today:
```typescript
function runInContext<T>(injector: EnvironmentInjector, fn: () => T): T {
const token = new InjectionToken<T>('TOKEN');
const tmpInjector = createEnvironmentInjector([
{provide: token, useFactory: () => fn()},
], injector);
return tmpInjector.get(token);
}
```
The factory provider for `token` in this example runs in the context of the
`tmpInjector`, giving it access to `inject` that can retrieve values from
`injector` as well. This is nearly identical, although because of the child
injector `self` and `skipSelf` injection options don't function correctly.
PR Close#46653
This commit removes the `Renderer3` experiment which attempted to use the
real DOM API as Angular's renderer. As shown in the diff, having this
experiment around added real code complexity to Angular that could not be
removed by an optimizer.
Since we no longer feel this experiment is worth continuing, we're removing
the `Renderer3` concept and all supporting code.
PR Close#46605
Previously, when instantiating a component, Angular would look in the DI
hierarchy for `RendererFactory2`. Any DI tree which rolls up through an
application injector (that is, one created with `BrowserModule`) should be
able to provide this interface. If not found, Angular would switch to the
experimental `Renderer3` mechanism. This switch was designed this way,
because it allowed for the creation of experimental applications where
`RendererFactory2` was not included in the bundle at all.
In this commit, instead of automatically falling back on `Renderer3`-style
rendering, an error is raised instead if `RendererFactory2` is missing from
the DI hierarchy.
PR Close#46605
This commit migrates any remaining Angular tests which are using some form
of Renderer3 interfaces. Instead, they're switched to Renderer2.
PR Close#46605
Due to the restrictions of circular dependency checking, we need a separate
internal interface for a renderer. We cannot use `Renderer2` as a type
internally as even importing it as a type incurs a dependency on its
implementation, which creates a major potential for circular dependencies.
Previously this role was served by the `Renderer3` type. As we prepare to
remove the `Renderer3` abstraction (the idea of using `document` as a
differently-shaped renderer), this commit renames `ProceduralRenderer3` to
the more generic term `Renderer`.
`RendererFactory3` is also renamed to the more generic `RendererFactory` for
consistency.
PR Close#46605
Remove calls to enableRenderer3 in the functional unit tests.
This effectivelly cuts code paths going through the Renderer3
in the functional tests.
PR Close#46612
This commit converts the remaining bundling tests which were using
`renderComponent` to use regular bootstrapping instead.
Since `renderComponent` is synchronous and regular bootstrapping is not,
some test adjustments were necessary to wait for bootstrapping before test
assertions could run.
Additionally, debug servers were adjusted in some cases where they'd broken
(likely some time ago).
PR Close#46559
The deleted r3 versions of these tests had symbol tests, but their r2
equivalents did not. This commit adds symbol tests to the r2 variants.
PR Close#46559
In the previous commit, the r3-based hello_world and todo tests were deleted
in favor of the r2 versions. This commit renames the r2 versions to drop the
r2 suffix.
PR Close#46559
The `hello_world` and `todo` bundling tests use the experimental
`renderComponent` function (and `Renderer3`) as a result, and have
corresponding `Renderer2` equivalents. This commit removes these tests in
favor of the `Renderer2` versions, which will be renamed in a future commit.
PR Close#46559
This commit updates various tests to use TestBed instead of hand-written instructions, which makes tests easier to maintain and allows to perform further cleanup.
PR Close#46561
This commit updates the `ApplicationRef` logic to trigger the destroy operation when an underlying platform is destroyed. This is needed to make sure all teardown processing is completed correctly to avoid memory leaks.
Closes#46473.
PR Close#46497
Replace `new Error()` in a forms Validators function with `RuntimeError`, for better tree-shakability. Also, improve the error messages, and add documentation.
PR Close#46537
The `Renderer3` abstraction in Angular was an experimental code path in Ivy
which uses direct DOM operations instead of the former `Renderer2` path. To
allow `Renderer2` to tree-shake away, `Renderer3` is the default _unless_
`Renderer2` is provided. It was only an experiment, and never meant to be a
production code path.
However, it's possible for `Renderer3` to leak into user code. This commit
prevents that possibility by causing the `Renderer3` path to throw, unless
an explicit function has been called to enable it.
PR Close#46530
This commit updates a set of tests to avoid using hand-written instructions and replace them with TestBed APIs. Some tests were moved to the `acceptance` folder to colocate them with other renderer-related tests.
PR Close#46525
di_spec.ts was using handwritten definitions and the `renderComponent`-based
`ComponentFixture` (left over technical debt from the early days of Ivy.
This commit updates it to:
* remove unnecessary tests ("limp mode" DI, Renderer3, etc)
* convert other tests to use JIT-compiled classes and not handwritten defs
PR Close#46522
This commit finishes converting providers_spec.ts from `ComponentFixture`
and handwritten definitions to TestBed and JIT-compiled standalone
components.
PR Close#46527
This commit replaces usage of the internal `directiveInject` instruction
with the public `inject` function, as part of a larger cleanup of
providers_spec.ts.
PR Close#46527
This commit convers the providers_helper utility function
`expectProvidersScenario` to use the TestBed internally instead of
`ComponentFixture` and handwritten defs. This required several adjustments:
* Making the `ngModule`s passed in to the helper utility real NgModules.
* Using `ViewEncapsulation.None` for the test components (stabilizes the
generated HTML).
* Convert handwritten test components & directives into JIT-compiled
standalone equivalents.
PR Close#46527
when a component uses the shadowDom view encapsulation its children are
not rendered as normal HTML children of the element but they are
insterted in the element's shadowRoot, this causes the leave of the
element not to be normally propagated to the shadow child elements, fix
such issue
resolves#46450
PR Close#46459
This change separates the router initializer into different providers.
While it does not actually change the tree-shakeablity or the public
API, it does move us towards a world that _could_ do this. That is,
instead of `initialNavigation: 'disabled'`, users could use
`provideDisabledInitialNavigation` in the `bootstrapApplication` call
and none of the code for `initialNavigation: 'enabledBlocking'` would be
included in the application.
PR Close#46215
Extracting preloading to a provider moves us towards
thinking about a world where `ExtraOptions` doesn't exist to control
behaviors that are opt-in/opt-out. Instead, these behaviors could be
controlled by the presence (or lackthereof) of the providers which has
the functionality. This is relevant to a world in which we no longer
have the `RouterModule` but instead have something like `provideRouter`
where the features are tree-shakeable.
This change _does not_ make the `RouterPreloader` tree-shakeable inside
`RouterModule.forRoot` because the compiler cannot statically determine
whether it's needed. However, in the `provideRouter` world without
`forRoot`, preloading could be exposed through the provider function
instead, making the `RouterPreloader` and `PreloadingStrategy`
implementations tree-shakeable for those that don't use it (which is the
default - no preloading).
PR Close#46215
During JIT compilation of standalone components the compiler did not deduplicate
declarations in the imports array, unlike the AOT compiler. This may result in
runtime errors during directive matching, when the same component is found
multiple times resulting in NG0300, for example:
> NG0300: Multiple components match node with tagname mat-form-field: MatFormField and MatFormField.
This commit fixes the issue by deduplicating imports in the JIT compiler.
Relates to https://github.com/angular/angular/issues/46109#issuecomment-1160705031Closes#46109
PR Close#46439
Fixes that the server renderer was producing an invalid `style` attribute when a null value is passed in. Also aligns the behavior with the DOM renderer by removing the attribute when it's empty.
Fixes#46385.
PR Close#46433
Prior to this commit, the TestBed logic erroneously tried to apply provider overrides to standalone pipes that were imported in an NgModule. This commit updates the logic to recognize types that may have a scope (an NgModule or a standalone component) and skip other types while applying provider overrides recursively.
PR Close#46407
Previously, the `createEnvironmentInjector` function allowed creating an instance of an EnvironmentInjector without providing a parent injector. This resulted in an injector instance, which was detached from the DI tree, thus having limited value. This commit updates the types of the `createEnvironmentInjector` function to make the parent injector a required argument.
PR Close#46397
The `Observable` chain is currenlty the most straightforward way to
handle navigation cancellations where we ensure that the cancelled
navigation does not continue to be processed. Until we design and
implement an alternative way to accomplish equivalent functionality,
we need to maintain the `Observable` chain wherever we might execute
user code. One reason for this isthat user code may contain redirects so we do not
want to execute those redirects if the navigation was already cancelled.
PR Close#46021
* beforePreactivation hook is unused
* The only place that uses afterPreactivation does not use the arguments
Not to say we won't want to provide hooks similar to this in the future,
but the current state is over-engineered for what it's being used for.
PR Close#46321
Consider the case in which `FormBuilder` is used to construct a group with an optional field:
```
const controls = { name: fb.control('') };
const foo: FormGroup<{
name: FormControl<string | null>;
address?: FormControl<string | null>;
}> = fb.group<{
name: FormControl<string | null>;
address?: FormControl<string | null>;
}>(controls);
```
Today, with fully strict TypeScript settings, the above will not compile:
```
Types of property 'controls' are incompatible.
Type '{ name: FormControl<string | null>; address?: FormControl<FormGroup<SubFormControls> | null | undefined> | undefined; }' is not assignable to type '{ name: FormControl<string | null>; address?: FormGroup<SubFormControls> | undefined; }'.
```
Notice that the `fb.group(...)` is calculating the following type for address: `address?: FormControl<FormGroup<string|null>`. This is clearly wrong -- an extraneous `FormControl` has been added!
This is coming from the calculation of the result type of `fb.group(...)`. In the type definition, if we cannot detect the outer control type, [we assume it's just an unwrapped value, and automatically wrap it in `FormControl`](https://github.com/angular/angular/blob/14.0.0/packages/forms/src/form_builder.ts#L66).
Because the optional `{address?: FormControl<string|null>}` implicitly makes the RHS have type `FormControl<string|null>|undefined`, [the relevant condition is not satisfied](https://github.com/angular/angular/blob/14.0.0/packages/forms/src/form_builder.ts#L55). In particular, the condition expects just `FormGroup<T>`, not `FormGroup<T>|undefined`. So we assume `T` is a value type, and it gets wrapped with `FormControl`.
The solution is to add the cases where `undefined` is included in the union type when detecting which control `T` is (if any).
PR Close#46253
Alex Rickabaugh