<NumericInput> does not expose onChange(e:ChangeEvent<HTMLInputElement>) the same way as <InputGroup>. Instead, onValueChange(n:number, s:string) is exposed, with no information about which input is changing. This means that, annoyingly, one change handler is needed for each numeric input. Should be trivial to expose the change event of the <input> within.
with no information about which input is changing
I'm a little confused by this; there's only one input in a NumericInput component.
Can you demonstrate your issue with a code sandbox? I don't see why you need the change event of the underlying <input>. Note that you can attach your own DOM event handler using the inputRef prop, but that's a little different from a React event handler like you suggested.
Thanks for the response. Here is a sandbox illustrating what I wish to achieve: https://codesandbox.io/s/react-typescript-xuly5
As you can see, one handleChange() method is used to deal with the onChange events of the various <InputGroup>s. However, if I wish to use a <NumericInput>, there is no onChange event so I have to define one event handler for each of them. Even if there may be a way to work around this as you say, it would be neat if I could use the same logic as the <InputGroup>s.
Let me know if I have misunderstood anything about the use of
@adidahiya Any update on this? My group is looking to generate InputGroups and NumericInputs extensively based on data and share the same onChange event handler, but this is currently not possible.
@strusoftsawen I pushed a PR which should accomplish what you want, please check it out: https://github.com/palantir/blueprint/pull/3982
@adidahiya awesome, looks exactly like what I need. Apparently it wasn't included in the 3.24.0 package release, but I'm looking forward to using it once it's released.
@adidahiya I think this issue should be reopened. To be frank it seems insane that two very similar components InputGroup and NumericInput (naming is also wierd) have very different API. I think proper onChange method is required here.
@rkulinski I don't think you'll get very far in open source conversations with that kind of language in your comment. Most of the API decisions in Blueprint come with tradeoffs and the names have been chosen for a reason. If you have a concrete criticism of or proposal for what you'd like to see in the NumericInput component, please file a new issue and use the issue template.