add an ajaxCounter to the pager object so it can index each request and ... #443
Conversation
…nd refuse to process old requests and only process the last one, this is important because when you execute multiple requests, sometimes the old requests return AFTER the new request has returned, meaning you get a mixed up data, this will stop that, even though really it should cancel the ajax request, but once the server has it, I don't know how you can do that.
|
shouldnt this be done on the user side to handle async calls? |
|
I can't think of a single reason why you'd want to filter the table and want updates out of order, surely if you type "gr" and then it searches and you type another "ou" (gr+ou) then you don't care about the results from "gr" and only the results which come from "grou", but if you get served the results from "grou" and then the "gr" also completes, it'll change the table and overwrite all your filters. this overwriting of the filters is actually something I want to change also, I think it shouldn't do that, but thats another topic of discussion :) or perhaps you can explain a reason why it might be desirable? |
|
Honestly, I don't really like the counter idea. What if it gets really out of sync somehow? Then nothing will get through. Why not increase the |
|
the counter is only updated in one place and it's used in a specific circumstance, there is only one location where the code performs an ajax call and if there is more than one, we can refactor it together. no, the options you've suggested are not enough to prevent the problem that I've mentioned here, you are just hoping it doesn't trigger the race condition, but ultimately, it's not a solution, it's a workaround. this solves the problem by making it not possible to accept out of order requests, it doesn't prevent future requests cause if you trigger another update, it'll execute again and attempt to find the last one, if the ajax is constantly failing, then there is nothing you can do to prevent the situation in the first place since it's out of your hands. perhaps we can add an option which states "ajaxAccept: [any,last]" and any == no restriction, last == last counter value, then it's configurable for any situation where this counter is not desirable |
Honestly this is what I ended up doing, my users take forever to get a thought out and thus type very slowly, the delay I needed was insane, so I just set it to false. I love search as you type but it just didn't work for me I ran into this same issue, hitting enter is safer and works 100%. |
|
for that particular use case I can understand it's desirable, I know users like this also, but in the scenario that you want dynamic updates as you type, then the counter trick really does help a lot, I've attached a screenshot of how it stopped my table from doing random updates in any old order and at least made it useful. |
|
Well, as I said, I keep an open mind so I'm not against adding this.. but wouldn't it be better to use a less than comparison versus a not equal to comparison? if (counter < p.ajaxCounter) { |
|
I think you're assuming it might become larger than the testable condition somehow? I guess there is no harm to that, I mean, it's largely not changing anything, still works the same way, so I'm ok with that. do you want the option to configure it? or do you think it should be automatic? I personally can't see a situation where multiple updates occur and they arrive out of order is desirable to use an older update over a newer one, but if somebody can provide a use-case description where it would be something useful, I'm all ears. |
|
I don't think an option would be necessary - as long as it works. But, I was wondering if you tested this with a filter search or sorting? Looking at the screen shot, I see different page requests but neither the filter nor sort change. |
|
yeah, it works as well, see the screenshot, I suppose it'll work with anything that attempts to go through this code and do an ajax request, meaning it won't make any difference when working with a static table, since no ajax comes into play |
add an ajaxCounter to the pager object so it can index each request and ...
...refuse to process old requests and only process the last one, this is important because when you execute multiple requests, sometimes the old requests return AFTER the new request has returned, meaning you get a mixed up data, this will stop that, even though really it should cancel the ajax request, but once the server has it, I don't know how you can do that.