Use new WebAPI

[nojaf]

This is a sample PR to illustrate the usage of the new WebAPI.
Some types in ReactDOM and ReactEvent were changed to match the new bindings.
As only the new types are used (which will be quite stable), this might not be as radical a change.

(PS: not saying we should merge this PR anytime soon)

[Freddy03h]

Hi @nojaf !
I'm really interested to test theses changes on my projects. Is it possible to upgrade rescript and @rescript/webapi please? thanks :)

[nojaf]

Feel free to push to this branch.
Tis probably best to make a new PR for this really.

[Freddy03h]

Hi, I'm testing the PR.

Is this the way to onChange on input or I'm missing something?

letonChange= (event: ReactEvent.Form.t) => {
letinput: WebAPI.DOMAPI.htmlInputElement=event->ReactEvent.Form.target->WebAPI.Prelude.unsafeConversationhandleChange(input.value)
}

[nojaf]

Hey Freddy,

Yeah, that is still a bit of a tricky one. The target can be multiple things (for example select) so we can't quite pick a useful type here.

WebAPI.Prelude.unsafeConversation is also really an alias for Obj.magic, which is something we might also want to revisit at some point.

One other thing that comes to mind here is to do an inline %raw instanceof check.

But yeah, no ideal solution.

[Freddy03h]

The previous {..} wasn’t safe either, but to me it’s better now.

I don’t see a better solution than providing a custom Event for each HTML element, so that currentTarget can be a DOMAPI.htmlInputElement / DOMAPI.htmlSelectElement / etc. instead of a generic DOMAPI.node.
This won’t fix target, but bubbling is a less common scenario anyway.

Typing the DOM API is hard. Something like react-strict-dom would probably be easier - but that’s off topic.

I think the current WebAPI approach is fine as it is; it’s permissive.
And it’s always possible to build a custom rescript-react library that enforces stricter types (or one that types react-strict-dom).

[nojaf]

Maybe a helper to get the .value as string (option?) would go a long way.
That is what 95% of the users will need.

[Freddy03h]

For forms & inputs, yes, but that doesn’t solve other types of events.
The goal of having detailed records is kind of lost if we need to create a bunch of helpers for common use cases.

On HTML*Element we already have asNode for type converting, so why not also have a fromNode on each element? (because adding all asHTML*Element on the Node module would be huge)

[nojaf]

Because fromNode would require a runtime check to be safe.
Something like instanceof HTMLInputElement, that would no longer make it a zero-runtime binding, which is another of discussion.
Maybe we want to go in that direction, maybe not.