Lavorare correttamente con le richieste Ajax in WordPress

Ogni volta che lavori con API di terze parti e lo fai in modo asincrono, c’è sempre la possibilità che qualunque cosa tu stia richiedendo restituirà un risultato indesiderato.

Forse è un codice di errore, forse è un avviso, o forse è un semplice messaggio che dice qualcosa del tipo "Stiamo ancora elaborando la tua richiesta da parte nostra".

In ogni caso, di solito puoi gestirli bene sul lato server e lasciare che il lato client sappia come gestirlo. Ma se hai a che fare con quest’ultimo caso, è lì che sei bloccato dall’elaborazione di terze parti; ci sono altre cose che puoi fare per gestire meglio questa situazione.

Ad esempio, in quest’ultimo caso, è meglio aspettare un po’, quindi effettuare nuovamente la richiesta per vedere se l’API ha una risposta diversa per te.

Ma quando lo fa, richiede Ajax che ovviamente richiede JavaScript. Uno dei metodi ovvi, ma più datati per farlo è usare setInterval.

Il problema con questo, tuttavia, è che crea uno stack di richieste e quindi, quando la risposta è pronta, ogni elemento nello stack riceverà la stessa risposta.

Questo può avere un impatto drastico su un determinato server. E ci sono modi migliori per farlo.

Lavorare correttamente con le richieste Ajax

Come al solito, poiché WordPress viene fornito con jQuery, lo userò; tuttavia, ti esorto anche, se non l’hai già fatto, a guardare Ajax in ES6 per avere un’idea su come farlo in modo nativo.

Ad ogni modo, l’idea è questa: piuttosto che impostare un intervallo, utilizzare le funzioni Ajax integrate per valutare correttamente la risposta. E solo in determinate condizioni, riattivare la funzione.

Caso in questione: il metodo $.post di jQuery offre alcune funzioni che possono essere utilizzate esattamente per questo. Ad esempio, offre metodi come:

• fatto()
• fallire()
• sempre()

E ognuno di questi è pensato per essere eseguito in determinate condizioni che mostrerò momentaneamente in alcuni esempi di codice.

Prima di farlo, però, è importante capire che ci sono diversi parametri che sto inviando che presumo tu abbia familiarità con:

• l’URL Ajax di WordPress (che definirò acme.ajax_url),
• un URL al post che stiamo visualizzando (che verrà archiviato in una variabile sUrl),
• e un nonce di sicurezza che chiamerò acme.security

Se una delle precedenti non è chiara, si prega di leggere le pagine collegate per vedere come si ottiene ciò.

Ma detto questo, ecco l’idea alla base di come gestire le risposte Ajax ripetute senza setInterval.

1 Una funzione per il lavoro

La prima cosa che devi fare è racchiudere il lavoro che farai nella sua stessa funzione. Ciò significa che puoi chiamarlo da qualsiasi altra parte nell’applicazione lato client o anche nel contesto di un timer (se assolutamente necessario).

Ad esempio :

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() {
      // ..
    });
}

E, come puoi vedere, sono andato avanti e ho cancellato alcune delle funzioni che ho menzionato sopra.

2 Gestisci il successo

In caso di successo, puoi utilizzare una funzione anonima come callback per la funzione $.post. L’argomento principale di cui dovresti preoccuparti è l’ argomento della risposta .

In genere, mi piace che le mie risposte abbiano un attributo di successo e un attributo di errore. Ciò semplifica la gestione di un caso ogni volta che la risposta è completamente riuscita, ma i dati restituiti dal server non erano quelli che mi aspettavo.

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() {
      // ...
    });
}

Questo non significa necessariamente che ci sia stato un fallimento. Significa solo che tutto ciò che stavo cercando di recuperare non è stato trovato.

3 Gestire il fallimento

D’altra parte, ci sono momenti in cui qualcosa può fallire. Il motivo per cui ciò accade può essere dovuto a una serie di motivi e per comprenderlo correttamente, vale la pena esaminare gli argomenti forniti dal callback, vale a dire lo stato e l’ errore.

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() {
      // ...
    });
}

Non posso fornire esempi concreti qui perché ogni API è diversa; tuttavia, consiglio almeno di scrivere i dati sulla console in modo da poter capire cosa sta succedendo e come gestirlo con grazia a livello di codice.

4 Gestire il caso incondizionato

In questo caso particolare, questa funzione si attiverà indipendentemente dal fatto che qualcosa sia andato a buon fine o meno.

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.
    });
}

Questa funzione non è qualcosa di cui potresti aver sempre bisogno (nessun gioco di parole), ma è una solida opzione, ad esempio, per nascondere una barra di avanzamento o visualizzare qualcosa sull’interfaccia utente. Questo può fornire all’utente un po’ di feedback sul fatto che la richiesta ha completato il suo lavoro (di nuovo, indipendentemente dal fallimento o dall’esito positivo).

5 Gestisci il successo, ancora

Infine, il metodo done è molto simile al metodo del successo, ma pensa che sia destinato a essere chiamato una seconda volta.

Ciò significa che dopo che la risposta è tornata dal server con l’ argomento response, la stessa cosa si attiverà di nuovo una volta che tutto il resto è stato completato.

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.
    });
}

Questo ti dà un’altra possibilità di fare tutto ciò che vuoi fare con l’argomento della risposta ancora una volta prima che tutto sia completato.

Lo uso raramente, ma ci sono stati momenti in cui ho voluto rimuovere un elemento solo dopo che qualcosa è stato fatto, tutte le altre elaborazioni sono state eseguite e la risposta ha avuto successo.

Forse non ti serve tutto

Ovviamente, gran parte del codice sopra è solo per una demo su come gestire le richieste. Ma lo scopo è mostrare come gestire tale richiesta senza dover impostare intervalli per impilare le richieste. Invece, si sfruttano le funzioni preesistenti per, ad esempio, chiamare di nuovo la funzione se si verifica un errore.

Ad ogni modo, questo potrebbe essere eccessivo per alcuni, ma per altri che sono abituati a usare setInterval, potrebbe essere un modo molto migliore per gestire le richieste Ajax che non si accumulano e inviare la stessa richiesta al server quando una risposta è già stata gestito.

E in definitiva, questo è l’obiettivo: codice efficiente che recuperi le informazioni di cui abbiamo bisogno senza impantanare l’API di terze parti o il browser del nostro utente.