fix(FormControl): onChange and innerRef ts decls (#3583,#3568,#2781)

[craigpg]

These changes seemed get the types sorted out for my project. I added some tests to simple.test.tsx to confirm and demonstrate my usage.

May want to consider adding a test-types script to package.json and including it in the main test script.

"test": "npm run lint && npm run dtslint && npm run test-browser && npm run test-node && npm run test-types"
"test-types": "tsc --noEmit -p types"

[taion]

we do test the types, i thought?

we should get rid of the last few innerRef instances

[craigpg]

@taion - the dtslint script covers type checking just fine so my comments re: script changes can be ignored. I assumed I was missing something so I didn't include script changes in the PR.

My original PR was going to just fix the onChange type, but I noticed that innerRef was also incorrect so I fixed that while I was in there. On closer look, it doesn't look like FormControl makes use of innerRef so it can be removed. It can probably be removed from the other Form... type declarations as well. I'll update the PR if you agree.

Not sure there's a way to get clean typings for ref since React will insist on creating a ref for the wrapping component and combine that type with the inner ref type. This just means that when creating the ref, you'll need do something like this:

React.createRef<FormControl<"select"> & HTMLSelectElement>()

[taion]

That seems weird. So is there no way to get React.createRef to have the correct types?

[taion]

well, for the time being this is just an improvement, anyway

[craigpg]

@taion - The ref types are coming from:

1. The generic class that FormControl extends to get the props of the wrapped input element. This will add a ref prop with type HTMLInputElement, which is really the only ref we want.
2. When TS transforms the JSX, it creates a FormControl element and the underlying TS declarations automatically add a ref prop with type FormControl by intersecting it with the rest of the props.
3. Since the ref prop already exists, albeit with a different type, the prop types are intersected.

There is a workaround

[taion]

thanks for digging that up.

i'm comfortable moving forward with this. we'll likely want to switch everything to forwardRef just for non-TS API concerns before we cut 1.0.0 final, but this is a strict improvement as things are now

[bpas247]

Definitely an improvement for the time being, great work 👍