Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop polling based on the response #106

Open
thiagorp opened this issue Mar 23, 2020 · 10 comments
Open

Stop polling based on the response #106

thiagorp opened this issue Mar 23, 2020 · 10 comments

Comments

@thiagorp
Copy link

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?

@nikolalsvk
Copy link
Owner

nikolalsvk commented Mar 27, 2020

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?

@benr75
Copy link

benr75 commented Apr 17, 2020

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

@nikolalsvk
Copy link
Owner

nikolalsvk commented May 9, 2020

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

@vanboom
Copy link

vanboom commented May 30, 2020

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?

@nikolalsvk
Copy link
Owner

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.

@vanboom
Copy link

vanboom commented Jun 2, 2020

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 pushed a commit to vanboom/render_async that referenced this issue Jun 2, 2020
vanboom pushed a commit to vanboom/render_async that referenced this issue Jun 26, 2020
nikolalsvk added a commit that referenced this issue Jul 31, 2020
#106 Add polling control start/stop events
@vanboom
Copy link

vanboom commented Aug 19, 2021

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.

@nikolalsvk
Copy link
Owner

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?

@vanboom
Copy link

vanboom commented Aug 24, 2021

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

@nikolalsvk
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants