metamourge890745dI'd wrap up modifications that happen within a certain time period.
Eg, if the comment count gets modified,
The client receives an update every 3 seconds, that contains the updated data of the last 3 seconds.
This. I tend to like rolling backoffs as well. I'll keep a pair per user in an actor state for active session. The longer a user goes without seeing an update that contains new data, the longer the backoff gets to a set space.
For things like this I'll do 2^nth to 16, then default to a 60s periodicity check.
hitzoR28045dWell, websockets are designed to update the page many times per second. If you wrap multiple messages in some timeframe into one update, it isn't really realtime.
uyouthe1395044dIf you can fuck up at this, the fuckup itself will happen with rerendering. I’d recommend save the link to your counter element to query dom on update exactly one time and rerendering exactly one dom node. Also throttle the update function.
rantingduck244dThanks I'll take these under advisement.
Another idea i just considered is this.
-When the new comment is added, the client is notified through socket with the "id" of the post that owns the comment.
-Then the client identifies the particular post in the posts list object and just updates only the "count" property. (No update will happen if the post is not in view or not loaded in the posts list object).
This will prevent full refresh and also the client will only worry about the posts currently on the users view.
hitzoR28044d"Full refresh"? Why would you do that? Just send the post data in the websocket message. You shouldn't need to query something extra after the client receives ws message.