Decoupling TypeScript from ReScript

[umuro]

Data Structure Design idea. Decoupling TypeScript and ReScript
We experienced that opaque data types are throwing off TypeScript and JavaScript. However, some data needs to be opaque. Otherwise coupling between the packages are too tight and even bug fixing is a torture because of coupling. I am still looking for a pattern that relieves both sides on the ReScript border for the future. One idea is creating fake tags and then keeping the data private. For example,

MyModule = {
   Private = { 
     @genType.opaque type t = ... //hidden real module data
       ... }
   @genType
   type t = {iAmMyModule: bool; private: Private.t}
   let makeMyModule = {iAmMyModule: true; private: Private.makeMyModule}
}

• The data is private. The module is decoupled from TypeScript.
• There is a fake tag to satisfy strong typing in TypeScript.
• TypeScript can totally ignore opaque data because of the fake tag. Easy conversion with the tag.
• Unfortunately there is no Private data in Rescript. We fake it using inner Private module.
• Because the module data is Private, there has to be an explicit module interface which is not in Private. That fixes the need for a TypeScript interface.

An alternative would be to specify a _type field instead of iAmMyModule. However that is error prone. Required to be set correctly for each module. iAmMyModule is unique to the module and type checking ensures that it is there.

There are many cases that correspond to inheritance and on TypeScript side severe type casting is required... So far there is no better way to have a record field to be utilized for typing in TypeScript.

So I am looking for an idea to ease life on the Rescript border... Any comments?

[OAGr]

I imagine we might not know what works well until we try things out. One strategy, if we think this is promising, is to try things out with a small test case, ideally end-to-end, and see how that works. It seems very possible that there could be some snags that are impossible to see in advance.

This work is fairly messy, so I suggest @berekuk and yourself decide on some strategy you two like here. I'd be happy to go along with basically anything you two like for this.

[berekuk]

I think we can do better than this. I'm not sure how exactly, yet, but I'll write down what I understand so far.

Note: one of the reasons I don't like fake tags is then they create a run-time overhead on ReScript side. I'd strongly prefer the solution that doesn't do that.

Key observation: we need tagging only for variants; for everything else the current ForTS pattern works pretty well and is entirely type-safe.

First idea (probably bad):

• variants are usually objects (except for pathological IEvVoid case).
• So all that we need is a type-safe mapping from a variant object ({TAG: 123, ... }) to named tags. Maybe we could just parse Rescript code and it won't be that difficult? Like, during the build step, we could generate that information, and then it would be possible to generate all the Typescript layer?

---

Alternatively: @umuro, you're going to have a negative reaction about this initially, but hear me out :) maybe we could make specifically variants non-opaque? Right now we expose everything about their top-level structure anyway, in ForTS layer.

So maybe we could make variants non-opaque, but keep their contents opaque. For example, internalExpressionValue could be non-opaque with @genType, while lambdaValue could be opaque.

Then in TypeScript layer it'd be easy for me to either:

1. rely on string tags to figure out the specific TypeScript subclass that I need to use to wrap the given value
2. or maybe I could just set the prototype of the value I obtained from genType-generated function to the specific TypeScript subclass and be done with it

---

Now, a few cases. First:

@genType.opaque
type t2 = ...

@genType.opaque
type t3 = ...

@genType
type t = Foo(t2) | Bar(t3)

In this case we won't leak anything new to the TS side.

genType would generate something like this:

export abstract class t2 { protected opaque!: any };
export abstract class t3 { protected opaque!: any };

export type t = 
    { tag: "Foo"; value: t2 }
  | { tag: "SampleSet"; value: t3 };

---

Second:

@genType
type t = Foo(string) | Bar(array<number>)

This is a bit more problematic. Now the TS land will know that internally Foo-tagged values wrap strings and Bar-tagged values wrap arrays of numbers.

But this can be solved by type aliases! Then we'll be back to the initial example, and nothing is exposed again:

@genType.opaque
type t2 = string

@genType.opaque
type t3 = array<number>

@genType
type t = Foo(t2) | Bar(t3)

A bit more work on the Rescript side, but it's not that bad, I think...

[umuro]

"So maybe we could make variants non-opaque, but keep their contents opaque."
I agree with this...
Your second suggestion also exposes a point. If a Rescript module is exposing Js types directly then there are 2 cases

• Yes, it was intended so
• Private internal data exposed by haste, it should have a type name anyway.

[berekuk]

Great, seems like we agree. (Also discussed in PMs.)

I'll try to do an experimental PR with some one variant (something less complex than SquiggleValue, at first), to test whether there would be issues with this approach in practice.