Js.t deprecation vs pure type parameters?

1

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?

Thanks
A

2

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.

3

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.

4

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.

3 Likes
5

Yep pretty much.

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

6

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

Thanks

7

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

8

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

9

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.