render_async icon indicating copy to clipboard operation
render_async copied to clipboard

Stop polling based on the response

Open thiagorp opened this issue 6 years ago • 10 comments

First of all, thanks for the work on the lib :)

I have the following situation: I'm running a script in the background and want to poll for the logs. The problem I see with the current polling approach is that it never stops, only if some user-initiated event happens. But that's not a good experience in this case. Ideally, the polling should stop when the server returns that the script is done running.

Is it possible to solve it somehow?

thiagorp avatar Mar 23 '20 22:03 thiagorp

Hey, @thiagorp, thanks for submitting the issue!

The idea sounds interesting to me! You are right about the polling, it either goes on until you refresh the page, or you set it up to be turned off by an event.

I'm not sure how to build this, stopping polling based on the request response might be tricky. Are you able to stop polling by initiating an event to stop polling maybe?

We could add an option to stop polling if an event is dispatched from somewhere (does not have to be a user event like it is now):

<%= render_async comments_path, 
                 toggle: { event: 'stop-polling-event' }, # you would have to dispatch this from your JS code
                 interval: 2000 %> # poll for comments_path every 2 seconds

Then, you could use a default event or emit your own when render_async finishes each request. Catch that event, parse the response (we'd have to add response object to the event that is dispatched after request succeeds) and then emit another event to stop polling.

WDYT?

nikolalsvk avatar Mar 27 '20 06:03 nikolalsvk

I wanted to do exactly what @thiagorp wants to do. This is the workaround I came up with so that I could use the current version and keep my project moving. The user does have to manually start the polling, but when the task is complete I redirect the user and stop the polling.

<a href='#' id='detail-button' class = "button">Turn on Polling</a>
<%= render_async "/status/#{@thing.id}", toggle: { selector: '#detail-button', event: 'click' }, interval: 10000 %>
<%= content_for :render_async %>

<script>
  document.addEventListener('render_async_load', function(event) {     
    if(event.container.innerHTML.trim() == "VALUE_WHEN_COMPLETE") {
      window.location.href = "https://something.to/redirect/to";
    }
  });
</script>

I'm a bit rusty with the javascript, tried to fire the click programmatically so the user didn't need to start the polling. However this caused the polling to go crazy, not sure why.

document.getElementById("detail-button").click();

The idea presented by @nikolalsvk would be ideal longer term.

** Sidenote - one thing I realized is that Turbolinks can mess up the page properly polling. In my link_to tags I had to turn Turbolinks off **

<%= link_to("View", polling_page_path, :"data-turbolinks" => false) %>

benr75 avatar Apr 17 '20 02:04 benr75

Hey, @benr75, thanks for the suggestion that you've been using! I think some people will find it useful until we get some solution on the way.

BTW, for your sidenote about Turbolinks, have you tried setting the config variable like described in the README maybe? It could save you some extra code :) EDIT: The new 2.1.6 release might solve your problem with polling and Turbolinks! Give it a try and let me know how it goes :)

nikolalsvk avatar May 09 '20 16:05 nikolalsvk

I think #118 is related - the use case would be:

  1. Start polling on page load.
  2. Set up a toggle that would disable polling based on the toggle.

The polling continues forever even when the server replies with an error status. Maybe an easy solution would be an option to stop polling on an error status code?

vanboom avatar May 30 '20 21:05 vanboom

Maybe an easy solution would be an option to stop polling on an error status code?

This sounds good, we could add an option to stop polling on specific error code. Something like stop_on: [401, 404] or stop_on: :error.

nikolalsvk avatar Jun 01 '20 10:06 nikolalsvk

I implemented some code that sets up async-stop and async-start events on the container element to give us total control over the starting and stopping of the polling. I will submit a PR for your consideration.

vanboom avatar Jun 02 '20 21:06 vanboom

Suggest closing this issue. The 'async-stop' event works great for stopping the polling when a background job is completed, or based upon some other status.

vanboom avatar Aug 19 '21 18:08 vanboom

It would be nice to provide some kind of an example of how to do this with the response of the polling request. I think we can't do it right now because we don't return response data in the default events (like the render_async_load event).

What you suggested here:

when a background job is completed, or based upon some other status.

might work, but it depends on factors we can't control. For example, what if a user doesn't have an indicator like a finished background job to stop the polling? WDYT, @vanboom?

nikolalsvk avatar Aug 24 '21 13:08 nikolalsvk

Since render_async purpose is to render views, the output is going to be a html or js partial. I think it would be up to the client to handle the response of the polling request in the application specific software, then trigger the async-stop event to stop the polling. So I see this issue as something that the user can already do, not requiring a change to render_async.

In my app, I monitor the progress of a Sidekiq worker using polling that renders a JS partial. When the job is complete or on any other error, my logic triggers async-stop which stops the polling. Note the README where you can manually set the container_id that render async uses - this is key to identifying the element in the async-stop event.

Something like this in the rendered view (e.g. jobs/show.js.erb):

<% if @job.complete? %>
  $("#<%= dom_id(@job, :polling)%>").trigger("async-stop");
<% end %>

vanboom avatar Aug 24 '21 15:08 vanboom

Right, the idea itself sounds pretty complicated from what we have right now. I want to keep the issue open so it attracts new ideas we can have about this.

What you did is great and we're thankful for it, it would be even better if we had some kind of example of how this @job.complete? works so folks can get an idea of how to build their solution.

nikolalsvk avatar Aug 27 '21 11:08 nikolalsvk