Skip to content

NumberControl: commit (and constrain) value on blur event #39186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ciampo merged 14 commits into from
Mar 21, 2022
Merged

NumberControl: commit (and constrain) value on blur event #39186

Changes from 1 commit
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
e3bc714
`InputControl`: always commit value to internal state on `blur`
ciampo Mar 3, 2022
b2f2138
`NumberControl`: constain value also on the `UPDATE` action
ciampo Mar 3, 2022
bb15bd2
CHANGELOG
ciampo Mar 3, 2022
823cf7b
Add unit test
ciampo Mar 3, 2022
a1c6fc7
Remove `UPDATE` action from `InputControl` s state reducer
ciampo Mar 8, 2022
1e5123c
Add unit test to check that `onChange` gets called when the value is …
ciampo Mar 9, 2022
6f5696e
Fix input control blur logic, so that `onChange` is called after clam…
ciampo Mar 9, 2022
5db0df6
Comments
ciampo Mar 9, 2022
f6d2654
Use `event.target.validity.valid` in docs, storybook and unit tests
ciampo Mar 9, 2022
1154566
README
ciampo Mar 10, 2022
046ca57
Add docs and update example about input validity
ciampo Mar 15, 2022
5a6154f
Update `onChange` event type
ciampo Mar 15, 2022
43ff576
Override `event.target`, update types
ciampo Mar 15, 2022
dad09a5
Revert docs and Storybook changes about `target.visibility` potential…
ciampo Mar 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
README
  • Loading branch information
@ciampo
ciampo committed Mar 17, 2022
commit 115456668e2bbae347bdd679f2f0457c9e434d39
2 changes: 1 addition & 1 deletion packages/components/src/number-control/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@ The callback receives two arguments:
1. `newValue`: the new value of the input
2. `extra`: an object containing, under the `event` key, the original browser event.
Copy link
Contributor

@andrewserong andrewserong Mar 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I have a slight (though not at all strong) preference for having the second param be the plain event object rather than nesting it within an extra object. There's a familiarity with having the second param of callbacks be the event object itself, so it might make this component slightly easier for someone new to looking at it if we don't add in this abstraction.

But I'm aware you probably added it in mostly thinking of the isValid flag? I think given the documentation now covers event.target.validity.valid, we'd probably be fine not adding in any additional metadata.

What do you think?

Copy link
Contributor

@stokesman stokesman Mar 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chiming in to say the shape of that goes back well before this PR. I've suggested the same #33696 (comment). My feeling is the components are experimental so we have license to make the change as long as we fix up any internal stuff that might break. Good for a separate PR though.

Copy link
Contributor Author

@ciampo ciampo Mar 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @stokesman mentioned, the extra object existed before this PR and is defined in InputControl.

For example, UnitControl extends that extra object by adding a custom data property too (which seems to include extra info about which unit is being selected).

Given the above, I'm not sure what would be the best way to simplify the signature of the onChange callback — but it's definitely something that can be done in a follow-up

Copy link
Contributor

@andrewserong andrewserong Mar 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, excellent, thanks for linking the prior discussion, glad I'm not alone there! 😄

Yes, I think that's perfectly fine for a follow-up, not a blocker for me!


Note that the value received as the first argument of the callback is _not_ guaranteed to be a valid value (e.g. it could be outside of the range defined by the [`min`, `max`] props). In order to check the value's validity, check the `event.target.validity.valid` property from the callback's second argument.
Note that the value received as the first argument of the callback is _not_ guaranteed to be a valid value (e.g. it could be outside of the range defined by the [`min`, `max`] props, or it could not match the `step`). In order to check the value's validity, check the `event.target.validity.valid` property from the callback's second argument.

- Type: `(newValue, extra) => void`
- Required: No
Expand Down