Introduces a referrer policy option for HTTP requests to allow specifying the referrer information sent, improving privacy and security controls.
PR Close#64116
Move most of the implementation of the `Control` directive into core
framework instructions. This allows field state changes to be propagated
to their corresponding UI controls directly during execution of a
template update block, instead of relying on `effect()`s to synchronize
each change later during the update (and too late in the case of
required inputs).
* Define a private API in `@angular/core` for signal forms to implement:
* `ɵControl` for the `Control` directive.
* `ɵFieldState` for the control's associated `FieldState`.
* Emit specialized instructions when compiling a `[control]` binding:
* `ɵɵcontrolCreate` sets up the `ɵControl` directive if present,
determines whether it's bound to a native control element or a
custom control component, and adds the appropriate event listeners
to notify the `ɵFieldState` of UI changes.
* `ɵɵcontrol` propagates changes from `ɵFieldState` properties to their
corresponding UI control properties (in additional to binding the `control`
property itself).
PR Close#63773
There are two primary reasons for this renaming:
1. It better reflects the actual nature of the proxy object, namely that
the form is represented as a tree, and that this object is used for
navigating the tree structure (while `FieldState` is used for getting
the state at a particular point in the structure).
2. This frees up the name `Field` to be used for the directive that
binds a `FieldTree` to a UI control.
PR Close#64214
Since HTTP/2, responses no longer contain a status text besides the status code, which caused our default value of 'OK' to be used in HttpErrorResponse.message.
DEPRECATED: `HttpResponseBase.statusText` is deprecated
PR Close#64176
This commit updates the TypeScript configuration across the project to use `moduleResolution: "bundler"`. This modernizes our module resolution strategy to align with current TypeScript best practices and bundler behaviors.
The following changes are included:
- Updated `tsconfig.json` files to set `moduleResolution` to `"bundler"`.
- Updated the `rules_angular` bazel dependency to a version compatible with these changes.
- Adjusted related test files and golden files to reflect the new module resolution strategy.
PR Close#64125
This commit changes `Resource.hasValue()` and its derived types to improve narrowing
of resources whose generic type either does not include `undefined` (i.e. when a default
value has been provided) or when the generic type is `unknown`. This fixes the undesirable
behavior where `hasValue()` would cause the `else` branch of an `hasValue()` conditional
to have a narrowed type of `never`, given that the `hasValue()`'s type guard covers the
entire type range already (meaning that the type in the else-branch cannot be inhabited
in the type system, yielding the `never` type).
By making the `hasValue()` method only a type guard when the generic type includes `undefined`
these problems are avoided.
Fixes#60766Fixes#63545Fixes#63982
PR Close#63994
This adds an optional flag to the renderer on `removeChild` called `requireSynchronousElementRemoval`, which can tell any downstream renderer that elements need to be removed synchronously. This gets passed down to the legacy animation renderer to ensure that any elements that set this flag aren't impacted by that renderers changes to timing.
fixes: #63893
PR Close#63921
An invalid APP_ID could be responsible to generating broken CSS selectors. (eg `:` is an example for a character that breaks a selector by being a separator for pseudo-selectors.)
We now throw an error if the provided value is not alphanumerical
PR Close#63252
This option was deprecated by #55778.
BREAKING CHANGE: The `interpolation` option on Components has been removed. Only the default `{{ ... }}` is now supported.
PR Close#63474
The diagnostic will raise an error when required initializers (input, model, queries) are invoked the context of property initializers and contructors.
Docs will be provided in a follow-up
fixes#63602
PR Close#63614
This makes it possible to batch effects, where we can "reopen" consumers
during initial render and then finalize them after we are finally done
adding all the effects to a batch:
```
function createBatch() {
const effect = // ... create effect node
resetConsumerBeforeComputation(effect);
return effect;
}
// pseudo-code
function appendEffect(effectBatch, updater) {
if (value is a signal) {
const prevConsumer = setActiveConsumer(effectBatch.node);
const output = value();
setActiveConsumer(prevConsumer);
effectBatch.push({ signal, updater });
return output;
}
}
function finalizeBatch(effectBatch) {
if (effectBatch.length > 0) {
finalizeConsumerAfterComputation(effectBatch.node);
}
}
const effectBatch = createBatchEffectNode();
appendEffect(signal1, (newValue) => /* something */);
appendEffect(signal2, (newValue) => /* something different */);
finalizeBatch(effectBatch);
```
PR Close#62549
Dropping `any` in favor of `Node` for better type safety and clarity.
BREAKING CHANGE: `ngComponentOutletContent` is now of type `Node[][] | undefined` instead of `any[][] | undefined`.
fixes#63538
PR Close#63674
This commit introduces a number of changes to the server bootstrapping process to make it more robust and less error-prone, especially for concurrent requests.
Previously, the server rendering process relied on a module-level global platform injector. This could lead to issues in server-side rendering environments where multiple requests are processed concurrently, as they could inadvertently share or overwrite the global injector state.
The new approach introduces a `BootstrapContext` that is passed to the `bootstrapApplication` function. This context provides a platform reference that is scoped to the individual request, ensuring that each server-side render has an isolated platform injector. This prevents state leakage between concurrent requests and makes the overall process more reliable.
BREAKING CHANGE:
The server-side bootstrapping process has been changed to eliminate the reliance on a global platform injector.
Before:
```ts
const bootstrap = () => bootstrapApplication(AppComponent, config);
```
After:
```ts
const bootstrap = (context: BootstrapContext) =>
bootstrapApplication(AppComponent, config, context);
```
A schematic is provided to automatically update `main.server.ts` files to pass the `BootstrapContext` to the `bootstrapApplication` call.
In addition, `getPlatform()` and `destroyPlatform()` will now return `null` and be a no-op respectively when running in a server environment.
PR Close#63562
Moves the control directive under api/ since it is part of the public
API. Also removes the interop abstract control from the public API
PR Close#63616
Removes the deprecated `ApplicationConfig` export from `@angular/platform-browser`.
This export was deprecated in a prior version and developers should import `ApplicationConfig` from `@angular/core` instead.
BREAKING CHANGE:
The deprecated `ApplicationConfig` export from `@angular/platform-browser` has been removed.
Please import `ApplicationConfig` from `@angular/core` instead.
PR Close#63529
This option was introduced out of caution as a way for developers to opt out of
the new behavior in v18 which scheduled change detection even when
events happened outside the NgZone. After monitoring the results post-release, we
have determined that this feature is working as desired and do not believe it
should ever be disabled by setting this option to `true`.
This option was deprecated in v18.2, less than 3 months after it was
introduced in v18. We do not really expect it to be used.
BREAKING CHANGE: `ignoreChangesOutsideZone` is no longer available as an
option for configuring ZoneJS change detection behavior.
PR Close#62700
This allows passing errors and disabled reasons that did not originate
from `@angular/forms/signals` in case the the control is being used
separately from the forms system
PR Close#63455
Removes custom handling of emptiness in several of the validators and
replaces it with a common `isEmpty` check. The common empty check
considered the following values to be empty: `null`, `undefined`, `''`,
`false`, `NaN`
Generally most validators should treat an empty value as valid. This
aligns with both the behavior or native HTML validators and reactive
forms validators.
As an example, consider an optional email field. If the email validator
considered empty string to be an invalid email, there would be no way
for the user to not enter it.
There are several exceptions to this rule:
- `required` whose entire purpose is to ensure that the field is *not*
empty
- `validateStandardSchema` which should subject all values including
empty ones to the specified standard schema. It is up to the schema to
decide whether an empty value is valid or not
- `validate`/`validateAsync` which leaves it up to the user's custom
validation logic to decide if an empty value is valid.
PR Close#63456
This commit introduces an experimental version of a new signal-based forms API for Angular. This new API aims to explore how signals can be leveraged to create a more declarative, intuitive, and reactive way of handling forms.
The primary goals of this new signal-based approach are:
* **Signal-centric Design:** Place signals at the core of the forms experience, enabling a truly reactive programming model for form state and logic.
* **Declarative Logic:** Allow developers to define form behavior, such as validation and conditional fields, declaratively using TypeScript. This moves logic out of the template and into a typed, testable schema.
* **Developer-Owned Data Model:** The library does not maintain a copy of data in a form model, but instead read and write it via a developer-provided `WritableSignal`, eliminating the need for applications to synchronize their data with the form system.
* **Interoperability:** A key design goal is seamless interoperability with existing reactive forms, allowing for incremental adoption.
* **Bridging Template and Reactive Forms:** This exploration hopes to close the gap between template and reactive forms, offering a unified and more powerful approach that combines the best aspects of both.
This initial version of the experimental API includes the core building blocks, such as the `form()` function, `Field` and `FieldState` objects, and a `[control]` directive for binding to UI elements. It also introduces a schema-based system for defining validation, conditional logic, and other form behaviors.
Note: This is an early, experimental API. It is not yet complete and is subject to change based on feedback and further exploration.
Co-authored-by: Kirill Cherkashin <kirts@google.com>
Co-authored-by: Alex Rickabaugh <alxhub@users.noreply.github.com>
Co-authored-by: Leon Senft <leonsenft@users.noreply.github.com>
Co-authored-by: Dylan Hunn <dylhunn@gmail.com>
Co-authored-by: Michael Small <michael-small@users.noreply.github.com>
PR Close#63408
Add support for the Fetch API's responseType property in HttpResponse and HttpErrorResponse when using HttpClient with the withFetch provider.
PR Close#63043
Deprecated since v5. Use `upgrade/static` instead, which also supports aot.
BREAKING CHANGE: `UpgradeAdapter` is no longer available. Use
`upgrade/static` instead
PR Close#61659
The `FormArrayDirective` will allow to have a `FormArray` as a top-level form object.
* `NgControlStatusGroup` directive will be applied to the `FormArrayDirective`
* `NgForm` will still create a `FormGroup`
Fixes angular#30264
BREAKING CHANGE: This new directive will conflict with existing FormArray directives or formArray inputs on the same element.
PR Close#55880
Running the Angular compiler with declaration-only emission is dangerous
because Angular does not yet support this mode as it relies on the Ivy
compilation which does not run in this mode
In the best case, everything works fine as incidentally there's no
difference in the emitted type declarations (e.g. this is the case for
TS files containing no Angular annotations or only `@Injectable`
annotations).
In the worst case, compilation silently fails in that the compilation
succeeds but the resulting type declarations are missing the Angular
type information and are therefore incomplete. This happens for all
components, directives and modules.
BREAKING CHANGE: The Angular compiler now produces an error when the
the `emitDeclarationOnly` TS compiler option is enabled as this mode is
not supported.
PR Close#61609
SkyZeroZx