Remove an unnecessary TODO comment. The native `<select>` tracks its
`value` by keeping track of the selected `<option>`. Thus if the value
was set *before* the corresponding option is created, the `<select>`
will ignore it, but the framework doesn't know that and will cache the
bound value anyways. Therefore, checking if the value changed since it
was last bound when the mutation that creates the selected `<option>`
occurs would in fact prevent a needed update, leaving the `<select>` and
field values out of sync.
Furthermore, we know the control type is a native `<select>` element, so
we can update its value directly instead of going through
`updateNativeControl()` which would perform a redundant input type
check.
This adds a handler to the `NavigationInterceptOptions` when we are
intercepting a `NavigateEvent`. This means that the scroll and focus
restoration will be delayed until the handler promise resolves. It also
means that we can provide better indication of an ongoing navigation
event.
https://github.com/angular/angular/pull/64590 implemented change
detection for field bindings, but only for those bound to native or
custom form controls. This change extends that optimization to apply to
field bindings on interoperable controls built using Reactive Forms as well.
Currently the logic for detecting `Field` directives only works if it's imported from `@angular/forms/signals` which doesn't cover our own tests.
These changes make the check more robust.
Adds some logic that won't report the `value` or `checked` inputs as missing when the `Field` directive is present since it will bind to the inputs implicitly.
Switches to checking against `FormValueControl<any>` instead of `FormValueControl<unknown>` when checking whether custom controls conform to the interface.
Fixes#64946.
This addresses a potential memory leak in plugin-factory.ts.
The require call inside the create function reloads the entire language
service module for every new project, which is inefficient and could be a cause of the memory leak during branch
switching. This ensures the module is loaded only once and the same
instance is shared across all projects.
This change adds support for commas in :host() arguments (e.g.
`:host(:not(.foo, .bar))` as well as in nested parens when the argument
is applied without parens (e.g. `:host:not(:has(.foo, .bar))`).
Previously these selectors would receive an extra `[nghost]` attr, e.g.
`[nghost]:not(.foo, [nghost].bar)`.
I didn't file a bug for this one, but it's also blocking on an internal
LSC. Like the other CSS changes, I'll run a TGP to confirm this isn't
breaking.
By intersecting with `object` instead of `unknown` in the primitive and
`FormControl` cases, we get TypeScript to show nicer type errors that
mention `FieldTree<...>` insetad of `() => FieldState<...>`
* Define `ResourceSnapshot<T>` as a type union of possible states for a
`Resource<T>`.
* Add `Resource.snapshot()` to convert a `Resource` to a signal of its
snapshot.
* Add `resourceFromSnapshots` to convert a reactive snapshot back into a
`Resource`.
By converting resources from/to `Signal<ResourceSnapshot>`s, full
composition of resources is now possible on top of signal composition APIs
like `computed` and `linkedSignal`.
For example, a common feature request is to have a `Resource` which retains
its value when its reactive source (params) changes. This can now be built
as a utility, leveraging `linkedSignal`'s previous value capability:
```ts
function withPreviousValue<T>(input: Resource<T>): Resource<T> {
const derived = linkedSignal({
source: input.snapshot,
computation: (snap, previous) => {
if (snap.status === 'loading' && previous?.value) {
// When the input resource enters loading state, we keep the value
// from its previous state, if any.
return {status: 'loading', value: previous.value.value};
}
// Otherwise we simply forward the state of the input resource.
return snap;
},
});
return resourceFromSnapshots(derived);
}
// In application code:
userId = input.required<number>();
user = withPreviousValue(httpResource(() => `/user/{this.userId()}`));
// if `userId()` switches, `user.value()` will keep the old value until
// the new one is ready!
```
Currently we maintain the pathKeys internally, but do not expose them
through the `FieldContext`, this PR updates the `FieldContext` to expose
this property.
Previously we supported one level of nested parentheses inside of a
`:host()` selector, e.g. `:host(:not(p))`. This caused a breakage in g3
when I migrated a selector from `:host:not(:has(p))` to
`:host(:not(:has(p)))`. This change adds support for just one more level
of nesting.
It'd be nice to move everything to a real CSS parser (or even update it
to count parentheses like I did with :host-context()), but I wasn't able
to get that to work in ~20 minutes and I'm focusing on other things at
the moment.
This change punts the problem until somebody tries to use just one more
level of nesting in a selector.
Fixes#64830
This further builds out the Router integration with the platform
Navigation API. Key features in this state include:
* History restoration via direct platform APIs rather than markers left on
`history.state`. This means more guaranteed correctness and less
internal code to compute traversal restorations.
* Ability to observe navigations triggered outside the Router APIs.
Practically speaking, this means some navigations can be performed
through the platform rather than requiring `Router.navigate`. Note
that because the `NavigateEvent` is never intercepted at this point of
the implementation, regular anchor tags cannot be used because they
will still trigger a popstate navigation.
This implementation does _not_ intercept the `NavigateEvent` but future
iterations should. By omitting the interception, we are missing out on
features such as:
* Platform-supported scroll and focus reset
* Holding the navigate event open for the duration of the router
navigation, allowing for a visual loading indicator in the browser
* Support for intercepting navigations from regular anchor tags (e.g.
not `RouterLink`s) and converting those to SPA navigations.
PR Close#64905
When we set the `value` on a `<select>` element we're really just
setting the selected `<option>`. It treats the selected option as the
source of truth, rather than the actual value. This means that if
options are added or removed or their value changes, the `<select>` may
wind up with a different `value` than what's in our model.
This PR resolves this issue by adding a `MutationObserver` to the select
that is used to resync its value to the model whenever the options may
have changed.
