Suggestion: Generate a "class" rather than "module + functions" to allow overriding functionality about jco HOT 4 CLOSED

Closing as resolved, but if there is more that needs to be investigated here please do continue discussion.

from jco.

@GordonSmith can you clarify what sorts of extensions you are looking to make here? It would help to understand what kinds of interceptions might be useful, above and beyond the current --instantiation output mode.

from jco.

Disclaimer 1 - I haven't attempted to integrate any of the (new to me) component, wit, wasi-sdk toolchains into a "product", so my comments are just observations on the "hello world" type generated code. Also as I highlighted above, they are more about certain frustrations with the emscripten generated "module" JS, that I would not like to see repeated here!

Disclaimer 2 - I am not interested in any class v functional debates, IMO they are just different abstractions with their own pros and cons, if anything my mantra is always "good encapsulation" which in this context is the ability to replace well encapsulated "bits" of the generated code.

So with that in mind when I look at the generated code my initial observations are:

1. The "loader" code (the bit which fetches the wasm), is catering for two separate environments (NodeJS and Browsers) and is also making assumptions about the location of the wasm file. This has historically been a pain for me (as a JS library writer) as I won't be able to bundle that code cleanly - I like to create a single JS file which "just works" in NodeJS, Browsers (inline or as web workers) AND that my customers can bundle in their web applications without having to think about it. FWIW I solved this issue by compressing the wasm using zstd and encoding it as Base91 so it can be stored in a JS file as a string, with a helper function that does the decoding and decompressing - so I would need the ability to exclude your loader code and be able to pass in a "pre-loaded" wasm file (and have no reference to any NodeJS/Deno libraries which confuse my bundlers and my customers bundlers).
2. The helper functions are going to get duplicated when working with more than one wasm component
3. The use of TextEncode/TextDecoder might be problematic in some environments (does Deno support them? Does wasmr + embedded JS support them?), While I suspect the answer might be yes in those examples I already have my own encoder and decoder that I might prefer to use.
4. The shared memory is not accessible (in my toy example anyway), I will want to be able to allocate memory on demand and be able to read / write to it from the JS side (image blobs, or parquet blobs etc.)

The code being generated is super clean and I would hate to see it getting a lot of if (opt.nodejs === true) or if (opt.utf8encode !== undefined) type statements.

Classes could solve these issues, so could well typed functions in separate files...

from jco.

I believe the class will make more sense to be generated from a resource shape defined in WIT. Because right now the tooling does not support resources, they have been defined as separated functions without state and no particular flow. I hope that this will change in the near future.

from jco.