Tworzenie interfejsu użytkownika ustawień dla niestandardowego bloku WordPress

Do tej pory omówiliśmy, jak pracować z danymi z zewnętrznego interfejsu API w niestandardowym bloku WordPress. Przeszliśmy przez proces pobieranie tych danych do użytku na froncie witryny WordPress i jak to zrobić wyrenderuj go bezpośrednio w edytorze bloków WordPress podczas umieszczania bloku w treści. Tym razem połączymy te dwa artykuły, podłączając się do panelu kontrolnego edytora bloków, aby utworzyć interfejs ustawień dla utworzonego przez nas bloku.

Znasz panel kontrolny, o którym mówię, prawda? To ten panel po prawej zawiera ustawienia postów i bloków w edytorze bloków.

Widzisz ten podświetlony na czerwono obszar? To jest panel kontrolny. Aktualnie zaznaczony jest blok akapitu, a jego ustawienia są wyświetlane w panelu. Możemy zmieniać style, kolory, typografię… wiele rzeczy!

Cóż, dokładnie to robimy tym razem. Zamierzamy stworzyć elementy sterujące dla ustawień bloku rankingów piłkarskich, nad którymi pracowaliśmy w dwóch ostatnich artykułach. Ostatnim razem stworzyliśmy przycisk w naszym bloku, który pobiera zewnętrzne dane do rankingów piłkarskich. Znaliśmy już adres URL i punkty końcowe, których potrzebowaliśmy. Ale co, jeśli chcemy pobrać ranking dla innego kraju? A może inna liga? A co z danymi z innego sezonu?

Potrzebujemy do tego kontrolek formularza. Moglibyśmy skorzystać z interaktywnych komponentów React — takich jak Reaguj-Wybierz — aby przeglądać różne opcje API, które są dostępne do analizowania tych danych. Ale nie ma takiej potrzeby, ponieważ WordPress jest dostarczany z wieloma podstawowymi komponentami, które od razu podłączamy!

Połączenia dokumentacja dla tych składników — tzw InspectorControls - coraz lepiej w Podręcznik edytora bloków WordPress. Z czasem będzie jeszcze lepiej, ale w międzyczasie mamy też WordPress Bajka Gutenberga i Komponenty WordPress Gutenberg strony z dodatkową pomocą.

Architektura API

Zanim się do czegokolwiek podłączymy, dobrze jest najpierw ustalić, czego potrzebujemy. Zmapowałem strukturę danych RapidAPI, które pobieramy, więc wiemy, co jest dla nas dostępne:

Sezony i kraje to dwa punkty końcowe najwyższego poziomu, które są mapowane na punkt końcowy lig. Stamtąd mamy resztę danych, których już używamy do wypełnienia tabeli rankingowej. Tak więc chcemy utworzyć ustawienia w edytorze bloków WordPress, które filtrują dane według sezonu, kraju i ligi, a następnie przekazują przefiltrowane dane do tabeli rankingowej. Daje nam to możliwość upuszczenia bloku na dowolnej stronie WordPress lub poście i wyświetlenia odmian danych w bloku.

Aby zdobyć rankingi, musimy najpierw zdobyć ligi. Aby zdobyć ligi, najpierw musimy zdobyć kraje i/lub pory roku. Możesz przeglądać różne punkty końcowe w dashboardzie RapidAPI.

Istnieją różne kombinacje danych, których możemy użyć do wypełnienia rankingów, i możesz mieć preferencje co do danych, które chcesz. Na potrzeby tego artykułu stworzymy następujące opcje w panelu ustawień bloku:

• Wybierz kraj
• Wybierz Ligę
• Wybierz sezon

Następnie będziemy mieli przycisk do przesłania tych wyborów i pobrania odpowiednich danych oraz przekazania ich do tabeli rankingowej.

Załaduj i zapisz listę krajów

Nie możemy wybrać kraju, dla którego chcemy uzyskać dane, jeśli nie mamy listy krajów do wyboru. Tak więc naszym pierwszym zadaniem jest pobranie listy krajów z RapidAPI.

Idealną rzeczą jest pobranie listy krajów, gdy blok jest faktycznie używany w treści strony lub postu. Nie ma potrzeby pobierania czegokolwiek, jeśli blok nie jest używany. Podejście jest bardzo podobne do tego, co zrobiliśmy w pierwszy artykuł, z tą różnicą, że używamy innego punktu końcowego API i innych atrybutów do przechowywania listy zwróconych krajów. Istnieją inne sposoby pobierania danych WordPress, takie jak pobieranie interfejsu API, ale to wykracza poza zakres naszych działań.

Możemy albo dołączyć listę krajów ręcznie po skopiowaniu jej z danych API, albo możemy użyć oddzielnego API lub biblioteki do wypełnienia krajów. Ale interfejs API, którego używamy, ma już listę krajów, więc użyłbym tylko jednego z jego punktów końcowych. Upewnijmy się, że początkowa lista krajów ładuje się po wstawieniu bloku na stronę lub opublikowaniu treści w edytorze bloków:

// edit.js
const [countriesList, setCountriesList] = useState(null);

useEffect(() => {
  let countryOptions = {
    method: "GET",
    headers: {
      "X-RapidAPI-Key": "Your Rapid API key",
      "X-RapidAPI-Host": "api-football-v1.p.rapidapi.com",
    },
  };
  fetch("https://api-football-v1.p.rapidapi.com/v3/countries", countryOptions)
    .then( (response) => response.json() )
    .then( (response) => {
      let countriesArray = { ...response };
      console.log("Countries list", countriesArray.response);
      setCountriesList(countriesArray.response);
    })
  .catch((err) => console.error(err));
}, []);

Mamy zmienną stanu do przechowywania listy krajów. Następnie zaimportujemy komponent z pliku @wordpress/edytor bloków pakiet o nazwie InspectorControls gdzie znajdują się wszystkie komponenty potrzebne do utworzenia kontrolek ustawień.

import { InspectorControls } from "@wordpress/block-editor";

Paczka GitHub repo dobrze tłumaczy InspectorControls. W naszym przykładzie możemy go użyć do kontrolowania ustawień danych API, takich jak Kraj, Liga i Sezon. Oto podgląd, abyście mogli zorientować się, jaki interfejs tworzymy:

A kiedy te wybory zostaną dokonane w ustawieniach bloku, użyjemy ich w bloku Edit funkcjonować:

  { countriesList && (
    
  )}

Tutaj upewniam się, że używamy renderowania warunkowego, aby funkcja ładowała tylko komponent po ładuje się lista krajów. Jeśli się nad tym zastanawiasz LeagueSettings komponent, jest to niestandardowy komponent, który utworzyłem w oddzielnym pliku components podfolder w bloku, dzięki czemu możemy mieć czystszy i bardziej zorganizowany Edit zamiast setek wierszy danych krajów w jednym pliku.

Możemy zaimportować go do edit.js plik taki jak ten:

import { LeagueSettings } from "./components/LeagueSettings";

Następnie przekazujemy wymagane rekwizyty do LeagueSettings składnik od rodzica Edit komponent, abyśmy mogli uzyskać dostęp do zmiennych stanu i atrybutów z pliku LeagueSettings komponent potomny. Możemy to zrobić również innymi metodami, np Kontekstowe API aby uniknąć wierceń podporowych, ale to, co mamy teraz, doskonale pasuje do tego, co robimy.

Pozostałe części Edit funkcję można również przekształcić w komponenty. Na przykład kod tabeli ligowej można umieścić w oddzielnym komponencie — na przykład LeagueTable.js — a następnie importowane, tak jak importowaliśmy LeagueSettings do Edit funkcja.

Wewnątrz LeagueSettings.js filet

LeagueSettings jest taki sam jak inny Składnik reakcji z którego możemy zniszczyć rekwizyty z komponentu nadrzędnego. Zamierzam użyć trzech zmiennych stanu i dodatkowej leagueID state, ponieważ zamierzamy wyodrębnić identyfikator z pliku league obiekt:

const [country, setCountry] = useState(null);
const [league, setLeague] = useState(null);
const [season, setSeason] = useState(null);
const [leagueID, setLeagueID] = useState(null);

Pierwszą rzeczą, którą zrobimy, jest zaimportowanie pliku PanelBody komponent z pakietu @wordpress/block-editor:

import { PanelBody } from "@wordpress/block-editor";

…i włącz go do naszego return funkcjonować:

Tam są inne znaczniki i atrybuty panelu — to tylko moje osobiste preferencje dotyczące korzystania z tych. Żadne inne nie są wymagane… ale spójrz na wszystkie komponenty mamy do dyspozycji panel ustawień! Podoba mi się prostota tzw PanelBody dla naszego przypadku użycia. Rozwija się i zwija, aby odsłonić rozwijane ustawienia bloku i to wszystko.

Mówiąc o tym, mamy wybór do dokonania tych wyborów. Moglibyśmy skorzystać z SelectControl składnik lub a ComboBoxControl, który dokumentacja opisuje jako „ulepszoną wersję a SelectControl, z dodatkiem możliwości wyszukiwania opcji przy użyciu danych wejściowych wyszukiwania”. To dla nas miłe, ponieważ lista krajów może być dość długa, a użytkownicy będą mogli albo przeprowadzić wyszukiwanie, albo wybrać z listy.

Oto przykład, jak a ComboboxControl może pracować dla naszej listy krajów:

 handleCountryChange(value) }
  onInputChange={ (inputValue) => {
    setFilteredCountryOptions(
      setupCountrySelect.filter((option) =>
        option.label
          .toLowerCase()
          .startsWith(inputValue.toLowerCase())
      )
    );
  }}
/>

Połączenia ComboboxControl jest konfigurowalny w tym sensie, że możemy zastosować różne rozmiary etykiety i wartości kontrolki:

{
  value: 'small',
  label: 'Small',
},

Ale nasze dane API nie są w tej składni, więc możemy przekonwertować countriesList tablica, która pochodzi z komponentu nadrzędnego, gdy blok jest uwzględniony:

let setupCountrySelect;

setupCountrySelect = countriesList.map((country) => {
  return {
    label: country.name,
    value: country.name,
  };
});

Po wybraniu kraju z ComboboxControl, zmienia się wartość kraju i odpowiednio filtrujemy dane:

function handleCountryChange(value) {
  // Set state of the country 
  setCountry(value); 

  // League code from RapidAPI
  const options = {
    method: "GET",
    headers: {
      "X-RapidAPI-Key": "Your RapidAPI key",
      "X-RapidAPI-Host": "api-football-v1.p.rapidapi.com",
    },
  };

  fetch(`https://api-football-v1.p.rapidapi.com/v3/leagues?country=${value}`, options)
    .then((response) => response.json())
    .then((response) => {
      return response.response;
    })
    .then((leagueOptions) => {
      // Set state of the league variable
      setLeague(leagueOptions);

      // Convert it as we did for Country options
      setupLeagueSelect = leagueOptions.map((league) => {
        return {
          label: league.league.name,
          value: league.league.name,
        };
      });
      setFilteredLeagueOptions(setupLeagueSelect);
    })
  .catch((err) => console.error(err));
}

Zauważ, że używam kolejnych trzech zmiennych stanu do obsługi zmian, gdy zmienia się wybór kraju:

const [filteredCountryOptions, setFilteredCountryOptions] = useState(setupCountrySelect);
const [filteredLeagueOptions, setFilteredLeagueOptions] = useState(null);
const [filteredSeasonOptions, setFilteredSeasonOptions] = useState(null);

A co z innymi opcjami ustawień?

Pokażę kod, którego użyłem do innych ustawień, ale wszystko, co robi, to uwzględnianie normalnych przypadków podczas definiowania błędów dla przypadków specjalnych. Na przykład w niektórych krajach i ligach wystąpią błędy, ponieważ:

• nie ma klasyfikacji dla niektórych lig i
• niektóre ligi mają tabele, ale nie znajdują się w jednej tabeli.

To nie jest samouczek JavaScript ani React, więc pozwolę ci zająć się specjalnymi przypadkami interfejsu API, którego planujesz użyć:

function handleLeagueChange(value) {
  setLeague(value);
  if (league) {
    const selectedLeague = league.filter((el) => {
      if (el.league.name === value) {
        return el;
      }
    });

    if (selectedLeague) {
      setLeague(selectedLeague[0].league.name);
      setLeagueID(selectedLeague[0].league.id);
      setupSeasonSelect = selectedLeague[0].seasons.map((season) => {
        return {
          label: season.year,
          value: season.year,
        };
      });
      setFilteredSeasonOptions(setupSeasonSelect);
    }
  } else {
    return;
  }
}

function handleSeasonChange(value) {
  setSeason(value);
}

Przesyłanie wybranych ustawień

W ostatni artykuł, stworzyliśmy przycisk w edytorze bloków, który pobiera świeże dane z API. Teraz, gdy mamy ustawienia, nie jest to już potrzebne. Cóż, potrzebujemy go - po prostu nie tam, gdzie jest obecnie. Zamiast umieszczać go bezpośrednio w bloku renderowanym w edytorze bloków, przeniesiemy go do naszego PanelBody komponent, aby przesłać wybrane ustawienia.

Więc z powrotem LeagueSettings.js:

// When countriesList is loaded, show the country combo box
{ countriesList && (
   handleCountryChange(value)}
    onInputChange={(inputValue) => {
      setFilteredCountryOptions(
        setupCountrySelect.filter((option) =>
          option.label
            .toLowerCase()
            .startsWith(inputValue.toLowerCase())
        )
      );
    }}
  />
)}

// When filteredLeagueOptions is set through handleCountryChange, show league combobox
{ filteredLeagueOptions && (
   handleLeagueChange(value)}
    onInputChange={(inputValue) => {
      setFilteredLeagueOptions(
        setupLeagueSelect.filter((option) =>
          option.label
            .toLowerCase()
            .startsWith(inputValue.toLowerCase())
        )
      );
    }}
  />
)}

// When filteredSeasonOptions is set through handleLeagueChange, show season combobox
{ filteredSeasonOptions && (
  
     handleSeasonChange(value)}
      onInputChange={
          (inputValue) => {
            setFilteredSeasonOptions(
              setupSeasonSelect.filter((option) =>
              option.label
              .toLowerCase()
              .startsWith(inputValue.toLowerCase()
            )
          );
        }
      }
    />

    // When season is set through handleSeasonChange, show the "Fetch data" button
    {
      season && (
         getData()}>Fetch data
      )
    }
    
  
)}

Oto wynik!

Jesteśmy w bardzo dobrym miejscu z naszym blokiem. Możemy wyrenderować go w edytorze bloków i na froncie strony. Możemy pobierać dane z zewnętrznego interfejsu API na podstawie wybranych przez nas ustawień, które filtrują dane. Jest cholernie funkcjonalny!

Ale jest jeszcze jedna rzecz, z którą musimy się uporać. W tej chwili, kiedy zapisujemy stronę lub post zawierający blok, ustawienia, które wybraliśmy do resetowania bloku. Innymi słowy, te wybory nie są nigdzie zapisywane. Jest trochę więcej pracy, aby te wybory były trwałe. Właśnie tam planujemy udać się w następnym artykule, więc bądźcie czujni.