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?
Also interested (related to https://github.com/bytecodealliance/jco/issues/402 I think)
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: ... }
.
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?
The generated types give information about the expected signatures
this can be found in the types folder for transpilations
we should have a document that fully captures all of these cases, @Dirk B盲umer did have something about this previously I believe
I'm actually transpiling in the browser and bundling the wasm with the shims for execution, rather than pre-transpiling
all JS imports are high-level JS types. Low-level bindings require component model ABI conventions.
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};
}
yes exactly
Awesome, thank you!
getObj() { return { var1: "alice", var2: BigInt(42) }
though
Default js integer is u32?
Er, i32?
JS numbers vary between floats and integers, but yes 64 bit requires bigint - can also be written with direct syntax 42n
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: Dec 23 2024 at 13:07 UTC