Js.t deprecation vs pure type parameters?

I have a little confusion around this Im hoping you guys can help out with.
I was getting comfortable with Js.t to assert that I had a javascript object as a value.
With Js.t gone, and the inner type parameter in its place, Is there a way to signal that still?
I am wondering what happens when a function is resolved with an int where the Js.t once was?


It actually works just as you’d expect. Removing the Js.t part keeps working.

I’m guessing the reason you’re asking this is because instead of writing Js.t<{..}> (and realizing that removing Js.t works), you wrote Js.t<'a>? These 2 were basically the same before, but only because Js.t<bla> accepted only an object type.

An example im thinking of is a common foreign interface like network requests.
There is ultimately noone else that can assert the shape of the parameters to a post request.
The args now become (id, 'payload)=>result<....> And theres nothing preventing an int passed as payload/ nothing suggesting what it should be.

You can use {..} as 'payload}. {..} as 'a means "'a is any type that’s an object."

type t<'a> = {foo: {..} as 'a}

let x: t<_> = {foo: {"bar": 1}}
// Compile error:
// let x: t<_> = {foo: 1}

Playground link.


Yep pretty much.

Btw do post your examples if they don’t work. Much easier to show you the code.

Aha that will work. Feels a little clever to have special syntax to me but itll get me through =)


There’s no special syntax, at least no extra ones. This is the same syntax as before, but without the Js.t part

Im comparing {…} to Js.t<'a>

You might have missed/misinterpreted my first message. You were always supposed to write Js.t<{..} as 'a>. Nothing about Js.t constrained it to be an object beside the fact that that’s the only thing it could have carried.