wasm-bindgen/examples/closures/index.js

// For more comments about what's going on here, check out the `hello_world`
// example
import('./closures')
  .catch(console.error);
Add examples/documentation for closures 2018-04-06 18:49:21 +03:00			// For more comments about what's going on here, check out the `hello_world`
			`// example`
Add a `#[wasm_bindgen(start)]` attribute This commit adds a new attribute to `#[wasm_bindgen]`: `start`. The `start` attribute can be used to indicate that a function should be executed when the module is loaded, configuring the `start` function of the wasm executable. While this doesn't necessarily literally configure the `start` section, it does its best! Only one crate in a crate graph may indicate `#[wasm_bindgen(start)]`, so it's not recommended to be used in libraries but only end-user applications. Currently this still must be used with the `crate-type = ["cdylib"]` annotation in `Cargo.toml`. The implementation here is somewhat tricky because of the circular dependency between our generated JS and the wasm file that we emit. This circular dependency makes running initialization routines (like the `start` shim) particularly fraught with complications because one may need to run before the other but bundlers may not necessarily respect it. Workarounds have been implemented for various emission strategies, for example calling the start function directly after exports are wired up with `--no-modules` and otherwise working around what appears to be a Webpack bug with initializers running in a different order than we'd like. In any case, this in theory doesn't show up to the end user! Closes #74 2018-11-28 20:25:51 +03:00			`import('./closures')`
Add `catch(console.error)` to all examples Some examples have been failing to load in some browsers, and this ensures that whenever the promise to load Rust code fails we log any errors happening instead of accidentally failing silently. This helped debug a bit in #897 2018-09-28 23:54:29 +03:00			`.catch(console.error);`