Stream: jco

Topic: Javascript import shims for complex types

James Mart (Mar 15 2024 at 03:24):

Let's say I have a component that imports a function whose return type doesn't have first class support in javascript (result<_,string>, for instance). I intend to use jco transpile on this component, and provide a javascript shim for the import for browser execution.

What are the correct types to return in my javascript shim? Do I have to manually pack a buffer according to the canonical ABI?

Nuke 🌄 (Mar 15 2024 at 16:13):

Also interested (related to https://github.com/bytecodealliance/jco/issues/402 I think)

Guy Bedford (Mar 15 2024 at 16:29):

Jco treats a top-level result as a JS error, so that would be an imported function that possibly throws a string, you could write function importFn () { throw 'mystring' } or have it not throw to provide the correct types. If the result is a nested result then it would be an object of the form { tag: 'ok' | 'err', val: ... }.

James Mart (Mar 15 2024 at 16:32):

Thanks @Guy Bedford , where can I look to see such mappings? And furthermore is there anything to say about returning custom record types? Will packing javascript objects with the same logical structure "just work"? Or do I have to consider serialization?

Guy Bedford (Mar 15 2024 at 16:32):

The generated types give information about the expected signatures

Guy Bedford (Mar 15 2024 at 16:33):

this can be found in the types folder for transpilations

Guy Bedford (Mar 15 2024 at 16:33):

we should have a document that fully captures all of these cases, @Dirk Bäumer did have something about this previously I believe

James Mart (Mar 15 2024 at 16:33):

I'm actually transpiling in the browser and bundling the wasm with the shims for execution, rather than pre-transpiling

Guy Bedford (Mar 15 2024 at 16:33):

all JS imports are high-level JS types. Low-level bindings require component model ABI conventions.

James Mart (Mar 15 2024 at 16:37):

all JS imports are high-level JS types.

If I understand correctly, you're saying that if I fill an import with a js shim, I can use high-level js types out of the box. So:

record my-type {
    var1: string,
    var2: u64,
}
...
get-obj: func() -> my-type;

Could use a shim like:

getObj() {
   return {"alice", 42};
}

Guy Bedford (Mar 15 2024 at 16:37):

yes exactly

James Mart (Mar 15 2024 at 16:37):

Awesome, thank you!

Guy Bedford (Mar 15 2024 at 16:38):

getObj() { return { var1: "alice", var2: BigInt(42) } though

James Mart (Mar 15 2024 at 16:38):

Default js integer is u32?

James Mart (Mar 15 2024 at 16:38):

Er, i32?

Guy Bedford (Mar 15 2024 at 16:39):

JS numbers vary between floats and integers, but yes 64 bit requires bigint - can also be written with direct syntax 42n

James Mart (Mar 15 2024 at 16:40):

This is why a mapping document would be great because I'm not very experienced with js / dynamically typed langs, not obvious to me what the js primitives will unpack as. I'll look into understanding that more. Thanks again

Last updated: Oct 23 2024 at 20:03 UTC