Factor underlying client-side engine out of yew app, for use in other clients #74
Comments
|
Hey @ronen !! I do like this because I am almost sure that by mixing render code and model we are missing on:
My only request is to do this change incrementally so that PRs are small and decrease the chances of conflicts |
|
Cool! I've already started working on this :) I'll see what I can do about making small PRs -- but I want to be sure it works before taking the code down a path that may not prove fruitful. Hopefully something coming up soon. |
Well, even though I don't have the whole thing done yet, seeing #83 go by made me realize you're right, I better PR what I can while I can :) So #85 is an initial step. |
Ultimate goal for security-union#74 is to move away from yew dependency, so originally used custom callbacks instead of yew's. But in working on websocket/webtransport connection (in another branch) it's currently deeply tied to yew Callback. So for now, for consistency it makes sense to use yew Callbacks everywhere. Later on in working on security-union#74 will try to come up with a consistent approach to extracting the yew Callback dependency.
|
Hi guys -- here's another commit waiting in the wings: 022476c "Factor out web media connection and use into model::connection::Connection" I haven't made a PR yet since that commit is based on the commits of #96 and a PR would include all those commits too. Once #96 is merged I'll rebase against main and create a PR with just the new commit. Just showing it to you now in case you want a sneak peak / give feedback ahead of the PR. |
* Factor out PeerDecodeManager * Add on_first_frame callback, use it to update for screen sharing * clippy & naming cleanups * Use yew::Callbacks instead of custom (for now) Ultimate goal for #74 is to move away from yew dependency, so originally used custom callbacks instead of yew's. But in working on websocket/webtransport connection (in another branch) it's currently deeply tied to yew Callback. So for now, for consistency it makes sense to use yew Callbacks everywhere. Later on in working on #74 will try to come up with a consistent approach to extracting the yew Callback dependency. * aside: move webaudio comment from attendants.rs to peer_decoder.rs (it got left behind when doing the initial refactor) * Added DecodeStatus, changed MultiDecoder::decode() to return Error Also, tidied: made a PeerDecode trait for the decode method * cargo fmt
|
H guys, FYI once #137 is merged, here's what I'm thinking my next steps are:
And once all that is working, I'd say it'd be a good time to re-visit the whole API. What do you think? |
I'd like to embed a zoom-rs client in an existing web / electron app, written in javascript using a non-yew UI framework. That would mean decoupling the encoding/decoding code and control mechanisms from the yew UI code, factoring them out to create an "engine" that could be used in other contexts. (Something like this would be needed also for #49 (comment) which suggests using electron on MacOS.)
I'm imagining another top-level directory
client-engine/that would hold that code. It would be set it up so that it would both:yew-uiappThe engine code wouldn't require specific HTML and wouldn't create any HTML. It would just provide a control API for establishing connections etc, it would take
ids of the canvas elements to render into, and it would use callbacks to communicate interesting events back to the app.My approach would be to first factor out the client engine code but keep it within
yew-ui/src/-- and once that looks good, snip it out and move it into that other directory and set up the cargo & npm mechanisms. The factoring could be done incrementally with PRs along the way, allowing reviews/suggestions as it goes and avoiding a massive shock to the code.What do you think? I'm happy to take this on.
The text was updated successfully, but these errors were encountered: