fix: createElement & h types

[rschristian]

Closes #4577

Seems like a bit of a shame, essentially the type falls through to just match against a string and offer no real type checking, but it's seemingly what React does.

[coveralls]

coverage: 99.616%. remained the same
when pulling 09b8b15 on fix/h-types
into db47ab6 on main.

[rschristian]

Sorry, drive-by change.

I couldn't find a situation in which this actually made a difference, as createElement/h seemingly always falls back to a very loose overload that allows anything, but we extracted out IntrinsicSVGElements a bit more than a year ago and so we should be using it.

[JoviDeCroock]

Let's add a ts-test

[rschristian]

Unfortunately our ts-tests seem to be not working correctly. This is an error in the TS playground, but not in our test suite:

h('a', { href: 'https://example.com' });

I have no earthly idea why at the moment, hence why I held off on a test. I don't understand what differentiates a & href from option & value. Maybe I'm being daft, let me know if that makes any sense to you.

[JoviDeCroock]

The TS-playground test from the issue replicated for me in our tests, I based my comments off of those tests

[rschristian]

Yeah that one does for me too, but seemingly not other equivalent tests? Which is why I'm confused.

I can copy/paste that and move on, just don't understand what exactly is diverging & what we're testing. Something seems off.

[JoviDeCroock]

Hmm, that's odd, the type-checking used to work very well and I think with the examples I gave still does. Not sure what changed though, to your point

[rschristian]

OH nvm, it's falling into the HTMLAttributes & SVGAttributes overload. Somehow didn't notice that