[jQuery] Gebruiker input en ajax aanvragen

[Bender]

Dit probleem duikt eigenlijk vooral op met de wat zwaardere real time search aanvragen.

Een gebruiker zoekt op "Tweakers" en voor het gemak is er een H1 met Tweakers, het resultaat wat je dan ziet:
Twe
Twea
Tweak
Twe
Tweake

Dus soms lopen requests door elkaar. Een oude request stoppen lijkt niet voldoende en er blijft ergens een grote vertraging in zitten maar het is me onduidelijk waar.

Ik heb bijvoorbeeld dit toegepast;
http://www.codeproject.co...Before-Calling-the-Same-A

code:

jQuery(document).ready(function(){
    var currentRequest = null;
    jQuery('#searchbox').keyup(function() {
        var text = jQuery(this).val();
        currentRequest = jQuery.ajax({
            type: 'POST',
            data: 'search_text=' + text,
            url: 'AJAX_URL',
            beforeSend : function()    {           
                if(currentRequest != null) {
                    currentRequest.abort();
                }
            },
            success: function(data) {
                jQuery('#data').html(data).show();
            }
        });
    });});

Maar de ajax requests zijn echt traag terwijl de url los opvragen gewoon goed snel is.

[ Voor 63% gewijzigd door Bender op 12-11-2014 17:01 ]

[RobIII]

Je moet gewoon eventueel lopende requests cancellen op 't moment dat je een nieuwe afvuurt (of geef ze een 'sequence id' mee die je "terug echo'ed" in elke response zodat je weet dat je een oud antwoord hebt ontvangen omdat je client-side al op een nieuwer/hoger 'sequence id' zit).

[Bender]

RobIII schreef op woensdag 12 november 2014 @ 17:21:
Je moet gewoon eventueel lopende requests cancellen op 't moment dat je een nieuwe afvuurt (of geef ze een 'sequence id' mee die je "terug echo'ed" in elke response zodat je weet dat je een oud antwoord hebt ontvangen omdat je client-side al op een nieuwer/hoger 'sequence id' zit).

Dat heb ik gedaan, zie het script. Lopen nog niet persee correct maar oude worden wel gecancled.

Maar de grootste bottleneck lijkt m te zitten in het plaatsen van de html.
http://jsperf.com/innerhtml-vs-replacehtml
Waarbij $.html() het langzaamst is en .interHTML al sneller, maar dat de replaceHtml functie uit het voorbeeld een veelvoud sneller kan zijn.

code:

   function replaceHtml(el, html) {
      var oldEl = el;
    /*@cc_on // Pure innerHTML is slightly faster in IE
                oldEl.innerHTML = html;
                return oldEl;
        @*/
      var newEl = oldEl.cloneNode(false);
      newEl.innerHTML = html;
      oldEl.parentNode.replaceChild(newEl, oldEl);
    /* Since we just removed the old element from the DOM, return a reference
        to the new element, which can be used to restore variable references. */
      return newEl;
    }

Maar het is nog steeds traag eigenlijk.

[RobIII]

Bender schreef op woensdag 12 november 2014 @ 17:54:
Dat heb ik gedaan, zie het script. Lopen nog niet persee correct maar oude worden wel gecancled.

Oh, daar heb ik overheen gekeken. My bad.

Bender schreef op woensdag 12 november 2014 @ 17:54:Maar de grootste bottleneck lijkt m te zitten in het plaatsen van de html.

Onzin; ongeacht welke je gebruikt is het vervangen van een DOM node een "atomische" actie; het is niet dat als je "sneller je HTML plaatst" het probleem opgelost is. Het probleem is dat responses soms wat langer op zich laten wachten (logisch; het blijft het web) en daardoor niet in de juiste volgorde "completed" zijn en dus in verkeerde volgorde afgehandeld worden. Hier kun je tegen "jsperfen" tot je een ons weegt; het probleem zit daar écht niet.

Overigens, over een andere boeg: ik zou er sowieso voor zorgen dat er niet meer dan, wat, 2, misschien 3 requests per seconde gestuurd worden. Als er in de afgelopen 1/2 seconde (of 1/3 seconde) een request gestuurd is, "schedule" dan de volgende met een setTimeout. Bij iemand die een beetje typecursus heeft gevolgd loop je niet je server te hammeren met 30 requests per seconde voor een "stomme autocomplete".

[ Voor 21% gewijzigd door RobIII op 12-11-2014 18:34 ]