Document updated with the assistance of the SME.
Add missing prerequisites and what's next sections
Make suggested changes to Event binding doc.
PR Close#45897
New binding overview doc. Content derived from existing docs.
Make changes suggested in PR for binding overview doc.
Deleted bottom paragraph from Binding overview per comments made by
atscott and alxhub.
PR Close#45897
New Transforming data with pipes document.
Content taken from the original Pipes document.
Content edited with the assistance of the SME.
PR Close#45897
New overview file using the Understanding… format.
The original Pipes document was considered too long and
was broken down into several separate topics.
Content edited with the assistance of the SME.
PR Close#45897
Class and style binding was pulled out of Attribute, class, and style
binding doc and put in its own doc.
Content edited with the assistance of the SME.
Prerequisites and What's next sections were added.
PR Close#45897
Attribute document broken down into two separate documents:
1) Attribute binding
2) Class and style binding
Content edited with the assistance of the SME.
PR Close#45897
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
Previously, the examples were split across shards based on the order in
which `globby()` returned them. This was based on the assumption that
`globby()`/the OS would list files in a deterministic order. However, it
turns out that examples can be listed in different orders between
executions, leading in them not being split correctly across shards on
CI (which further means that some examples may be tested multiple times
and others may not be tested at all).
You can see an example [here][1], where the `getting-started` example is
tested in both the 4th and 5th shards.
This commit fixes this by explicitly sorting the examples based on their
path.
[1]: https://circleci.com/gh/angular/angular/1165448
PR Close#46005
This action will enforce that all pull requests receive an approval from
at least one googler on the final commit for the pull request. Historically,
we have allowed all post approval changes regardless of authorship. Moving
forward, with this change, we will only allow known googlers to perform
post approval changes.
When a post approval change occurs by a non-googler, the action will
automatically rerequest a review from the latest googler who provided
an approval on the change.
PR Close#46006
Currently, the `Router` will create the `EnvironmentInjector` for a
`Route` with `providers` as soon as it _attempts_ to match segments to
the `Route`. Instead, this change updates the logic to only create the
injector once we have confirmed that the `Route` matches. Note that this
will include partial matches where the final navigation still fails with
a "cannot match any routes to segment" error. We need to maintain the
injector hierarchy so we still need to create parent injectors before
descending into the child routes and determining if there is a full
match or just a partial one.
resolves#45988
PR Close#45990
The `inject()` function was introduced with Ivy to support imperative
injection in factory/constructor contexts, such as directive or service
constructors as well as factory functions defined in `@Injectable` or
`InjectionToken`. However, `inject()` in a component/directive constructor
did not work due to a flaw in the logic for creating the internal factory
for components/directives.
The original intention of this logic was to keep `ɵɵdirectiveInject` tree-
shakable for applications which don't use any component-level DI. However,
this breaks the `inject()` functionality for component/directive
constructors.
This commit fixes that issue and adds tests for all the various cases in
which `inject()` should function. As a result `ɵɵdirectiveInject` is no
longer tree-shakable, but that's totally acceptable as any application that
uses `*ngIf` or `*ngFor` already contains this function. It's possible to
change how `inject()` works to restore this tree-shakability if needed.
PR Close#45991
Use the absolute path for the artifacts directory, as well as encapsulate the clone
vs init logic to prevent it from changing directories.
Manually remove the shallow marker so that git does not recognize this as a shallow repo.
PR Close#45979
Rather than using git init to create an empty repo and then shallow fetch the
repo for a specific branch, we shallow clone the repository itself for the branch.
This prevents us from running into the issue of Github denying the push because it
comes from a shallow branch which does not map back to the repository.
PR Close#45975
It looks like because the primary branch for our ephemeral repos doesn't match the build repos
we are pushing to it causes errors around shallow clones. This attempts to prevent this.
PR Close#45974
Previously, the preview server would incorrectly identify a running
`aio_preview` CI job as failed and therefore skip creating a preview.
This happened because it only checked whether the job's status is
`success`, failing to account for the fact that the job would have a
`running` status.
(This bug was accidentally introduced in #45934.)
This commit avoids the problem by getting rid of the job status check
altogether. This check does not offer any benefit, since the CI job will
always be in a `running` state (i.e. neither successfully completed nor
failed).
PR Close#45948
This change adds the capability of ngc_wrapped to emit an
unused_inputs_list file that could be used by starlark.
We are making this change because in situations where angular modules
depend on angular modules, it becomes very easy for a single change to
trigger a long cascading set of angular builds since each angular rule
depends on the transitive closure of input files.
With this change in place, and once it is properly configured, bazel
will update the set of inputs to a build rule after it is built once
removing any of the inputs specified in this list, making incremental
builds quicker by skipping any rebuilds that only had changes to unused
inputs.
This logic should be, and is likely duplicated in tsc_wrapped to solve
the same problem in pure TypeScript situations, ideally we could use the
same implementation one day.
In addition, its possible that tree artifacts are not as supported as
we'd like, and where this change should mark entire directories as
unused, we may get better performance gains by enumerating the directory
and being more explicit about specific inputs which are unused.
PR Close#45946
This commit updates the Testability-related tests to reset the testability getter class after each test to avoid leaking the state between tests. This should improve the stability of the testability tests that are currently flaky on CI.
PR Close#45947
The Testability-related logic was refactored in https://github.com/angular/angular/pull/45657 to become tree-shaking-friendly: it was decoupled from the core providers of the `BrowserModule`. This commit updates the newly-introduced `bootstrapApplication` function to exclude Testability-providers by default (note: the Testability is still included in the NgModule-based bootstrap).
In order to add the Testability to the app bootstrapped via `bootstrapApplication`, the `provideProtractorTestingSupport` function is introduced.
PR Close#45885
Previously, using `FormBuilder` with a union type would produce unions of *controls*:
```
// `foo` has type `FormControl<string>|FormControl<number>`.
const c = fb.nonNullable.group({foo: 'bar' as string | number});
```
This actually works in many cases, due to how extraordinarily powerful Typescript's distributive types are (e.g. `value` still has type `string|number`), but it is subtly incorrect. Here is a code example that exposes the reason the inference is incorrect. It exploits the fact that Typescript will not "un-distribute" a type, producing an obviously spurious error:
```
// fc gets an inferred distributive union type `FormControl<string> | FormControl<number>`
let fc = c.controls.foo;
// Error: Type 'FormControl<string | number>' is not assignable to type 'FormControl<string> | FormControl<number>'.
fc = new FormControl<string|number>('', {initialValueIsDefault: true});
```
Instead, we want the union to apply to the *values*:
```
// `foo` should have type `FormControl<string|number>`.
const c = fb.nonNullable.group({foo: 'bar' as string | number});
```
Essentially, we want to prevent Typescript from distributing the type. [As specified in the handbook](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types):
> Typically, distributivity is the desired behavior. To avoid that behavior, you can surround each side of the extends keyword with square brackets.
This PR applies this suggestion to `FormBuilder`'s type inference.
Fixes#45912.
PR Close#45942
We've had a TODO to expose ManualOnPush for a long time, but it hasn't moved since then. These changes remove it since it would be easy to re-introduce if we wanted to, it frees up an extra space in the flags bitmap and it removes some `render3` tests that we won't have to migrate to `TestBed`.
PR Close#45943
When an external template is read, adds the template file to to the project which contains.
This is necessary to keep the projects open when navigating away from HTML files.
Since a `tsconfig` cannot express including non-TS files,
we need another way to indicate the template files are considered part of the project.
Note that this does not ensure that the project in question _directly_ contains the component
file. That is, the project might just include the component file through the program rather
than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important
because the TypeScript language service/server prefers projects which _directly_ contain the TS
file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can
possibly be a different project used between the TS and HTML files.
For example, in Nx projects, the referenced configs are `tsconfig.app.json` and
`tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and
contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS
files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files
but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot
effectively express `projectContainsInfoDirectly` for HTML files.
We could consider also updating the language server implementation to attempt
to select the project to use for the template file based on which project
contains its component file directly, using either the internal `project.projectContainsInfoDirectly`
or as a workaround, check `project.isRoot(componentTsFile)`.
Finally, keeping the projects open is hugely important in the solution style config case like
Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not
`tsconfig.app.json`. However, if our extension does not also know to select
`tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined
first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in
keeping projects open when there is an HTML file open and (2) optionally attempt to do this
_only_ for projects that we know the TS language service will prioritize in TS files (i.e.,
attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close)
and prioritize that project for all requests.
fixes https://github.com/angular/vscode-ng-language-service/issues/1623
fixes https://github.com/angular/vscode-ng-language-service/issues/876
PR Close#45601
Based on early feedback, calling `fb.nonNullable.group(...)` continues to be clunky for a form with many such groups. Allowing `NonNullableFormBuilder` to be directly injected enables the following:
```
constructor(private fb: NonNullableFormBuilder) {}
```
PR Close#45904
Explain how to use OnPush change detection strategy and what are the
different edge cases. Looks into several different scenarios and covers
the behavior of OnPush for each one of them.
PR Close#45880
Add a guide that explains:
- How we can slow the change detection down
- How to discover slow computations with Angular DevTools
- Explain how to fix slow computations
PR Close#45880
Explain the relationship between Angular and Zone.js. Covers how to
discover code that triggers change detection more often than we have to
run it and explain how to run code outside the Angular zone.
PR Close#45880
There was an extra backslash in the description of the pipe character. This could be misleading as people could think that the backslash is a pipe character.
PR Close#45916
Virginia Dooley