Live removal of issue comments using htmx websocket

[anbraten]

First step into "realtime" updating UI using htmx with ws extension as discussed in #2287 and #25661

As rendering comments was quite tough (a lot of code changes) I just implemented the updating UI part for removing a comment for now as a reference. All other events will be quite simple to add from now on and only require some rendering logic to be adjusted.

htxm logic based on #28908
websocket logic based on #26679 and #27806

Screencast.from.2024-02-16.17-50-20.webm

How it works:

• a tab / client connects via websocket to the server /-/ws
• the client sends on dom.load: { action: "subscrib", data: { url: "http://localhost:3000/anbraten/test/issues/1"}} to the server to let it know it is interested in updates relevant for this page
• another client triggers some action (for now deletes a comment)
• the notifier kicks in and sends the event as json via the pubsub system
• the websocket_notifier gets the event from pubsub
• the websocket_notifier checks for all locally connected sessions if their url is relevant for the issue comment and checks if the user of that session is allowed to receive that notification data
• the websocket_notifier sends the updated dom element (matched based on #id) via websocket to all previously filtered client sessions

TODO

• listen to events like comment adding (with permission handling)
• send new issue comments templates through websocket
• send sth like url from client to server via websocket to filter necessary events (the url could be used to detect that only updates for a specific issue and general updates like new notifications are relevant)

[anbraten]

I will wait with further development until #28880 has a final decision for now. Just wanted to do this POC to see and show the team if it could be used for the discussed realtime topics as well.

[lunny]

Wouldn't we say htmx will be used on simple situation? I think this page is very complex.

[yardenshoham]

I agree with lunny, this is more complex than I imagined but hey, if it works that's awesome. Do we really have 2 way communication here though? Maybe SSE fits better for this use case

[silverwind]

I agree with lunny, this is more complex than I imagined but hey, if it works that's awesome. Do we really have 2 way communication here though? Maybe SSE fits better for this use case

We need a Websocket in any case as SSE is too limiting:

• max. 6 connections limitation per browser is a big problem when opening many tabs
• no 2-way communication
• SSE is seldomly used and therefor likely buggy depending on browser, websocket is a more stable and well-supported API

[anbraten]

Is it fine to hook into services/notify to get updates about changes like the added comments?

[lunny]

Is it fine to hook into services/notify to get updates about changes like the added comments?

I think it should be. You need to implemente a new notifier like notification.

[silverwind]

When using the url as topic, I would need to publish to all urls a specific event could possibly be interesting for. So ie an issue name change would be interesting for the issue page, but also for the issue list page and the issue list page of an org, right?

Maybe per-repo will be fine for a start, e.g. key repo:owner/name and server would then publish all changes to the repo. We don't have to over-complicate it at this stage, imho.

[silverwind]

BTW if we keep melody, we would likely need to increase it's MaxMessageSize as the default is only 512 as I recently discovered. I don't know why it has that so low, other libs I used set 100MB default 😆.

[anbraten]

Okay, I adjusted the code a bit so it sends messages through pubsub and to use subscriptions instead of the for loop iterating the sessions.

I currently see two options how the initial notifier event could be brought to a websocket client. What do you think?

• Generate the templates per user, send it via pubsub to a topic like <user-id>:<repo-owner>/<repo-name> and forward the message to websocket client. Allows us to avoid marshalling the necessary data for the pub-sub message, however it would be tricky to know if we even need to generate the template as we don't know it a specific user is listening a topic.

• Sending the notifier data as json via pubsub, inside the pubsub subscription handler of a client check the permissions of that user, generate the template and send it via websocket. I think marshalling the notifier data could be a bit tricky.

[lunny]

Maybe the topic should still contain the issue and index. And it also includes the actions like delete/create/update. Because I think different pages of the same clients should not share the same web socket client.

[lunny]

When an anonymous user are staying on an issue view page, shouldn't the page will be automatically updated?