Stop polling based on the response about render_async HOT 10 OPEN

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.

from render_async.

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) %>

from render_async.

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

from render_async.

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?

from render_async.

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?

from render_async.

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.

from render_async.

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.

from render_async.

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?

from render_async.

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 %>

from render_async.

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.

from render_async.