Fixes #72

@koute @CryZe This is untested and is definitely not ready to merge.

But I wanted to at least get started on adding in Promise support to stdweb. This pull request adds in the ability to convert any JS Promise into a Rustified Futurified version of that Promise. This conversion happens automatically with the TryFrom<Value> trait.

Please look this over and let me know if you see anything weird, or anything that can be improved.

As explained in the documentation, if the Promise never succeeds / fails then the callback will never be called, and it will leak memory. This pull request fixes that.

Now the done method returns a DoneHandle. When the DoneHandle is dropped it will drop the callback, thus freeing the memory (at least on the Rust side).

Hi.

I want to pass a result of JS Promise into Rust code like the below.

let result = js! { await asyncFunc(@{some_value}) };

I tried such a code but got an error "SyntaxError: Unexpected identifier 'asyncFunc'" when loading generated js file.

I should use rather Promise but I have no idea how I can take the result out from js! macro.

Rationale

With the landing of Web Components in Firefox 63, all major browsers will have web components support on by default in a couple of weeks(when Firefox 63 becomes stable). Web Components can provide better performance especially on mobile platforms comparing to other JavaScript-based solutions. I think now it is a good time to implement Web Components support.

Outcome

Web Components consists of Template Element, Shadow DOM, Custom Element and HTML Imports. This pull request aims at implementing all of them except HTML Imports. There are concerns about the disconnection between ES6 Modules and HTML Imports and thus Safari and Firefox refuse to implement it. Frameworks like Polymer used to use HTML Imports has moved away from it. Chrome also deprecated HTML Imports. It may need major revamp before it gains any adoption from browser vendors. Hence, I've decided to not include HTML imports in this pull request.

Steps

• [x] Template Element
  • [x] TemplateElement
  • [x] Document.import_node
  • [x] Tests
• [x] Shadow DOM
  • [x] Slot
    • [x] SlotElement
    • [x] ISlotable
    • [x] SlotChangeEvent
  • [x] ShadowRootMode
  • [x] ShadowRoot
  • [x] IElement.attach_shadow
  • [x] IElement.shadow_root
  • [x] Tests
• [ ] Custom Elements(Withdrawn due to unexpected circumstances)

(I didn't write tests because I don't have Chrome on my computer. I'll make them up eventually.)

Unsolved Question

How should custom elements be constructed? Approach 1:

#[derive(Clone, Debug, PartialEq, Eq, ReferenceType)]
#[reference(instance_of = "MyElement")]
#[reference(subclass_of(EventTarget, Node, Element, HtmlElement))]
#[custom_element(name = "my-element", extends = "HTMLElement")]
struct MyElement(Reference);

impl ICustomElement for MyElement { // HtmlElement and IHtmlElement are already occupied.
    fn inited(&self) {
        // JavaScript Constructor Called
    }
    fn connected(&self) {
        // HTMLElement.connectedCallback
    }
    fn attr_changed(&self, attr_name: String, before: String, after: String) {
        // HTMLElement.attributeChangedCallback
    }
    fn adopted(&self) {
        // HTMLElement.adoptedCallback
    }
    fn disconnected(&self) {
        // HTMLElement.disconnectedCallback
    }

    fn observed_attrs(&self) -> Vec<String> {
        // vec!["name".to_owned(), "class".to_owned()]
    }
}

fn define_custom_elements() {
    // ...
    window().custom_elements().define(MyElement);
    // ...
}

Pros:

• It allows custom elements to subclass other elements(e.g.: HTMLTextareaElement).
• It looks like the original api.

Cons:

• I don't know how to implement this.
  • Is there any other way to construct a JavaScript class than js! macro?
  • How to downcast JavaScript types to rust structs at runtime?
  • Will [reference(instance_of = "MyElement")] work if the class is not defined at the time wasm file is initiated?

Approach 2:

fn define_custom_elements() {
    // ...
    CustomElementBuilder::new("my-element")
        .on_inited(|element| {})
        .on_connected(|| {})
        .on_attr_changed(|attr_name, before, after| {})
        .on_adopted(|| {})
        .on_disconnected(|| panic!())
        .watch_attrs(["name", "class"])
        .define().unwrap();
    // ...
}

Pros:

• It is easy to implement. Just js! all javascript code inside define().

Cons:

• It's not possible to subclass other elements like HTMLTextareaElement.

See also: #32

Fixes #92

This implements a fallback mechanism using a normal Map if attempting to store an object in the WeakMap throws an exception - objects stored here are explicitly removed when their reference count reaches zero, meaning that there are no leaks, but that the "stable ID" guarantee does not hold for these specific objects.

This likely comes with a performance penalty due to the use of exception handling.

Personally I would prefer the "stable ID" guarantee to be dropped entirely from webcore, and instead a WeakMap type was exposed so that stable IDs could still be achieved by opting in for specific objects.

I plan on adding all of the methods and properties of CanvasRenderingContext2D. Currently a work in progress but I've opened this PR to get some feedback on the implementation of certain functions.

Starting with clip and create_pattern_image where I had to create Enums.

As well as in createPattern which takes a CanvasImageSource but I've currently only implemented the ImageElement as create_pattern_image.

fix #199

Outstanding question:

• Should the "root element" be ~~div~~ span?
• Should it be configurable in some way (id, let the user specify the tag, let the user insert a node?)
• should this be implemented as Node::set_inner_html instead (or can we have both)?

I added the https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame to window. I ended up copying the funcall_adapter function over temporarily to verify that it actually works, but I'm assuming there should be some sort of shared module that it can go in that would be better?

It was actually a lot easier than I thought to convert from Futures 0.2 to 0.3 (it required very little code changes).

Breaking changes:

• Now uses Futures 0.3 rather than 0.2 (which has various breaking changes of its own).
• PromiseFuture::spawn_local has been changed to spawn_local
• PromiseFuture::print_error_panic has been changed to print_error_panic
• The experimental_features_which_may_break_on_minor_version_bumps and futures-support features now require Nightly Rust.

New additions:

• It's now possible to use async + await! + join! + try_join! syntax :tada: (I added a promise example which demonstrates this).
• New unwrap_future function (which internally uses print_error_panic)

The breaking changes and new additions only affect people who are using the experimental_features_which_may_break_on_minor_version_bumps feature, so this does not require a major version bump.

This topic has come up from time to time, but I'd be curious if it'd be good to make this official? Would stdweb be up for officially moving in the direction (eventually) of building on top of wasm-bindgen?

If so, I'd be more than willing to help fill out more information and work with y'all to make sure we can handle everything. We mentioned during the last rustwasm working group meeting that I'd meet with @Pauan and have some discussion on Discord, but I wasn't able to reach them just afterwards :(. In any case, if this sounds like a good idea, it's probably best to close this an open a more official tracking issue next.

@koute @CryZe This is not ready to merge yet. It still needs an implementation of setInterval, and also documentation.

I want to get feedback on two things:

1. The code for WaitFuture. In particular, is it okay to call .drop() on a Once callback multiple times?

2. I want to implement setInterval, however there are actually many different ways to implement it.

   Let's say you use interval(1000) to create a Stream, it might behave in any of these ways:

   • Every 1 second it sends a () message, regardless of whether the consumer is ready or not. These messages will be buffered, and when the consumer is ready it might pull multiple () messages at once.

   • Same behavior as above, except it only buffers a single message, so when the consumer is ready it will never pull more than 1 message at once.

   • After the consumer pulls a message, it will wait 1 second before it sends another message. In other words, it's guaranteed that the consumer will not receive a message more than once every 1 second (no matter how fast or slowly it pulls).

   It seems to me that all three of these behaviors are useful (in different situations), so we should probably have three separate functions. What should these functions be called?

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps css-what from 2.1.0 to 2.1.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I used the console! macro in the inner rust project. When I build it with wasm-pack , it is successful. But it encountered a panic on the front-end page and output the following message: Error importing index.js: RuntimeError: unreachable ...

can anyone help? 😭

Hi, I was trying to update my old web sequencer project a little and discovered a problem ... the js!() macro that'd trigger some events suddenly stopped working and I got an unreachable error in the console.

Investigating the error, I compiled the wasm-minimal-example found in this repo, and the error is pretty much the same:

185b031e:0x2904 Uncaught (in promise) RuntimeError: unreachable
    at 185b031e:0x2904
    at 185b031e:0x2c0c
    at 185b031e:0x2f2f
    at 185b031e:0x2fae
    at 185b031e:0x2e47
    at 185b031e:0x3083
    at finalizeInit (wasm_bindgen_minimal.js:56:10)
    at init (wasm_bindgen_minimal.js:85:12)
    at async run ((index):33:9)

Given the non-descriptive nature of the error message, I'm out of my wits here ... any hint ?

Best, N

I was experimenting with using GilRs on WASM with Trunk using the following code:

use std::{cell::RefCell, rc::Rc};
use gilrs::Event;
use log::info;
use wasm_bindgen::{prelude::*, JsCast};

fn window() -> web_sys::Window {
    web_sys::window().expect("Platform does not have a global window.")
}

fn request_animation_frame(f: &Closure<dyn FnMut()>) {
    window()
        .request_animation_frame(f.as_ref().unchecked_ref())
        .expect("`requestAnimationFrame` should succeed");
}

fn game_loop(mut callback: impl FnMut() + 'static) {
    std::panic::set_hook(Box::new(console_error_panic_hook::hook));
    console_log::init_with_level(log::Level::Info).expect("Couldn't setup console logging");

    let f = Rc::new(RefCell::new(None));
    let g = f.clone();

    *g.borrow_mut() = Some(Closure::wrap(Box::new(move || {
        callback();
        request_animation_frame(f.borrow().as_ref().unwrap());
    }) as Box<dyn FnMut()>));

    info!("Starting game loop");
    request_animation_frame(g.borrow().as_ref().unwrap());
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut context = gilrs::Gilrs::new()?;

    game_loop(move || {
        info!("game_loop");
        while let Some(Event { id, event, time}) = context.next_event() {
            info!("Gamepad event");
            // info!("{:?}", id);
        }
    });

    Ok(())
}

The code runs fine as long as the connected gamepad doesn't have any inputs. As soon as the gamepad gets an input, the code panics with the following:

Panic location: /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/stdweb-0.4.20/src/webcore/serialization.rs:447 inline279.js:1:108
    __cargo_web_snippet_72fc447820458c720c68d0d8e078ede631edd723 http://localhost:8080/snippets/stdweb-bb142200b065bd55/inline279.js:1
    __wbg_cargowebsnippet72fc447820458c720c68d0d8e078ede631edd723_ece3da0a4474dbeb http://localhost:8080/index-44e15f7f4b7059be.js:429
    hfc584dac876d521b http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:567993
    h11bcb30f712fdf5b http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:675817
    hd829486609ce1dfc http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:690973
    h98ec191c18086a09 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:302453
    h606d7c7f7a423b98 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:454051
    h9b985a293aac4ce1 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:561075
    ha03abef02a8b70fd http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:746856
    rust_begin_unwind http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:715965
    h6314b5c91abe7349 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:730725
    hec1fc057bd0baf0b http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:694808
    <stdweb::webcore::serialization::SerializedValue as core::convert::From<stdweb::webcore::serialization::SerializedUntaggedReference>>::from::hadfbae9d235f25d7 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:357571
    <T as core::convert::Into<U>>::into::h5a573d61e2a7eb6e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:568628
    <stdweb::webcore::value::Reference as stdweb::webcore::serialization::JsSerialize>::_into_js::hc4c09f414aa3eb25 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:679509
    <&T as stdweb::webcore::serialization::JsSerialize>::_into_js::h85c64cc956c40e8d http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:707989
    <stdweb::webcore::newtype::Newtype<(stdweb::webcore::serialization::NonFunctionTag,()),T> as stdweb::webcore::serialization::JsSerializeOwned>::into_js_owned::h5d20b7dcb6d87257 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:657841
    heaa01a07f9cd69d9 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:304545
    h67e64ad48dc99139 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:54876
    h91b9f80778aea007 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:618855
    core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once::hd4a412cd0b519899 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:555100
    ha00841e5932f2bc4 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:344169
    <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::next::h352aa1033bc5ab60 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:576477
    <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter::h7a1b3705b436b9b7 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:218444
    <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter::h57e586fadfc94a89 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:516655
    <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter::h547de20f16ac3be1 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:468799
    h099f28b8da9dd9e8 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:516997
    hc5395bde68faa4b7 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:49546
    h600223be596d5476 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:717220
    h72b1789ec4d25374 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:42919
    h0f2fad8861d4473a http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:187492
    h9806841f81972af8 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:177300
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477376
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353
    hdcbe2455b4a75a5c http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:388341
    h152f11a925cb67a2 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:467811
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477517
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353
    hdcbe2455b4a75a5c http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:388341
    h152f11a925cb67a2 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:467811
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477517
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353
    hdcbe2455b4a75a5c http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:388341
    h152f11a925cb67a2 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:467811
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477517
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353
    hdcbe2455b4a75a5c http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:388341
    h152f11a925cb67a2 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:467811
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477517
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353
    hdcbe2455b4a75a5c http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:388341
    h152f11a925cb67a2 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:467811
    h8d4b07a2975bb5a0 http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:477517
    <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hd01aec6e6501a09e http://localhost:8080/index-44e15f7f4b7059be_bg.wasm:513139
    __wbg_adapter_20 http://localhost:8080/index-44e15f7f4b7059be.js:222
    real http://localhost:8080/index-44e15f7f4b7059be.js:207
    (Async: FrameRequestCallback)
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:354
    handleError http://localhost:8080/index-44e15f7f4b7059be.js:257
    __wbg_requestAnimationFrame_8e3c7028c69ebaef http://localhost:8080/index-44e15f7f4b7059be.js:353

The error seems to due with webcore serializing something as per the first line in the error:

Panic location: /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/stdweb-0.4.20/src/webcore/serialization.rs:447 inline279.js:1:108

You can view the full code here: https://github.com/sotrh/gamepads

I've already created an issue on the GilRs gitlab: https://gitlab.com/gilrs-project/gilrs/-/issues/118