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.
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.
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!
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 export
s.
That said either should work -- feel free to make another thread if you run into any issues!
Victor Adossi has marked this topic as resolved.
Ben Sully has marked this topic as unresolved.
I did try the Rust way first but the import
ed bindings were different types to the export
ed ones so I would have had to write a _ton_ of boilerplate to do the type conversions :sweat_smile: Perhaps I missed something though!
Victor Adossi has marked this topic as unresolved.
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 resource
s), but glad it worked out OK!
Understood, perhaps I'll try the parent WIT thing one day :smile: thanks again!
Ben Sully has marked this topic as resolved.
Last updated: Nov 22 2024 at 17:03 UTC