RFC: Make the forum clients more resilient to bad connections

  • GNU/Linux Admin

    Hey @sloosecannon -- good topic 😄

    In general, the times when connection drops are most noticible are during:

    1. Page navigations
    2. 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 😦

  • Plugin & Theme Dev

    @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:

    1. Page navigations
    2. 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

  • NodeBB

    @exodo This probably happens because the composer uses socket.io to load data. So if sockets aren't working the composer won't load. I will look into replacing the socket.io code in the composer with xhr at some point.

  • GNU/Linux

    @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:

    1. Page navigations
    2. 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!

  • GNU/Linux

    @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).

  • Admin

    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.

    0_1471819561113_Screenshot_20160821-163949.png

  • Gamers

    Does me remind of Pokemon Go 😛


  • @psychobunny I like that implementation a lot. It could appear in the little toast window that comes up for "new forum version".


  • I spy with my little eyes...

    0_1472668960493_upload-c64bd64c-f680-4e4c-aeb2-f751f8fd9f80

  • GNU/Linux

    @teh_g Yep, I got that as well. That looks much better, but it still was stuck even when the connection was recovered (The submit button was disabled)

  • GNU/Linux

    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?

Suggested Topics

  • 5
  • 11
  • 1
  • 5
  • 131
| |