WebSocket support

[ByteAlex]

My initial approach to supporting websockets in workers-rs.
Sending data works fine, though receiving data - for example through onmessage - does not work yet.

I'd appreciate some help figuring this out!

Also at maintainers, would this PR, if properly documented, get an OK from you?

[ByteAlex]

I did some initial investigation on why the onmessage does not work and it seems that the JS onmessage is not called at all.

export function __wbg_setonmessage_8bf4fad923b5767c(arg0, arg1) {
    console.log(new WebSocketPair()[1]);
    let ws = getObject(arg0);
    console.log(ws);
    ws.onmessage = function (evt) {
        console.log(evt);
        let fn = getObject(arg1);
        console.log(fn);
        fn(evt);
    };
};

The first log was solely to figure how the WS should look.
The second log was too see whether the WS is correctly instantiated.

These logs are written once a ws-request is received.

then I have the ws.onmessage and it's contents are never logged. So it does not seem to be an issue with the closure, but it implies that the ResponseInit did not properly carry the webSocket to the browser, I think?

Taking a look into the workers-chat-demo, I see

return new Response(null, { status: 101, webSocket: pair[0] });

Which should be the same as my rust implementation.
ResponseInit in worker-sys:

    #[doc = "Change the `webSocket` field of this object."]
    pub fn websocket(&mut self, val: &WebSocket) -> &mut Self {
        let r = ::js_sys::Reflect::set(self.as_ref(), &JsValue::from("webSocket"), val.as_ref());
        debug_assert!(
            r.is_ok(),
            "setting properties should never fail on our dictionary objects"
        );
        let _ = r;
        self
    }

But debugs of it show: The webSocket is defined in the ResponseInit:

{ status: 101, headers: HeadersList(0) [], webSocket: WebSocket {} }

[ByteAlex]

I intended to go to sleep when I was sending my investigation answer, but I wanted to get this done, so I kept searching.

The issue was more stupid than I thought; It's not "set_onmessage", as implied by the generated WebSocket bindings from wasm, but set_event_handler.
After fixing those, this PR should be fully functional.
I've tested sending, receiving and echoing data aswell as the close event, but I was not able to test an "error" case yet.

[nilslice]

@ByteAlex - wow, thank you for all of this. We will start taking a look, but please convert it to a "ready for review" PR once you think it is out of Draft.

Also at maintainers, would this PR, if properly documented, get an OK from you?

Yes, I don't see why not! @zebp 👀 🚀

[ByteAlex]

@nilslice Will do! Planning to complete documentation later today (this evening) and will turn it into "Ready for Review".
I do not expect any more changes to the actual implementation, as I've been using the current version in my other project already and it seems solid!

What probably is important: I removed the web_sys::ResponseInit implementation and did an own implementation in worker_sys::response_init::ResponseInit, due to the required additional webSocket field.

[zebp]

Also at maintainers, would this PR, if properly documented, get an OK from you?

Yes, I don't see why not! @zebp eyes rocket

Yeah this would be awesome @ByteAlex! You're making great progress and it looks pretty good so far.

Edit: Removed clippy reminder, forgot it isn't commented out anymore we just pinned wasm-bindgen instead.

[ByteAlex]

Yeah this would be awesome @ByteAlex! You're making great progress and it looks pretty good so far.

Edit: Removed clippy reminder, forgot it isn't commented out anymore we just pinned wasm-bindgen instead.

Haha yeah, Linters / Formatter is always complaining about my code, but I think it should be all good now + it's ready for review! 🚀

[zebp]

Super minor changes, but overall this is awesome :)