Õige töö Ajaxi taotlustega WordPressis

Kui töötate kolmanda osapoole API-dega ja teete seda asünkroonselt, on alati võimalus, et kõik, mida te taotlete, annab soovimatu tulemuse.

Võib-olla on see veakood, võib-olla on see hoiatus või võib-olla lihtne sõnum, mis ütleb midagi sellist nagu "Me töötleme endiselt teie taotlust."

Igal juhul saate nendega serveri poolel tavaliselt hästi hakkama ja andke kliendile teada, kuidas seda käsitleda. Kui aga tegelete viimase juhtumiga, blokeerib teid kolmanda osapoole töötlemine; on ka muid asju, mida saate selle olukorra paremaks lahendamiseks teha.

Näiteks viimasel juhul on parem veidi oodata ja seejärel uuesti päring teha, et näha, kas API-l on teie jaoks erinev vastus.

Kuid seda tehes on vaja Ajaxit, mis ilmselt nõuab JavaScripti. Üks ilmsemaid, kuid aegunud meetodeid selleks on setIntervali kasutamine.

Selle probleemiks on aga see, et see loob taotluste virna ja siis, kui vastus on valmis, saavad kõik virnas olevad üksused sama vastuse.

See võib iga serverit drastiliselt mõjutada. Ja selleks on paremaid viise.

Õige töö Ajaxi taotlustega

Nagu tavaliselt, kuna WordPress tarnitakse koos jQueryga, kasutan seda; Siiski soovitan teil tungivalt – kui te seda juba teinud pole – vaadata ES6-s olevat Ajaxit, et saada aimu, kuidas seda natiivselt teha.

Igatahes on idee järgmine: intervalli seadistamise asemel kasutage vastuse õigeks hindamiseks sisseehitatud Ajaxi funktsioone. Ja ainult teatud tingimustel käivitage funktsioon uuesti.

Näide: jQuery $.post meetod pakub mõningaid funktsioone, mida saab täpselt selleks kasutada. Näiteks pakub see selliseid meetodeid nagu:

• tehtud()
• ebaõnnestub ()
• alati()

Ja igaüks neist on ette nähtud käitamiseks teatud tingimustel, mida ma näitan hetkeks mõnes koodinäidises.

Enne selle tegemist on siiski oluline mõista, et on mitmeid saadavaid parameetreid, millega ma eeldan, et olete tuttav.

• WordPress Ajaxi URL (mida ma määratlen kui acme.ajax_url),
• meie vaadatava postituse URL (mis salvestatakse muutujasse sUrl),
• ja turvalisus, mida ma kutsun acme.securityks

Kui mõni ülaltoodust pole selge, lugege lingitud lehti, et näha, kuidas see saavutatakse.

Kuid siin on idee, kuidas saate hallata korduvaid Ajaxi vastuseid ilma setIntervalita.

1 Funktsioon töö jaoks

Esimene asi, mida peate tegema, on koondada töö, mida kavatsete teha, oma funktsiooni. See tähendab, et saate sellele helistada kõikjalt mujalt kliendipoolses rakenduses või isegi taimeri kontekstis (kui see on hädavajalik).

Näiteks :

var _processArticle = function() {

  var request =
    $.post(acme.ajax_url, {
      action:  'acme_get_data',
      url:      sUrl
      security: acme.security
    }, function(response) {
      // ...
    })
    .done(function(response) {
      // ...
    })
    .fail(function(xhr, status, error) {
      // ...
    })
    .always(function() {
      // ..
    });
}

Ja nagu näete, olen jätkanud ja eemaldanud mõned ülalmainitud funktsioonid.

2 Saate hakkama eduga

Edu korral saate funktsiooni $.post tagasihelistamiseks kasutada anonüümset funktsiooni. Peamine argument, mille pärast peaksite muretsema, on vastuse argument.

Tavaliselt meeldib mulle, kui mu vastusel on edu ja ebaõnnestumise atribuut. See muudab juhtumi käsitlemise lihtsamaks, kui vastus on täiesti edukas, kuid serverist tagasi tulnud andmed ei vastanud ootustele.

var _processArticle = function() {

  var request =
    $.post(acme.ajax_url, {
      action:  'acme_get_data',
      url:      sUrl
      security: acme.security
    }, function(response) {

      // Abort all request operations.
      if (false === response.success) {
        request.abort();
      }

      // Handle the successful response by modifying the DOM.
    })
    .done(function(response) {
      // ...
    })
    .fail(function(xhr, status, error) {
      // ...
    })
    .always(function() {
      // ...
    });
}

See ei tähenda tingimata ebaõnnestumist. See tähendab lihtsalt, et seda, mida ma otsisin, ei leitud.

3 Käsitlege ebaõnnestumist

Teisest küljest võib juhtuda, et miski võib ebaõnnestuda. Miks see juhtub, võib olla mitmel põhjusel ja selle õigeks mõistmiseks tasub uurida tagasihelistamise argumente, nimelt olekut ja viga.

var _processArticle = function() {

  var request =
    $.post(acme.ajax_url, {
      action:  'acme_get_data',
      url:      sUrl
      security: acme.security
    }, function(response) {

      // Abort all request operations.
      if (false === response.success) {
        request.abort();
      }

      // Handle the successful response by modifying the DOM like flashing the first image.
      $('img:first').fadeTo('fast', 0.5, function() {
        $(this).fadeTo('fast', 1);
      });
    })
    .done(function(response) {
      // ...
    })
    .fail(function(xhr, status, error) {

      console.log('There was a problem with contacting the API.');

      console.log('The status was:');
      console.log(status);

      console.log('The error was:')
      cosole.log(error);
    })
    .always(function() {
      // ...
    });
}

Ma ei saa siin konkreetseid näiteid tuua, sest iga API on erinev; aga soovitan vähemalt andmed konsooli välja kirjutada, et saaksid aru, mis toimub ja kuidas sellega kooditasemel graatsiliselt hakkama saada.

4 Käsitlege tingimusteta juhtumit

Sel konkreetsel juhul käivitub see funktsioon olenemata sellest, kas miski õnnestus või mitte.

var _processArticle = function() {

  var request =
    $.post(acme.ajax_url, {
      action:  'acme_get_data',
      url:      sUrl
      security: acme.security
    }, function(response) {

      // Abort all request operations.
      if (false === response.success) {
        request.abort();
      }

      // Handle the successful response by modifying the DOM like flashing the first image.
      $('img:first').fadeTo('fast', 0.5, function() {
        $(this).fadeTo('fast', 1);
      });
    })
    .done(function(response) {
      // ...
    })
    .fail(function(xhr, status, error) {

      console.log('There was a problem with contacting the API.');

      console.log('The status was:');
      console.log(status);

      console.log('The error was:')
      console.log(error);
    })
    .always(function() {
      // Regardless of what happens, this is where you can provide the user feedback.
    });
}

See funktsioon ei ole midagi, mida te alati vajate (pole mõeldud), kuid see on hea võimalus näiteks edenemisriba peitmiseks või kasutajaliideses millegi kuvamiseks. See võib anda kasutajale veidi tagasisidet, et päring on oma töö lõpetanud (jällegi, olenemata ebaõnnestumisest või õnnestumisest).

5 Jällegi õnnestumine

Lõpuks sarnaneb tehtud meetod paljuski edumeetodile, kuid mõelge sellele, et seda kavatsetakse teist korda nimetada.

See tähendab, et pärast seda, kui vastus on serverist vastuse argumendiga tagasi tulnud, käivitub sama asi uuesti, kui kõik muu on lõpule viidud.

var _processArticle = function() {

  var request =
    $.post(acme.ajax_url, {
      action:  'acme_get_data',
      url:      sUrl
      security: acme.security
    }, function(response) {

      // Abort all request operations.
      if (false === response.success) {
        request.abort();
      }

      // Handle the successful response by modifying the DOM.
    })
    .done(function(response) {
      // Display any additional changes you may want to make based on the respnse.
    })
    .fail(function(xhr, status, error) {

      console.log('There was a problem with contacting the API.');

      console.log('The status was:');
      console.log(status);

      console.log('The error was:')
      console.log(error);
    })
    .always(function() {
      // Regardless of what happens, this is where you can provide the user feedback.
    });
}

See annab teile veel ühe võimaluse teha vastuse argumendiga kõike, mida soovite teha, enne kui kõik on lõpule viidud.

Kasutan seda harva, kuid on olnud aegu, kus olen soovinud elemendi eemaldada alles pärast seda, kui midagi oli tehtud, kogu muu töötlus oli tehtud ja vastus oli edukas.

Võib-olla pole teil seda kõike vaja

Ilmselgelt on suur osa ülaltoodud koodist vaid demo jaoks, kuidas taotlusi käsitleda. Kuid eesmärk on näidata, kuidas nimetatud päringut käsitleda, ilma et oleks vaja taotluste virnastamise intervalle määrata. Selle asemel kasutate ära juba olemasolevaid funktsioone, et näiteks tõrke korral funktsiooni uuesti välja kutsuda.

Igatahes võib see mõne jaoks olla liialdatud, kuid teiste jaoks, kes on harjunud kasutama setInterval, võib see olla palju parem viis Ajaxi taotluste haldamiseks, mis ei virna ja käivitavad sama päringu serverisse, kui vastus on juba saadud. juhitud.

Ja lõpuks on see eesmärk: tõhus kood, mis hangib meile vajaliku teabe ilma kolmanda osapoole API-t või meie enda kasutaja brauserit segamata.