Repository navigation
feat(forms): support updateOn in ngModelOptions - #18577
Conversation
|
You can preview 895ccc8 at https://pr18577-895ccc8.ngbuilds.io/. |
|
You can preview 71470e9 at https://pr18577-71470e9.ngbuilds.io/. |
63664a6 to
321b059
Compare
|
You can preview 63664a6 at https://pr18577-63664a6.ngbuilds.io/. |
|
You can preview 321b059 at https://pr18577-321b059.ngbuilds.io/. |
|
You can preview bc4aba0 at https://pr18577-bc4aba0.ngbuilds.io/. |
kara
added
the
action: review
|
You can preview 3b05d06 at https://pr18577-3b05d06.ngbuilds.io/. |
IgorMinar
left a comment
IgorMinar
left a comment
There was a problem hiding this comment.
lgtm for api changes. I didn't review the implementation
There was a problem hiding this comment.
This seems to be the same as in ng_form.ts. Can we reuse the code?
There was a problem hiding this comment.
That's a good point; I'll refactor it to shared.ts
This commit introduces a new option to template-driven forms that
improves performance by delaying form control updates until the
"blur" or "submit" event. To use it, set the `updateOn` property
in `ngModelOptions`.
```html
<input ngModel [ngModelOptions]="{updateOn: blur}">
```
Like in AngularJS, setting `updateOn` to `blur` or `submit` will
delay the update of the value as well as the validation status.
Updating value and validity together keeps the system easy to reason
about, as the two will always be in sync. It's also worth noting
that the value/validation pipeline does still run when the form is
initialized (in order to support initial values).
Upcoming PRs will address:
* Support for setting group-level `updateOn` in template-driven forms
* Option for skipping initial validation run or more global error
display configuration
* Better support of reactive validation strategies
See more context in angular#18408, angular#18514, and the [design doc](https://docs.google.com/document/d/1dlJjRXYeuHRygryK0XoFrZNqW86jH4wobftCFyYa1PA/edit#heading=h.r6gn0i8f19wz).
kara
added
target: major
|
You can preview fff5d70 at https://pr18577-fff5d70.ngbuilds.io/. |
This commit introduces a new Input property called
`ngFormOptions` to the `NgForm` directive. You can use it
to set default `updateOn` values for all the form's child
controls. This default will be used unless the child has
already explicitly set its own `updateOn` value in
`ngModelOptions`.
Potential values: `change` | `blur` | `submit`
```html
<form [ngFormOptions]="{updateOn: blur}">
<input name="one" ngModel> <!-- will update on blur-->
</form>
```
For more context, see [angular#18577](angular#18577).
This commit introduces a new Input property called
`ngFormOptions` to the `NgForm` directive. You can use it
to set default `updateOn` values for all the form's child
controls. This default will be used unless the child has
already explicitly set its own `updateOn` value in
`ngModelOptions`.
Potential values: `change` | `blur` | `submit`
```html
<form [ngFormOptions]="{updateOn: blur}">
<input name="one" ngModel> <!-- will update on blur-->
</form>
```
For more context, see [#18577](#18577).
|
This doesn't yet support debounce ngModelOption on inputs. I would like to know what is the logic behind not implementing the same with blur? Example usecase for debounce:
|
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This commit introduces a new option to template-driven forms that improves performance by delaying form control updates until the "blur" or "submit" event. To use it, set the
updateOnproperty inngModelOptions.Like in AngularJS, setting
updateOnto'blur'or'submit'will delay the update of the value as well as the validation status. Updating value and validity together keeps the system easy to reason about, as the two will always be in sync. It's also worth noting that the value/validation pipeline does still run when the form is initialized (in order to support initial values).Upcoming PRs will address:
updateOnat the group level in template-driven formsSee more context in #18408, #18514, and the design doc.