Is it possible to give names to wrappers and helpers functions?

[alexshelkov]

So if I have some basic async function which I want to export:

#[wasm_bindgen(js_name="test")]
pub async fn test(val: u32)  {
}

This expands to some glue code both on Rust and on JS side. So something like this ends up in JS:

imports.wbg.__wbg_new_b85e72ed1bfd57f9 = function(arg0, arg1) {
     // removed some code for clarity
     return __wbg_adapter_26(a, state0.b, arg0, arg1);     
};
 imports.wbg.__wbindgen_closure_wrapper32 = function(arg0, arg1, arg2) {
     const ret = makeMutClosure(arg0, arg1, 7, __wbg_adapter_14);
     return addHeapObject(ret);
};

So the two key functions is __wbg_adapter_14 and __wbg_adapter_26:

function __wbg_adapter_14(arg0, arg1, arg2) {
    wasm._dyn_core__ops__function__FnMut__A____Output___R_as_wasm_bindgen__closure__WasmClosure___describe__invoke__hd633b0858f9c6e90(arg0, arg1, addHeapObject(arg2));
}
function __wbg_adapter_26(arg0, arg1, arg2, arg3) {
    wasm.wasm_bindgen__convert__closures__invoke2_mut__hcb90f526d04a9687(arg0, arg1, addHeapObject(arg2), addHeapObject(arg3));
}

This functions calls some exported Rust functions.

So I want to know is it somehow possible to give static names to this helpers?
Or at least know that __wbindgen_closure_wrapper32 -> will call _dyn_core__ops__function__FnMut__A____Output___R_as_wasm_bindgen__closure__WasmClosure___describe__invoke__hd633b0858f9c6e90?
Now each time this helpers created they will have random names, so the JS glue file can't be dynamically created.

[daxpedda]

It is not possible.

Why is this necessary though?

Now each time this helpers created they will have random names, so the JS glue file can't be dynamically created.

What does "dynamically created" mean in this context?

[alexshelkov]

What does "dynamically created" mean in this context?

I mean that I have multiple modules that define the exports with the same interface:

#[wasm_bindgen(js_name="test")]
pub async fn test(val: u32)  {
}
#[wasm_bindgen(js_name="test_b")]
pub async fn test_b(val: u32)  {
}

So this test can be in module A or module B, and test_b can be in module A or B. And I can have multiple instances which created from the same JS glue files. I wrap the JS created by wasm_bindgen in something like:

create({imports}) {
  // here is the code generated by wasm_bindgen
  
   return {
       init: __wbg_init,
       test,
       test_b 
   }
}

So now I can create let moduleA = create({...}) or let moduleB = create({}). SO this is what I call "dynamically created".

[daxpedda]

I see, wasm-bindgen was built to use the shim with it's corresponding module, so this is definitely unsupported.
Whats the use case for all this?

[alexshelkov]

Whats the use case for all this?

So my goal is to create very lightweight portable interface (for example, I can even use it from the Rust side just by providing required imports). I do understand that wasm-bindgen may be a but wrong tool to use in this case, but it is so easy to use from the developer view. Like other options is something like webassembly components or maybe wapc, but they also have their tradeoffs. I can't find something similar to wasm-bindgen which would be as equally simple to use (if you have something in mind I would greatly appreciate any hints!)

I also check it a bit futher and it seems that all this methods like _dyn_core__ops__function__FnMut__A____Output___R_as_wasm_bindgen__closure__WasmClosure___describe__invoke__hd633b0858f9c6e90 are actully static, so they always the same even if I export multiple async functions. So there must be some place in code where this names is created?

[daxpedda]

I still don't know why you have to use it this way, but you are really not supposed to rely on the shim not changing, eventually things will break for you because wasm-bindgen was definitely not built to be used this way.
Unfortunately I don't have any recommendation for you other then to find a different strategy for what you are trying to do.

So there must be some place in code where this names is created?

You could try to use the module + type path instead of a hash, maybe that would make it more reproducible?
I'm honestly not sure, but I wouldn't recommend it.

---

Again, I don't know what you are trying to do exactly, but it really seems to me like wasm-bindgen is not the tool you are looking for. You can easily use Wasm in Rust without wasm-bindgen at all, this way you have full control over the exports/imports and don't need a shim.

Trying to un-marry the wasm-bindgen shim from the module would seems like a futile effort to me, the generated shim will change a lot under various circumstances and should not be relied on to stay the same.

[alexshelkov]

Thanks for help, I think your are right and eventually I will just use Rust without wasm-bindgen. Maybe I will write few my own macros.