Unfocus triggers extra queries with periodically observed

[kingdonb]

Hi, I have this page listing records with a Filterrific search and other controls at the top. I am using AJAX with the form_for_filterrific as described in the View API docs.

When I type into the search field, it updates in approximately real-time as I type, as you'd expect it to. When I'm done typing, I see the result I was looking for at the top of the list!

Then, approximately 2 seconds after typing, at the pace I normally use when typing and clicking, I click on the top result. The rows in my table are processing the click through a JavaScript onclick handler. It seems to lose my click, as the filterrific form receives the blur event and proceeds to refresh the query quickly just one more time, briefly showing and hiding the progress animation.

I'm not sure if I'm losing the click because the filterrific form is repeating the query, or just because the progress animation moves my table down the page while it's appearing. But it's annoying, and I thought I'd write it in an issue report while I try to fix it.

Right now I'm trying to make sure the placement and styling of the progress animation is fixed so that it doesn't cause things to move around the page when it appears and disappears.

[kingdonb]

Putting the filterrific spinner inside of a container with enough space for it, with position: absolute, so that the page dimensions don't change when it was shown or hidden, seemed to fix this for me.

It's still running extra queries but it doesn't affect the user experience.

Is it possible maybe to get the input to Filterrific thrown into a hash that can be summed and compared, so that we don't run the same queries twice, once on the event monitoring periodically observing key events until they stop, and then again on blur?

This is mostly solved for me, now it's just an architectural question. The UX bug I was able to fix.

[mark100net]

I just noticed the same issue (both the UI one, which I worked around similarly, and the extra query). Surprised I never encountered it before.

Also this might be the same as #84

[kingdonb]

So, not really solved. Actually I was able to trigger the "lost click" behavior even when the span.filterrific_spinner was not moving things around the page anymore. So this is probably worth addressing.

[kingdonb]

@mark100net that is exactly my issue, and that looks like a very elegant solution that does not introduce scary architectural changes.