feat(forms): support binding null to number input #66917
Conversation
angular-robot
bot
added
detected: feature
mmalerba
changed the title
mmalerba
force-pushed
the
sf/number
branch
4 times, most recently
from
66e5dea to
714ff23
Compare
| ): () => void { | ||
| let updateMode = false; | ||
| const input = parent.nativeFormElement; | ||
| // TODO: (perf) ok to always create this? |
There was a problem hiding this comment.
What's the alternative? Could we only create this if we know it's a numeric input?
There was a problem hiding this comment.
yeah we could look at the input type and only do it for types that have parsing. (e.g. type=text wouldn't need it), wanted to see if people thought that's worth it or not
There was a problem hiding this comment.
Is there a compelling reason not to?
I guess it means this call site needs to encode some of the same work done inside getNativeControlValue() to know whether it should handle parse errors.
There was a problem hiding this comment.
yeah, it felt like duplicating logic that checks the input type, that we already have elsewhere. then if we ever needed to add parsing to another type we'd have to remember to opt it in here in addition to adding the logic for it
Changes `parsedErrors` to a `linkedSignal` based on the model value. This ensures that the parse errors are reset if the model changes from outside the control.
Integrates native inputs with the new parseErrors API so that they can report parse errors when the user types an un-parsable value (e.g. "42e" in a number field). When a user types an un-parsable value, the model does not update. It retains its previous value and a parse error is added for the control that received the un-parsable value.
Supports binding `null` to a `<input type=number>`. - Binding in `null` clears the input - Binding in `NaN` also clears the input - When the user clears the input, the model is set to `null` - The model is _never_ set to `NaN` based on user interaction. It is either set to `null` if the user cleared the input, or is unchanged and a parse error added if the user entered an invalid number like "42e"
native controls and custom controls (via transformedValue) use similar parsing logic but it needs to be hooked up differently. This commit extracts the common bits into a shared piece.
leonsenft
left a comment
leonsenft
left a comment
There was a problem hiding this comment.
reviewed-for: public-api
3 participants
Supports binding
nullto a<input type=number>.nullthe same as a model value ofNaNnullrather thanNaNan error via the parse errors mechanism