You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to write a library that can optionally work-alongside wasm-bindgen or stand-alone without wasm-bindgen based on a feature flag.
My library has some Javascript that requires access to the Wasm instance's exports (to communicate independent of wasm-bindgen), but right now it's quite tricky to expose the instance's exports to my library.
The approach I've found is to stash the value retuned by wasm-bindgen's init on a global variable to access later:
A problem with this approach is that main is called by init so if my library is called by main then it won't yet have access the Wasm exports. A hack is to add a fake entry point to my library and then later call the entry point manually but that's a pretty invasive approach.
Ideally a library user should not have to change any of their Javascript code, they just need to flip a feature flag in my library.
Proposed Solution
If wasm-bindgen exposes a Rust function to access the instance's exports (or the instance itself) instead then that could be used instead to pass the information
This feels similar in purpose to functions like wasm-bindgen's memory function.
Such a function would be a useful escape-hatch for scenarios that are a little bit outside the norm, like my own.
The text was updated successfully, but these errors were encountered:
Motivation
I'm trying to write a library that can optionally work-alongside
wasm-bindgen
or stand-alone withoutwasm-bindgen
based on a feature flag.My library has some Javascript that requires access to the Wasm instance's exports (to communicate independent of
wasm-bindgen
), but right now it's quite tricky to expose the instance's exports to my library.The approach I've found is to stash the value retuned by
wasm-bindgen
'sinit
on a global variable to access later:A problem with this approach is that
main
is called byinit
so if my library is called bymain
then it won't yet have access the Wasm exports. A hack is to add a fake entry point to my library and then later call the entry point manually but that's a pretty invasive approach.Ideally a library user should not have to change any of their Javascript code, they just need to flip a feature flag in my library.
Proposed Solution
If
wasm-bindgen
exposes a Rust function to access the instance's exports (or the instance itself) instead then that could be used instead to pass the informationThis feels similar in purpose to functions like
wasm-bindgen
's memory function.Such a function would be a useful escape-hatch for scenarios that are a little bit outside the norm, like my own.
The text was updated successfully, but these errors were encountered: