@julian said in RFC: Make the forum clients more resilient to bad connections:
Hey @sloosecannon -- good topic
In general, the times when connection drops are most noticible are during:
- Page navigations
- Posts
Other real-time things you honestly can't tell, since if someone posts and it doesn't show up right away, it's not really all that detrimental to the end user experience
Now, the former, we really can't do anything about, since if the call to the api route takes awhile, we just have to wait... the latter, we could. A post could be rendered on the client-side, and then stored in the active session while it goes about saving to the backend.
The risk, of course, is that the user might leave the site, at which point poof, goes the transient data.
Not so good
i really dont understand those connections things but the main problem i get on bad connections aka 3g, sometimes on 4g too is that i hit reply and composer doesnt open, i need to reload page and then hit reply again
That is randonmly of course
@julian said in RFC: Make the forum clients more resilient to bad connections:
Hey @sloosecannon -- good topic
In general, the times when connection drops are most noticible are during:
- Page navigations
- Posts
Other real-time things you honestly can't tell, since if someone posts and it doesn't show up right away, it's not really all that detrimental to the end user experience
Now, the former, we really can't do anything about, since if the call to the api route takes awhile, we just have to wait... the latter, we could. A post could be rendered on the client-side, and then stored in the active session while it goes about saving to the backend.
The risk, of course, is that the user might leave the site, at which point poof, goes the transient data.
Not so good
Right - I believe Discourse does something like that as well. And it does indeed have exactly that issue 
I'd be interested in a way to debug what exactly has broken down in socket.io when these drops happen - it seems like it sometimes just refuses to reconnect without a page refresh, and I think that's the thing people find most annoying - it's not necessarily the fact that it breaks, it's that it breaks and stays broken!
@baris That would be nice. Also, probably not a bad idea to add some kind of UI cue to indicate that the button has been pressed, and maybe something in the way of error-checking to let people know when the socket is broken (That would be more of a general thing - there are a lot of actions that don't work at all without any kind of feedback - upvoting, scrolling to load posts, IIRC some of the buttons too).
Interesting this topic came back up - just earlier today I saw this on Reddit (mobile) and I liked how they did it. The alert at the bottom slides up to let you know you disconnected and then slides away a few moments after you reconnect.
@psychobunny I like that implementation a lot. It could appear in the little toast window that comes up for "new forum version".
Hmm, so I just found an interesting behavior that might be the cause.
It appears that NodeBB uses the websocket by default, but when the connection fails, it falls back to polling!
It does not appear to reconnect to the websocket after the failure. There's an easy way to see this - open up Chrome's dev tools on a NodeBB site, then kill your network connection.
It starts sending polling requests, and continues even after the connection is re-established!
Perhaps this is the reason that it gets "stuck" and has weird connectivity bugs?
