3

This is a front end project that is using socket.io for all communication with the server. This allows for push which is good, but recently we have been asked to provide a pause button. The pause button is intended on stopping the data from changing out on the ui if the user does not wish it to do so automatically.

We currently have a class that wraps the web-socket and provides very minimal wrapping of socket.io.

The problem is, we can't just turn off the socket. User interactions need to continue to work, and different views have different specs as to what messages need to be ignored.

Ultimately its a big global boolean no matter how you slice it, and that sucks. I would rather not have it truly be a global variable, so here are the idea's I've had so far:


Narsty Global

  // A non pausable listener
  socket.on('myEvent', function(data){
      // do thing
  });

  // A pausable listener
  socket.on('myPausable', function(data){
      if(window.isPaused){ return false; }
      // do thing
  });

Passed Value

  // A non pausable listener
  socket.on('myEvent', function(data){
      // do thing
  });

  // A pausable listener
  socket.on('myPausable', function(data, isPaused){
      if(isPaused){ return false; }
      // do thing
  });

Wrapped Method

  // A non pausable listener
  socket.on('myEvent', function(data){
      // do thing
  });

  // A pausable listener
  socket.onLive('myPausable', function(data){
      // do thing
  });

Separate Class

  // A non pausable listener
  socket.on('myEvent', function(data){
      // do thing
  });

  // A pausable listener
  liveData.on('myPausable', function(data){
      // do thing
  });

Currently there is ALOT of messaging taking place over the socket, and there is only going to be one 'PAUSE' toggle on the UI, so this needs to be done carefully. Advice and best practices are appreciated. Thanks folks.

3
+50

I have some cognitive dissonance regarding the pause button - as a user, I consider 'Pause' to mean - halt what the server is doing. From your requirement, though, it seems that the server is not affected by the button at all, which might be confusing, and even misleading, as the feedback to the user really stops. I believe that in most cases, a button called 'Stop animation' or a toggle called 'Auto-refresh' might convey the idea to the user better.

To the matter at hand, I could suggest one more idea, which is having a flag on the server, which will prevent relevant messages from reaching the client altogether when paused. This way, the only change in the client is adding the server message to pause or un-pause, and the rest stays the same.

If that does not make sense in your case, I believe that the simplest solution (although deemed ugly) will be the best, since it has the least number of moving parts. Use a global state variable (under a suitable namespace of course - window.MyAmazingApp.isPaused), and use it as necessary, leaving other code untouched.

  • The UX on this is actually pretty good. It just pauses the UI from updating, the server spams regardless and is un-pausable. – Fresheyeball Mar 13 '14 at 15:31
  • Right now I am doing something similar. I just attached the state to the socket instead of the window. So socket.isPaused.status which satisfies the name spacing. Is there truly no more advisable way? – Fresheyeball Mar 13 '14 at 18:57
  • My approach is very KISS - and when you think about it, it does make sense - the flag is global by design - a single button for the whole page, so it stands to reason that its state will be globaly available. Anything more might complicate code readability and maintenance... (in my opinion) – Uri Agassi Mar 13 '14 at 19:40
  • Ok, that is valid. Is there a reason to have it attached to windowrather than Socket? – Fresheyeball Mar 13 '14 at 22:27
  • Well, it doesn't sound like it is part of the Socket status, does it? The socket is not paused - the UI is paused, so it sounds more like part of the state of the UI... – Uri Agassi Mar 14 '14 at 6:41
0

I presume that you need to update the UI with the most recent information when you un-pause the update.

This means that you want pausing to occur on the UI and not on the socket. Let the socket run freely, updating local state. For your UI, you use a copy of the local state for display and don't refresh the copy until you unpause everything.

  • This is essentially the behavior we are going for. I would just like feedback on how to best handle the nasty global state. – Fresheyeball Mar 13 '14 at 15:30
  • The state is local to your UI. Depending on your UI state, you use the local copy or the state that is being continually updated. – BobDalgleish Mar 13 '14 at 16:25
  • Thats sounds massively stateful. State is evil, so evil I felt the need to start a bounty on how to manage a single global flag. It also does not give me any direction on how to manage that flag, just how I might implement based on that flag. In other words, this is still a non-answer. – Fresheyeball Mar 13 '14 at 18:55
  • "State is evil." Give me a break! The collection of data that your app displays is sometimes called the display state. It has nothing to do with "evil." DON'T make it a global flag. Make it a flag that is local to your UI. – BobDalgleish Mar 13 '14 at 18:58
  • Yes, its necessary, but things having more state then needed is often the source of bugs and should be avoid when possible in favor of statelessness. The flag is global in the UI, and only for the UI. I'm sorry if that was not clear. – Fresheyeball Mar 13 '14 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.