WebSocket support & example about seed HOT 8 CLOSED

Agree. It would be appropriate for the WIP server_integration example. First, I'm going to first attempt a high-level wrapper for fetch requests: this is a critical missing feature. (Eg like using fetch/axios in ES6, or an async version of Python's Requests.) Asking a user to dive into the raw web_sys fetch/Request API's not feasible. Then would love WebSocket support.

Perhaps once sorted, all this could be placed in a general crate usable by any wasm-bindgen framework.

Related: seanmonstar/reqwest#288

from seed.

Will do. It's on my todo list now. Also, what are your thoughts on implementing a high-level API in Gloo and then pulling it in for use here (just the minimal websocket module)? That would be nice because it would be a bit more universal. If you are good with that, I'll open an issue there, cross link them, and then discuss a bit more with the WASM WG.

from seed.

I think starting with Gloo is the answer, and if you come up with a working soln, but it takes too long for a release or PR merge, we can integrate it into a new Seed version until released in Gloo.

Much like Fetch, I don't see this as being tightly-coupled to a framework.

from seed.

related: #38

from seed.

I've recently built an app with this framework (which is awesome btw) and I used the websockets example to get started with setting up the Websockets integration. I wanted to share a few thoughts on my experience to see what you all think in terms of potential improvements &c.

difficulties

• Using wasm-bindgen types to differentiate between string & binary messages was a bit of a hurdle. I got it working, but I definitely see this as a stumbling block for new users. Could be fairly defeating for some folks I suspect. Eg, need to use ArrayBuffer, passed to a Uint8Array, and then copy it to a vec for access the raw bytes.
• Finding a way to store the callbacks for the Websocket without having to leak all of them (which is obvs not good) could be a stumbling block for folks as well.

a path forward

• We could introduce a higher-level type to store the underlying web-sys Websocket as well as its callbacks. We could just call it Websocket.
• It could expose a few helper methods, or the like, for being able to handle binary vs text messages.
• We could simply store all of the callbacks in a private vec on the wrapper Websocket type. When it goes out of scope, the callbacks will be dropped as well.
• The callbacks can be simply stored in an Rc wrapped inside of an enum to account for function type variance. This is what I did. Worked out pretty well.

Anyway, @David-OConnor you're an absolute champion. Thanks for all of the excellent work you've put into this. This framework is a game-changer, no doubt. I'm happy to help out in any way.

from seed.

Agree - I think the way forward is to add (and document) a high-level WS API. The example's a low-level stopgap that demonstrates it's possible, and shows the web_sys-level API endpoints we could use when building this API. Complicating factor: I haven't used WS, so am not (yet?) in a position to comment on the details. Want to submit a PR of your path forward? It doesn't have to be complete, documented or finalized: Any API that wraps the web_sys code, and addresses problems you ran into is better than the current approach (ie none).

We can build this iteratively if needed, until reaching an easy-to-use, high-level API. Can start with wrappers that smooth out the web_sys syntax.

from seed.

@David-OConnor @thedodd I absolutely agree with your direction!
Unfortunately I was quite busy the last month and that won't change in the next couple of weeks/month.
But probably I can test once in a while the current implementation :)

from seed.

@flosse I'm there too re super busy!

from seed.