-
Notifications
You must be signed in to change notification settings - Fork 6
feat(client): add WebSocket channel setup #2013
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
You can access the deployment of this PR at https://renku-ci-ui-2013.dev.renku.ch |
cc8e44d
to
e4108b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very good!
I have a few minor comments on some code improvements, but I overall like the structure.
function handleUserInit(data: Record<string, unknown>, webSocket: WebSocket, model: any): boolean { | ||
if (data?.message && (data.message as string).toLowerCase().includes("connection established")) { | ||
// send request for getting the UI version | ||
webSocket.send(JSON.stringify(new WsMessage({ requestServerVersion: true }, "init"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you not do this?
webSocket.send(JSON.stringify(new WsMessage({ requestServerVersion: true }, "init"))); | |
webSocket.send((new WsMessage({ requestServerVersion: true }, "init")).toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern is repeated in every send
function of both the client and server WebSocket channel. I changed it everywhere so that all the JSON.stringify(<content>)
become (<content>).toString()
.
Thank you for the review! I addresses the points you mentioned, and improved the logic to open/close the channel so that we won't miss the session cookies (or retry shortly after when that happens) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great and works well. The occasional initialization problem on first load seems to be fixed now. Looking forward to using this to improve the UX!
- start the WebSocket channel - handle messages and termination fix #1338
1bc0c1d
to
dcd865e
Compare
Thanks for the review! Could you re-approve? |
- start the WebSocket channel - handle messages and termination fix #1338
dcd865e
to
23c5af4
Compare
- start the WebSocket channel - handle messages and termination fix #1338
Tearing down the temporary RenkuLab deplyoment for this PR. |
This PR adds the client-side logic for WebSocket.
The WebSocket channel is set up and it gets re-created in case of recoverable errors (to be further expanded), and it listens to incoming messages.
Once a new message comes, it checks for a suitable handler and executes it.
Mind that we save minimal data to the store for the WebSocket channel itself, but the handlers can modify any part of the model.
This fully moves the logic to check for UI version updates to the WebSocket channel. It's also a good example of how we can send all the required data through the channel, although we probably want to avoid this behavior in most cases where we need to get a lot of data.
How to test
Open the network tab and verify that the WebSocket channel is created and information about the client version is sent regularly.
Further development
There will be a follow-up issue to finish and enable the (already partially coded) logic for finding session updates through the WebSocket channel.
/deploy renku-gateway=master #persist
fix #1338