[Proposal] Add typing for JsonObjectWrapper

[oleksandr-yefremov]

I am thinking about adding generic support to JsonObjectWrapper. Now that we have JS codebase in TypeScript, all objects are typed with interfaces. And so we can compare (at least by manually looking at the code) whether object coming from native is what we expect on JS side.

// typescript
interface RestoreStateOptions {
  snapshotId: number,
  someOtherParam?: boolean
}
interface Snapshot {
  one: number,
  two?: boolean,
  three?: string,
} 
const state: Snapshot = restoreState(options: RestoreStateOptions) // calls to native

// kotlin
//====== BEFORE =======//
fun restoreState(snapshotId: JsonObjectWrapper): JsonObjectWrapper

//====== AFTER =======//
interface RestoreStateOptions {
  val snapshotId: Int,
  val someOtherParam: Boolean?
}

interface Snapshot {
  val one: Double,
  val two: Boolean?,
  val three: String?,
} 
fun restoreState(options: JsonObjectWrapper<RestoreStateOptions>): JsonObjectWrapper<Snapshot>

@bwalter, what do you think? Is the effort worth it? :)

[bwalter]

I was thinking about it in the past, the idea was to use kotlin-serialization and return a concrete (annotated) type instead of the wrapper. It would first use JSON because it is easy to implement but for performance reasons we could even use a custom serializer generating QuickJS byte code (would be a lot of effort, though).

Of course on the JS side it would still be dynamic but the typescript definitions would be the same as the Java one so it is easy to compare them. I don’t think we should think of generating the typescript types, though :)

Do you think that it would cover your use case? I will check next week-end if I can create a prototype for it and submit a first pull request.

[oleksandr-yefremov]

the idea was to use kotlin-serialization and return a concrete (annotated) type instead of the wrapper. It would first use JSON because it is easy to implement

Yes, I was thinking the same. And performance would be on the current level, since we use JSON anyway. Generating bytecode sounds interesting, but I'd first do some measurements, how long serialization takes now. Maybe it's not worth to optimise at all :)

typescript definitions would be the same as the Java one so it is easy to compare them.

That's exactly what I had in mind. Comparing visually (or with the help of script) kotlin interface to TS definition would make sure there is no discrepancy in terms of payload. And that would basically mean APIs are safeguarded on both function signature level and payload type.

Let's have a chat some day, perhaps I can help here, too.