signal forms: support ngValue and compareWith for select

[jnizet]

Which @angular/* package(s) are relevant/related to the feature request?

forms (signal)

Description

Unless I missed something, there doesn't seem to be a way to support binding a non-string value to a <select> element in signals form.

Proposed solution

It would be hugely useful if signal forms supported the same functionality as reactive forms regarding selects, namely ngValue on <option> elements, allowing to bind the option to any kind of value (typically objects with some identifier), and compareWith on <select> elements, allowing to specify that these objects must be compared to the current value of the control using a provided equality function.

Alternatives considered

Leave it as is, and force developers to bind to the identifier of the object, and have some computed signal outside of the form model that finds the object with the selected identifier inside the list of options, but that is not ideal IMHO.

[jnizet]

It would also be nice if compareWith was made more user-friendly, kind of like trackBy was made more user-friendly when track was introduced in @for.

I don't have a specific syntax in mind, and it would perhaps be hard to make it type-safe, but being able just specify that we want to compare by country.code or user.id without having to expose a function in the component would be great.

[alxhub]

We did discuss doing this for Signal Forms, but ultimately decided not to support it on top of a "native" platform <select>.

When you use HTML platform controls like <input> and <select> in a signal-based form, our principle has been that we connect the form state (value, valid, disabled, etc) with the underlying HTML control in a natural way. Our goal is to make the behavior straightforward and intuitive, because it works the same as if you'd hand-written those bindings.

ngValue adds a lot of complexity on top of HTML <select>. In particular, now the value of the control becomes a complex interaction between the <select> and its <option>s, which might be in different templates, might be content-projected together, etc. There's a lot of behavior here that has to be specified - what happens if the [ngValue] binding changes, for example? Does the form value change? Is that <option> de-selected in the UI? How are values compared (the compareWith consideration)?

This didn't really fit our goal of the "default" behavior being an intuitive, natural connection between HTML behavior and the signal forms model. Instead, we think such experiences should be built as custom controls (maybe pairs of directives for <select> and <option>) which can navigate and resolve this complexity more explicitly.

[jnizet]

Thanks @alxhub. I understand and agree with these considerations.

My hope is precisely for Angular to provide this pair of directives (that would thus be opt-in, by importing them like any other directive) which would do things the same way the current ngValue and compareWith do it (i.e. with their current behavior and documented limitations, and with the same or a slightly better DX).

That would provide an easier migration path, and would avoid plenty of libraries or custom implementations doing that in their own subtly different (or broken) ways.

Note BTW that it's not doable currently in userland due to #63910 (which also prevents other use-cases, like a typeahead directive on an input for example)

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}