Prawidłowa praca z żądaniami Ajax w WordPress

Za każdym razem, gdy pracujesz z interfejsami API innych firm i robisz to w sposób asynchroniczny, zawsze istnieje szansa, że ​​niezależnie od tego, o co prosisz, zwróci niepożądany wynik.

Być może jest to kod błędu, może to ostrzeżenie, a może jest to prosta wiadomość o treści typu „Nadal przetwarzamy Twoje żądanie po naszej stronie".

W każdym przypadku zwykle możesz sobie z nimi poradzić po stronie serwera i dać znać stronie klienta, jak sobie z tym poradzić. Ale jeśli masz do czynienia z tym drugim przypadkiem, jest to miejsce, w którym jesteś blokowany przez przetwarzanie przez stronę trzecią; są inne rzeczy, które możesz zrobić, aby lepiej poradzić sobie z tą sytuacją.

Na przykład w tym drugim przypadku lepiej poczekać chwilę, a następnie ponownie wykonać żądanie, aby sprawdzić, czy interfejs API ma dla Ciebie inną odpowiedź.

Ale kiedy to robi, wymaga Ajax, który oczywiście wymaga JavaScript. Jedną z oczywistych, ale bardziej przestarzałych metod jest użycie setInterval.

Problem polega jednak na tym, że tworzy on stos żądań, a następnie, gdy odpowiedź jest gotowa, każdy element stosu otrzyma tę samą odpowiedź.

Może to drastycznie wpłynąć na dowolny serwer. I są na to lepsze sposoby.

Prawidłowa praca z żądaniami Ajax

Jak zwykle, ponieważ WordPress jest dostarczany z jQuery, będę go używał; jednak zachęcam również – jeśli jeszcze tego nie zrobiłeś – do spojrzenia na Ajax w ES6, aby dowiedzieć się, jak to zrobić natywnie.

W każdym razie pomysł jest taki: zamiast ustawiać jakiś interwał, użyj wbudowanych funkcji Ajax, aby właściwie ocenić odpowiedź. I tylko w określonych warunkach ponownie uruchom funkcję.

Przykład: metoda $.post jQuery oferuje kilka funkcji, których można użyć właśnie do tego. Na przykład oferuje metody takie jak:

• Gotowe()
• ponieść porażkę()
• zawsze()

I każdy z nich ma być uruchamiany w określonych warunkach, które za chwilę pokażę w niektórych przykładach kodu.

Jednak zanim to zrobisz, ważne jest, aby zrozumieć, że wysyłam kilka parametrów, które, jak zakładam, znasz:

• URL WordPress Ajax (który zdefiniuję jako acme.ajax_url),
• adres URL do oglądanego posta (który będzie przechowywany w zmiennej sUrl),
• i numer bezpieczeństwa, który będę nazywał acme.security

Jeśli którakolwiek z powyższych nie jest jasna, przeczytaj powiązane strony, aby zobaczyć, jak to osiągnąć.

Ale biorąc to pod uwagę, oto pomysł, jak możesz zarządzać powtarzającymi się odpowiedziami Ajax bez setInterval.

1 Funkcja dla pracy

Pierwszą rzeczą, którą musisz zrobić, to otoczyć pracę, którą zamierzasz wykonać, we własnej funkcji. Oznacza to, że możesz wywołać go z dowolnego miejsca w aplikacji po stronie klienta lub nawet w kontekście timera (jeśli jest to absolutnie konieczne).

Na przykład :

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

Jak widać, posunąłem się do przodu i odciąłem niektóre funkcje, o których wspomniałem powyżej.

2 Zajmij się sukcesem

W przypadku sukcesu możesz użyć funkcji anonimowej jako wywołania zwrotnego dla funkcji $.post. Podstawowym argumentem, którym powinieneś się zajmować, jest argument odpowiedzi .

Zazwyczaj lubię, gdy moja odpowiedź ma atrybut sukcesu i atrybut niepowodzenia. Ułatwia to załatwienie sprawy, gdy odpowiedź całkowicie się powiodła, ale dane, które wróciły z serwera, nie były takie, jakich się spodziewałem.

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

Niekoniecznie oznacza to, że nastąpiła awaria. To po prostu oznacza, że ​​to, czego szukałem, nie zostało znalezione.

3 Zajmij się niepowodzeniem

Z drugiej strony zdarzają się chwile, w których coś może zawieść. Dlaczego tak się dzieje może być z wielu powodów i aby to właściwie zrozumieć, warto przyjrzeć się argumentom, jakie dostarcza callback, a mianowicie statusowi i błędowi.

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

Nie mogę podać tutaj konkretnych przykładów, ponieważ każde API jest inne; jednak zalecam przynajmniej wypisanie danych do konsoli, abyś mógł zrozumieć, co się dzieje i jak z wdziękiem sobie z tym poradzić na poziomie kodu.

4 Postępuj w przypadku bezwarunkowego

W tym konkretnym przypadku ta funkcja uruchomi się niezależnie od tego, czy coś się powiodło, czy nie.

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

Ta funkcja nie jest czymś, czego zawsze możesz potrzebować (gra słów nie jest przeznaczona), ale jest to solidna opcja do, powiedzmy, ukrywania paska postępu lub wyświetlania czegoś w interfejsie użytkownika. Może to dać użytkownikowi pewną informację zwrotną, że żądanie zakończyło swoją pracę (ponownie, niezależnie od niepowodzenia lub sukcesu).

5 Ponownie zajmij się sukcesem

Wreszcie, metoda wykonania jest bardzo podobna do metody sukcesu, ale pomyśl o niej jako o tym, że należy ją wywołać po raz drugi.

Oznacza to, że po otrzymaniu odpowiedzi z serwera z argumentem odpowiedzi, ta sama rzecz zostanie uruchomiona ponownie, gdy wszystko inne zostanie zakończone.

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

Daje ci to kolejną szansę na zrobienie wszystkiego, co chcesz zrobić z argumentem odpowiedzi jeszcze raz, zanim wszystko się zakończy.

Rzadko tego używam, ale zdarzało się, że chciałem usunąć element dopiero po tym, jak coś zostało zrobione, wszystkie inne operacje zostały wykonane i odpowiedź się powiodła.

Może nie potrzebujesz tego wszystkiego

Oczywiście większość powyższego kodu jest przeznaczona tylko do demonstracji obsługi żądań. Ale celem jest pokazanie, jak obsłużyć wspomniane żądanie bez konieczności ustawiania interwałów dla żądań stosowych. Zamiast tego korzystasz z istniejących wcześniej funkcji, aby, powiedzmy, ponownie wywołać funkcję, jeśli wystąpi błąd.

W każdym razie dla niektórych może to być przesada, ale dla innych, którzy są przyzwyczajeni do używania setInterval, może to być znacznie lepszy sposób na zarządzanie żądaniami Ajax, które nie nakładają się na stos i uruchamiają to samo żądanie do serwera, gdy odpowiedź już została zarządzany.

I ostatecznie to jest cel: Wydajny kod, który pobiera potrzebne informacje bez blokowania interfejsu API innej firmy lub przeglądarki naszego użytkownika.