DE{CODE}: Gutenberg i bezgłowy WordPress

Gutenberg, znany również jako bloki WordPress, zapewnia producentom treści nowe, potężne sposoby układania treści w tradycyjnej witrynie WordPress. Ale w jaki sposób bezgłowy programiści WordPress mogą zapewnić zespołom marketingowym te same możliwości? W tej sesji DE{CODE}, założyciel GraphQL dla WordPress (WPGraphQL), Jason Bahl, dzieli się nowymi możliwościami i najlepszymi praktykami dotyczącymi korzystania z edytora bloków WordPress w witrynie bezgłowej.

Slajdy sesji

Transkrypcja pełnego tekstu

JASON BAHL : Cześć. Witam w moim wykładzie na temat Gutenberga i Headless WordPress. Nazywam się Jason Bahl. Jestem twórcą i opiekunem WPGraphQL. Jestem głównym inżynierem oprogramowania w WP Engine. Możesz mnie znaleźć na Twitterze @jasonbahl lub też na Twitterze @wpgraphql.

Więc dzisiaj chcę z tobą porozmawiać o tym, czym w ogóle jest Gutenberg, bezgłowy WordPress, kiedy i dlaczego możesz chcieć używać Bezgłowego WordPressa, jak możesz używać Gutenberga, w szczególności z Bezgłowym WordPressem, oraz kiedy i dlaczego Bezgłowy WordPress i Gutenberg razem może mieć sens dla Twoich projektów.

Więc WordPress historycznie miał edytor, który wyglądał trochę tak. Mieliśmy obszar tekstowy TinyMCE, w którym możemy edytować nasze treści. Możemy wstawiać media, a następnie publikować nasze treści, a potem w 2018 roku pojawił się Gutenberg, edytor blokowy, który pozwala nam wstawiać treści do tego pustego płótna i wchodzić w interakcje z naszymi treściami na poziomie bloków.

Więc każdy akapit ma ustawienia. Każdy obraz ma ustawienia. Każda galeria, nagłówek — wszystko, co możesz wymyślić jako treść, nazywa się blokiem. Możemy teraz uzyskać naprawdę szczegółowy sposób kontrolowania naszych treści, możemy je przeciągać i upuszczać oraz komponować nasze treści. Więc teraz jest to bardzo bogate doświadczenie w edycji w WordPress, więc jest to elementarz tego, czym jest Gutenberg.

Więc czym jest teraz Headless WordPress? Aby zrozumieć Headless, spójrzmy na tradycyjny WordPress. Tak więc tradycyjny WordPress, logujemy się do WordPress, interfejsu administratora, i publikujemy naszą treść, a następnie użytkownicy odwiedzają naszą witrynę, a PHP, język wbudowany w WordPress, renderuje stronę. Ładuje więc CSS, HTML i JavaScript i dostarcza stronę użytkownikowi. To rodzaj tradycyjnego WordPressa.

Dzięki Headless WordPress nadal używasz WordPressa jako CMS. Nadal publikujesz treści, zarządzasz treściami, administrujesz treścią w WordPressie, ale zamiast dostarczać stronę w HTML do przeglądarki, WordPress dostarcza dane zazwyczaj w formacie JSON, a następnie aplikacje klienckie mogą konsumować te dane, abyśmy mogli mieć natywne aplikacje na iOS lub Androida a nawet aplikacji wirtualnej rzeczywistości.

Mój kolega, Anthony, podzielił się treścią o tym, jak używa WordPressa do obsługi aplikacji rzeczywistości wirtualnej. Albo pracowałem w gazecie, w której używaliśmy WordPressa jako punktu wejścia dla naszych gazet drukowanych. Więc jeśli czytałeś papierową wersję drukowanej gazety, czytałeś treść stworzoną w WordPress.

I oczywiście nadal możemy używać tych danych do renderowania w sieci, ale zamiast ograniczać się do szablonów PHP, mamy swobodę wyboru dowolnej technologii front-endowej. Tak więc Headless oddziela zaplecze, zarządzanie treścią i sposób prezentacji danych zarządzanych w WordPress.

Są więc dwa popularne sposoby wykorzystania tych danych. Możemy uzyskać dane w formacie JSON z WP REST API, które jest wbudowanym API do WordPressa i jest jeszcze inne API o nazwie WPGraphQL. Jest to wtyczka typu open source, którą można zainstalować i pobierać dane z WordPress i JSON. A dzisiaj będziemy mówić o WPGraphQL.

Więc teraz, gdy wiemy, czym jest WordPress, dlaczego miałbyś iść i tworzyć projekty Headless WordPress? Jak wspomniałem, masz dużą elastyczność w wyborze technologii front-end. A dla niektórych osób bardzo ważna jest możliwość wyboru sposobu budowania projektów front-endowych. Istnieje kilka frameworków, takich jak Next, Gatsby i Svelte, które naprawdę celują w ulepszone podstawowe parametry internetowe. Więc możesz być w stanie przejść bez głowy z WordPress i ulepszyć podstawowe wskaźniki internetowe.

Możesz skorzystać z rzeczy takich jak dzielenie kodu w swoim kodzie. Możesz więc budować komponenty dla aplikacji front-end. A w oparciu o to, który komponent jest budowany dla konkretnej strony, wyśle ​​klientowi mniej lub mniej zasobów i przyspieszy Twoje strony. Headless daje również programistom dokładniejszą kontrolę nad interfejsem użytkownika, więc wtyczki zainstalowane w panelu administracyjnym WordPress mają mniejszy wpływ na interfejs użytkownika

Dlatego administratorzy nie mogą po prostu instalować wtyczek i dodawać dowolnych skryptów lub dowolnych znaczników do interfejsu witryny Headless. Bardziej chodzi o to, że programista definiuje ograniczenia na froncie, a WordPress otrzymuje przesyłane dane, a następnie jedną z rzeczy, które chcę wprowadzić, jest doświadczenie programisty.

Dzięki Headless WordPress, ponieważ masz swobodę korzystania z dowolnego stosu technologicznego, jaki chcesz, w niektórych przypadkach korzyścią jest lepsze doświadczenie programisty. I jeden z tych przypadków, którym się zajmę, nazywa się rozwojem opartym na komponentach i dużo o tym porozmawiamy za sekundę.

Więc to jest kilka powodów. W jakich sytuacjach możesz się znaleźć, gdy chcesz korzystać z Headless WordPress? Cóż, jeśli musisz tworzyć aplikacje inne niż internetowe, takie jak natywne aplikacje mobilne, prawdopodobnie chcesz przejść do Headless. Ponownie, jeśli Twoje podstawowe wskaźniki internetowe są słabe w Twojej witrynie WordPress, bieżącej witrynie WordPress lub są w porządku, ale utrzymanie ich w dobrym stanie staje się bardzo kosztowne, możesz rozważyć Headless.

Jeśli masz wiele aplikacji w swojej organizacji, które muszą pobierać dane z WordPressa, być może będziesz musiał przejść na Headless. A jeśli już zainwestowałeś w bibliotekę komponentów lub system projektowania oparty na komponentach dla swojej organizacji i potrzebujesz danych z WordPress, możesz zainwestować w przejście na Headless. Jeśli zespół preferuje JavaScript i nie lubi budować rzeczy w PHP, to również jest powód do rozważenia Headless.

Istnieją jednak powody, dla których możesz nie chcieć przejść na Headless – obecnie zajmuje to trochę więcej czasu na opracowanie. Więc jeśli masz niższy budżet lub ograniczasz czas i masz już rozwiązania w tradycyjnym WordPressie, możesz jeszcze nie przejść na Headless. Jeśli administratorzy Twojej witryny naprawdę potrzebują kontroli nad instalowaniem wtyczek, które modyfikują front-end, możesz jeszcze nie przejść na Headless.

Jeśli Twój zespół naprawdę preferuje PHP i nie chce uczyć się JavaScript ani alternatywnych interfejsów, możesz również pozostać przy tradycyjnym WordPressie. A jeśli nie inwestujesz w programowanie oparte na komponentach lub bibliotekę opartą na komponentach, jeśli nie jesteś tym zainteresowany, możesz trzymać się tradycyjnych przepływów pracy programistycznych WordPress.

A jeśli Twoje podstawowe parametry sieciowe w tradycyjnym WordPressie są naprawdę dobre, a koszty utrzymania są bardzo niskie, aby Twoja witryna działała bardzo szybko, możesz pozostać przy tradycyjnym WordPressie. Więc nie musisz iść bez głowy. Ale pokażę ci, dlaczego uważam, że gra Headless może być dobra dla niektórych drużyn.

Jeśli więc ponownie spojrzymy na doświadczenia programistów WordPress, publikujemy nasze treści w jednym polu, które generuje duży fragment kodu HTML. I nawet jeśli używamy edytora Gutenberga, który ma te szczegółowe bloki, efektem końcowym jest jeden duży fragment kodu HTML. Niezależnie od tego, czy publikujemy w Gutenbergu, czy w tradycyjnym klasycznym edytorze, ten fragment HTML jest wysyłany przez PHP do naszego motywu i mamy jedną globalną stronę, która ładuje nasz HTML, nasz CSS i nasz JavaScript. Te zasoby są stosowane na stronie globalnie.

Tak więc programiści WordPress zwykle oddzielają nasz rozwój w oparciu o typy plików, więc umieszczamy nasz CSS w oddzielnych plikach, które są stosowane globalnie na stronie, lub HTML zostanie napisany w PHP i pobierze potrzebne dane z WordPress, a następnie JavaScript być często zapisywane w jQuery w osobnych plikach. I tak te trzy rzeczy połączą się, aby zbudować stronę.

Problem polega na tym, że nie są one izolowane, są stosowane do całej strony. Więc czasami możesz coś zmienić. Tak jak to mi się przydarzyło. Pewnego razu dokonałem zmiany stylu w stopce witryny zgodnie z prośbą mojego kierownika, a trzy dni później zgłoszono, że styl w innym miejscu witryny zmienił się z powodu tej weryfikacji kodu dostępu. Minęliśmy to.

Nagle coś innego w witrynie uległo awarii, a to dlatego, że CSS jest stosowany globalnie i może mieć wpływ na rzeczy, z których nie zdajesz sobie sprawy. Jednak w przeszłości pojawił się nowy trend – nie wiem – siedem, osiem lat można nazwać architekturą opartą na komponentach. To pozwala nam budować określone elementy naszej aplikacji w tak zwanych komponentach.

I możemy połączyć nasz JavaScript, nasz HTML, nasz CSS w małe bity, które możemy przetestować w izolacji, abyśmy mogli zbudować fragmenty naszej aplikacji. Kilka problemów, znaczniki, skrypty JavaScript, style i możemy skomponować te komponenty razem, aby zbudować bardziej złożone aplikacje.

Tak więc programowanie oparte na komponentach pozwala nam rozbijać złożone funkcje na mniejsze, pojedyncze elementy i możemy je testować w izolacji, upewniając się, że działają, a następnie możemy połączyć nasze obawy, które powinny zostać połączone. Każdy wycinek interfejsu użytkownika ma określoną odpowiedzialność. Jeśli jest to karta graficzna, może być odpowiedzialna za renderowanie obrazu w określonym rozmiarze z określonym adresem URL.

Ma więc zależności znaczników. Ma zależności stylu. Może mieć interakcje stanowe. Wszystkie dotyczą tego konkretnego komponentu. Możemy więc połączyć nasze znaczniki, JavaScript i CSS w jednym miejscu, przetestować je i upewnić się, że działają dobrze. Dzięki temu możemy ponownie wykorzystać te komponenty w całej naszej aplikacji, a nawet możemy ponownie wykorzystać nasze komponenty w różnych projektach.

Istnieje więc trend zwany bibliotekami komponentów. Istnieją projekty takie jak Material UI lub komponenty projektu końcowego, a także popularny jest interfejs Chakra. I możemy używać tych komponentów w różnych projektach. I możemy rozwiązać główne problemy, takie jak dostępne znaczniki. Możemy je aktualizować i stosować jednocześnie w wielu projektach w naszej organizacji, dzięki czemu możemy szybciej iterować i dostarczać produkty z większą pewnością siebie.

Jak więc możemy używać Headless WordPress? Jak wspomniałem wcześniej, istnieją dwa sposoby na pobieranie danych z WordPressa i umieszczanie ich w komponentach. Jednym z nich byłby REST API. Jednym z nich byłby WPGraphQL. Mój przyjaciel, Drake, od jakiegoś czasu buduje witryny Headless, więc zapytałem go i oto, co powiedział…

Preferuje WPGraphQL. Więc o tym dzisiaj porozmawiamy. Czym więc jest WPGraphQL? Możesz zapytać. Cóż, jest to bezpłatna wtyczka WordPress typu open source, która zapewnia rozszerzalny schemat GraphQL i interfejs API dla dowolnej witryny WordPress. Czym w takim razie jest GraphQL? Cóż, jest to język zapytań graficznych.

W porządku, Jasonie. Nadal nie rozumiem, co mówisz. W porządku, więc pozwól, że ci pokażę. Tak więc GraphQL działa tak, że aplikacje klienckie wysyłają żądanie określające, czego chcą od serwera. A prośba wygląda mniej więcej tak. Wygląda jak klucze JSON bez wartości. Tak więc w tym przypadku żądanie dotyczy widza, a na widzu chcemy, aby pole „nazwa” zostało zwrócone.

A odpowiedź z serwera GraphQL może wyglądać tak. Jego rzeczywiste dane JSON, klucze i wartości i pasują do kształtu żądania. Więc w tym przypadku otrzymujemy imię lub widza o imieniu Jason Bahl. Więc GraphQL pozwala aplikacjom klienckim wyrywać drzewa z grafu danych aplikacji.

A jak to wygląda wizualnie, to mniej więcej tak. Możemy wejść do wykresu, powiedzmy, dodać pole przeglądarki lub użytkownika lub węzeł. I ten węzeł może mieć właściwość taką jak imię Jason. I ten węzeł może mieć połączenia z innymi węzłami na wykresie, jak awatar, który może mieć właściwość taką jak adres URL obrazu.

I ten użytkownik może mieć połączenia z innymi węzłami, takimi jak post, którego autorem jest ten użytkownik. A te posty mogą same mieć właściwości, takie jak tytuł, witaj świecie lub żegnaj Marsie. Te posty mogą mieć połączenia z innymi węzłami na wykresie, takimi jak kategorie z własnymi tytułami, takie jak wiadomości lub sport. A te kategorie mogą mieć połączenia z innymi węzłami, a także więcej postów. A te posty mogły zawierać obrazy i tak dalej, i tak dalej. Mamy więc ten duży wykres danych, o który możemy poprosić GraphQL.

I tak możemy użyć narzędzi w adminie GraphQL lub w adminie WordPressa. Istnieje narzędzie o nazwie GraphiQL, w którym mogę utworzyć zapytanie. I tutaj wybieram pole Przeglądarka z podselekcjami, nazwą, awatarem, adresem URL, a kiedy to wykonamy, otrzymamy pola, o które prosimy, więc wizualnie to zapytanie wygląda trochę tak.

Weszliśmy w wykres i poprosiliśmy o jednego użytkownika. Poprosiliśmy o nazwę użytkownika, połączonego awatara w adresie URL awatara. Mamy do dyspozycji cały ten wykres danych, ale prosimy tylko o określony zestaw danych, aw odpowiedzi otrzymaliśmy ten konkretny zestaw z powrotem. A więc możemy wziąć – możemy teraz używać komponentów.

Mówiłem więc o korzyściach płynących z programowania opartego na komponentach i chcę pokazać to w działaniu. I to jest to, co nazwałbym komponentem prezentacyjnym. Jest to więc element karty, który jest odpowiedzialny. Ma jedną odpowiedzialność za renderowanie tej karty z obrazem i tytułem.

Możemy spojrzeć na kod i zobaczyć, że mamy pewną kontrolę nad stylem. Możemy ustawić szerokość, możemy przekazać mu żądany obraz i możemy przekazać mu tytuł. Dzięki temu możemy ponownie wykorzystać ten komponent w całym naszym projekcie. I ten komponent ma wszystkie zależności, których potrzebujemy. Ma kod HTML do renderowania. Ma style. Mamy tutaj pewną kontrolę nad stylem. Ma pewne komponenty stanowe, takie jak stan zawisu i tak dalej.

Jest to więc izolowany komponent, który możemy ponownie wykorzystać, a teraz dzięki GraphQL możemy wziąć zapytanie, które właśnie utworzyliśmy w panelu administracyjnym WordPress za pomocą GraphQL, i możemy je wprowadzić i mieć teraz komponent karty przeglądarki. Możemy więc napisać nasze zapytanie, połączyć je z naszym komponentem karty, a teraz uzupełnia komponent.

Mamy swój HTML, CSS nasz JavaScript. A dzięki danym mamy teraz coś do renderowania z danymi, o które prosiliśmy. Więc teraz możemy używać tego w całej naszej aplikacji i istnieje funkcja GraphQL zwana fragmentami, która pozwala nam wziąć nasze zapytania GraphQL i podzielić je na części wielokrotnego użytku.

W tym przypadku tworzę fragment karty profilu użytkownika i określam nazwę, awatar i adres URL, a następnie używam tego fragmentu w większym zapytaniu. Wykonując, uzyskujemy oczekiwane rezultaty. Możemy teraz wziąć ten fragment i umieścić go w komponencie. Teraz mamy inny komponent zwany kartą profilu użytkownika.

Ta karta profilu użytkownika określa, że ​​za każdym razem, gdy wysyłamy zapytanie do użytkownika, powinniśmy uzyskać nazwę, awatar i adres URL awatara do użycia w komponencie. Więc teraz mamy ten komponent wielokrotnego użytku, że gdziekolwiek w naszej aplikacji poprosimy o użytkownika, możemy uzyskać dane niezbędne do wyrenderowania tej karty wielokrotnego użytku z awatarem i nazwą użytkownika.

Teraz można to wprowadzić i wykorzystać w większych częściach naszej aplikacji. Oto zapytanie, które mieliśmy przed zapytaniem przeglądarki, używając fragmentu, który importujemy z komponentu karty profilu użytkownika wielokrotnego użytku. Następnie wysyłamy go do komponentu karty widza, a teraz możemy go ponownie wykorzystać w naszej aplikacji.

Możemy tworzyć większe części naszej aplikacji, które opierają się na tej karcie użytkownika lub karcie autora. Możemy więc teraz mieć wiele komponentów, takich jak komponent tytułu bloga, który jest odpowiedzialny za tytuł. Możemy mieć kartę profilu użytkownika, którą właśnie utworzyliśmy, która renderuje profil użytkownika. Możemy mieć komponent treści lub fragmentu, który jest odpowiedzialny za znaczniki i dane dla tej części naszej aplikacji.

I tak, możemy zbudować te małe komponenty, które są odpowiedzialne za znaczniki, CSS i dane potrzebne do zbudowania tej aplikacji. I możemy je wspólnie skomponować. Możemy je przetestować w izolacji, przetestować je również jako większe jednostki. Możemy więc używać tego również w różnych szablonach.

Możemy użyć tych komponentów wielokrotnego użytku do posta na blogu lub naszej roli na blogu, w której mamy różnych autorów, ale możemy użyć tego samego komponentu do ich renderowania. Możemy go użyć do… drugiej strony archiwum. Tak bardzo podobne do części szablonów WordPress, możemy podzielić nasze aplikacje Headless na małe części, ale czerpiemy korzyść z połączenia naszej technologii razem.

To trochę o tym, jak programista Headless WordPress doświadcza projektowania opartego na komponentach i korzyści z tego płynących. Więc teraz, jeśli chodzi konkretnie o Gutenberga, dlaczego miałbyś rozważać Headless WordPress z Gutenbergiem? Cóż, jeśli Twój zespół korzysta już z Headless WordPress, prawdopodobnie z zaawansowanymi polami niestandardowymi i elastycznymi polami, i chcesz zaktualizować edytor, aby korzystać z Gutenberga, to oczywiście jeden z powodów, dla których możesz przejść na Headless z Gutenbergiem.

Jeśli chcesz czerpać korzyści z budowania komponentów, które są używane w administracji i komponentach, które są używane w interfejsie, to dobry powód, aby rozważyć przejście na Headless z Gutenbergiem, ponieważ edytor zaplecza edytora bloków Gutenberga jest w całości oparty na komponentach. Możesz chcieć skorzystać ze strukturalnych danych wejściowych. każdy blok w panelu administracyjnym ma uporządkowane pola.

Masz określone atrybuty, które możesz kontrolować na poziomie pola. I możesz chcieć skorzystać z tego, że te ustrukturyzowane dane wyjściowe docierają również do twoich komponentów. I jak wspomniałem, możesz chcieć ponownie wykorzystać komponenty i bloki w różnych projektach. Na przykład możesz chcieć mieć bibliotekę bloków zbudowaną przez Twoją agencję, która rozwiązuje takie kwestie, jak dostępność i określone problemy ze znacznikami, których chcesz używać w różnych projektach. Następnie możesz je zaktualizować w swoich projektach, a nie tylko w ramach jednego projektu.

Jest to więc część, w której motywy potomne w WordPress mogą być trudne do skalowania, ponieważ musisz przejść do każdej witryny i zaktualizować znaczniki i inne elementy w każdej witrynie. Cóż, tutaj możesz używać bibliotek bloków jako zależności NPM i aktualizować je w całej organizacji.

Tak więc obecnie stan rozwoju WordPress z Gutenbergiem jest taki, że mamy bloki na zapleczu, które są oparte na komponentach. Możemy zbudować własne niestandardowe bloki lub użyć podstawowych bloków WordPress. Ale dane wyjściowe w PHP to, jak wspomniałem, jeden duży fragment HTML, więc jak możemy przejść od pobierania tego jednego bloku HTML do posiadania komponentów na zapleczu, które również przenoszą się do komponentów na naszym interfejsie?

Przyjrzymy się więc niektórym opcjom pobierania danych Gutenberga z WordPressa do komponentów. Tak więc jedną z opcji jest pobranie treści w formacie HTML. Możemy więc wysłać zapytanie do naszej treści WordPress jako HTML, a następnie przeanalizować ten kod HTML do komponentów. Lub możemy odpytywać bloki jako typy GraphQL. Więc możemy – to pozwala nam zapytać o listę bloków, każdy blok byłby typem GraphQL, który możemy zmapować do komponentu.

Więc treść to HTML. To jest coś, co możemy zrobić dzisiaj w rdzeniu WPGraphQL. Jeśli chcesz przeszukiwać bloki jako pojedyncze typy GraphQL, w tej chwili dostępne są dwie opcje. Mamy rozszerzenie GraphQL dla Gutenberga, które jest rozszerzeniem społecznościowym, a następnie mamy WPGraphQL Block Editor, który jest wtyczką beta, nad którą osobiście pracuję.

Przyjrzyjmy się więc tym opcjom. W rdzeniu WPGraphQL możemy wyszukiwać treści jako HTML i analizować komponenty. Wygląda to tak, że pytamy o coś w rodzaju postu i możemy poprosić o pola takie jak identyfikator i tytuł lub treść. Treść zwróci jeden duży ciąg, jeden duży fragment kodu HTML, a następnie będziemy mogli przeanalizować ten kod HTML i zmapować różne węzły DOM do różnych komponentów.

Podobnie jak w tym przypadku na wpgraphql.com, link po lewej stronie prowadzi do kodu, w którym tak się dzieje. Biorę znaczniki zwracane przez WPGraphQL i analizuję je, szukam określonych węzłów HTML i konwertuję je na komponenty React. Więc mogę mieć interaktywne rzeczy, takie jak ten blok kodu, który podświetla składnię i pozwala użytkownikom kliknąć Kopiuj, a następnie mogę również analizować i tworzyć spis treści, na przykład. Więc to jest jedno podejście. I używam go dzisiaj w produkcji wpgraphql.com.

Niektóre rzeczy, które warto rozważyć, jeśli pójdziesz tą drogą, ładunki HTML mogą być nieprzewidywalne. Zmiany na serwerze, takie jak instalacja nowej biblioteki bloków lub różnych kodów HTML, które redaktorzy mogą umieścić w treści, są nieprzewidywalne. Więc może to być bardzo trudne do przeanalizowania. Nie możesz interospektować zmian. Jako programista kliencki nie możesz zobaczyć, co się zmieniło, więc po prostu coś do rozważenia.

Powiedziałbym, że takie podejście najlepiej sprawdza się w zespołach, które mają bardzo ścisłą kontrolę nad administratorem WordPress i front-endem. Więc jeśli jesteś pojedynczą osobą lub małym zespołem, który pracuje nad backendem i frontendem WordPress, może to działać dobrze, ponieważ możesz trochę lepiej kontrolować dane wejściowe i wyjściowe.

Jedna z innych opcji, WPGraphQL dla Gutenberga, jest to wtyczka utrzymywana przez społeczność. A to pozwoli ci wyszukiwać bloki treści, każdy blok jako własny typ GraphQL. Sposób, w jaki to działa, to strona ustawień, musisz wejść tylko w bloki jako schemat, więc otwiera to Gutenberg w niewidzialnym elemencie iframe, pobiera rejestr bloków z klienta JavaScript i wysyła go na serwer.

A potem możemy użyć GraphQL do zapytania naszych bloków jako określonych typów i możemy użyć fragmentów, jak pokazałem wcześniej, i możemy użyć tych fragmentów do mapowania na komponenty w naszym interfejsie użytkownika. Więc to jest jedna opcja. Niektóre uwagi dotyczące tej wtyczki, zmiany w rejestrze bloków są introspekcyjne, więc to dobrze.

Zespoły pracujące nad aplikacją front-end mogą korzystać z introspekcji GraphQL, aby zobaczyć, jak schemat zmienia się w czasie, i mogą wiedzieć, czy są przełomowe zmiany lub nowe pola, które mogą wykorzystać. Powiedziałbym, że to podejście działa trochę lepiej w przypadku projektów wieloosobowych lub wielozespołowych. Jeśli masz jeden zespół, który pracuje nad administratorem WordPress i inny zespół, który pracuje nad front-endem, to podejście może działać lepiej. Mogą używać schematu GraphQL jako kontraktu między blokami, które są używane po obu stronach.

Jedną rzeczą, która jest trochę interesująca, jest to, że ładuje bloki w ramce iframe, jak wspomniałem. Z tego powodu nie zawsze skaluje się w każdej sytuacji. Więc jeśli zarejestrujesz bloki na określonej stronie lub określonym szablonie lub określonym typie postu, ta metoda uzyskania mapy rejestru bloków do schematu może przegapić niektóre bloki. Może więc nie być skalowalny dla każdego projektu.

Więc następny projekt, WPGraphQL Block Editor, jest to wtyczka beta, nad którą obecnie pracuję. Pozwala to również na wysyłanie zapytań do bloków treści jako ich własnego typu GraphQL, a więc bardzo podobnie do WPGraphQL dla Gutenberga, możemy pisać fragmenty, które zwracają określone przez nas dane. A potem możemy użyć tych fragmentów z naszymi komponentami na froncie.

Kilka uwag z tym związanych, jest to wtyczka beta, więc jest to. Korzystasz z ustrukturyzowanego wejścia i ustrukturyzowanego wyjścia. Więc jako programista front-end, to na pewno wygrana. Działa z blokami zarejestrowanymi w pliku block.json. Tak więc podstawowe bloki WordPress Gutenberg mają ten plik, więc to będzie działać z tym podejściem. Wiele stron trzecich nie rejestruje swoich bloków w ten sposób, więc będziesz musiał ręcznie mapować te bloki.

Bloki nie są traktowane jako pojedyncze węzły. Chciałbym traktować bloki jako pojedyncze węzły, ale nie ma globalnego identyfikatora, więc musisz uzyskać dostęp do tych bloków jako części większych obiektów, takich jak strona z plakatem.

Mam więc nadzieję, że dowiedziałeś się czegoś o Headless WordPress, zaletach Headless WordPress i używaniu Headless WordPress z Gutenbergiem. Zapraszam do wypróbowania WPGraphQL już dziś. Możesz założyć bezpłatne konto Atlas Sandbox na stronie wpengine.com/atlas. I dziękuję za udział w mojej prezentacji. Ponownie możesz mnie znaleźć na Twitterze, jasonbahl, a także na Twitterze @wpgraphql. Dziękuję.