Stream: jco

Topic: ✔ 'wrapper' component?


view this post on Zulip Victor Adossi (Oct 16 2024 at 16:13):

Hey @Ben Sully ! What you're describing is definitely possible -- both (1) and (2).

Which you should do seems to depend on your use case (i.e. how the functionality should be split), etc, but you can take a module and jco transpile it very easily these days. There's a PR that will land soon with examples you can look at.

You can also reference the PR on the component-book documentation that explains more about the process.

This commit adds examples to the jco, some of which are/will be referenced from the component-model book (https://component-model.bytecodealliance.org/).
We read every piece of feedback, and take your input very seriously.

view this post on Zulip Victor Adossi (Oct 16 2024 at 16:16):

Generally, you should be able to just build the Rust code into a component, and run it through jco transpile and publish those libraries and be able to call them.

One of the great benefits of course being that you can model (and iterate on) the interfaces for individual components as you go.

Repository for design and specification of the Component Model - WebAssembly/component-model

view this post on Zulip Ben Sully (Oct 16 2024 at 16:30):

Hi @Victor Adossi , thanks for taking a look! I've been using jco transpile with some success already actually, and I think since asking this I've realised that just creating the smaller components is a better way to go than _also_ creating a separate 'big' component. I think if I wanted to do that I'd be better off doing it for each language.

My original idea, since I'm here, was to have multiple smaller components (say adder, subtracter, multiplier, etc), then one big component which literally just looked like:

world everything {
    import bsull:adder/add;
    export bsull:adder/add;

    import bsull:subtracter/subtract;
    export bsull:subtracter/subtract;

    ... etc
}

I wouldn't need to use cargo-component or any language specific tooling, just create an 'empty' component which imports or embeds the dependencies. Then I could use jco transpile to turn it into a single JS package. Bonus points if the jco-generated bindings provide separate entrypoints for each component (to mimc code-splitting & avoid loading unnecessary WASM blobs for users only using add)

I think I can achieve something similar right now though so we're all good!

view this post on Zulip Victor Adossi (Oct 16 2024 at 16:33):

Yeah that sounds reasonable to me, though I think that if you were building the components together it might be easier to build a rust-side component that re-exports everything and then your world would be all exports.

That said either should work -- feel free to make another thread if you run into any issues!

view this post on Zulip Notification Bot (Oct 16 2024 at 16:33):

Victor Adossi has marked this topic as resolved.

view this post on Zulip Notification Bot (Oct 16 2024 at 16:36):

Ben Sully has marked this topic as unresolved.

view this post on Zulip Ben Sully (Oct 16 2024 at 16:36):

I did try the Rust way first but the imported bindings were different types to the exported ones so I would have had to write a _ton_ of boilerplate to do the type conversions :sweat_smile: Perhaps I missed something though!

view this post on Zulip Notification Bot (Oct 16 2024 at 16:36):

Victor Adossi has marked this topic as unresolved.

view this post on Zulip Victor Adossi (Oct 16 2024 at 16:38):

Ah yes that does happen, if you define separate types i.e. not in some shared parent WIT then yes, you do have to end up converting those types, which can be pretty inconvenient. I thought you might run into more issues importing and exporting (which can be an issue when using resources), but glad it worked out OK!

view this post on Zulip Ben Sully (Oct 16 2024 at 16:38):

Understood, perhaps I'll try the parent WIT thing one day :smile: thanks again!

view this post on Zulip Notification Bot (Oct 16 2024 at 16:39):

Ben Sully has marked this topic as resolved.


Last updated: Nov 22 2024 at 17:03 UTC