Stream: jco

Topic: Is jco generating the correct js bindings for wit `option`?

James Mart (Aug 13 2024 at 22:54):

This question is in the context of a component that is transpiled for use in the browser.

Consider a variant definition in wit:

variant my-variant {
    typea(string),
    typeb(list<u8>),
}

I notice that when js bindings are generated for this, we get an object with a variant-like shape:

{
     tag: "typea"
     val: "some_value"
}

An option is, according to these component-model docs, semantically equivalent to the variant:

variant option {
    none,
    some(ty),
}

Therefore, I think I should expect that if a function returns an option<string> according to wit, that generated js bindings would unpack the object into a javascript object with a particular "optional" structure, such as:

{
     tag: "Some"
     val: "some_value"
}

or

{
     tag: "None"
}

I would prefer this!

But instead, in this option<string> example, we would simply either get a result of type string | undefined. This seems incorrect to me. Shouldn't undefined be reserved for uninitialized variables and the like, rather than the None case of a valid response?

Open to hearing some alternative opinions here.

Thanks,
James

Christof Petig (Aug 14 2024 at 06:04):

The mapping of the very common variants option and result to Java script uses a special representation as the more idiomatic way: option uses null for none, result an exception for error. Both provide the happy path value directly.

Last updated: Nov 22 2024 at 16:03 UTC