Przedstawiamy React-Gutenberg Bridge: Obsługa bloków bezgłowych dla jeszcze lepszego doświadczenia podczas edycji

Jesteś podekscytowany możliwościami, jakie oferuje bezgłowy WordPress, ale zespół marketingowy Twojego klienta jest powiązany z edytorem WYSIWYG Gutenberg.

Zobacz, jak nowa obsługa bloków Fausta Gutenberga dla projektów bezobsługowych łączy te dwa elementy, aby unowocześnić Twój rozwój, jednocześnie wzmacniając pozycję Twoich marketerów.

Głośniki:

• Teresa Gobble, inżynier oprogramowania w WP Engine
• Blake Wilson, starszy inżynier oprogramowania w WP Engine

Slajdy sesji:

Transkrypcja:

TERESA GOBBLE: Cześć, ludzie. Nazywam się Teresa Gobble. Jestem inżynierem oprogramowania z WP Engine pracującym w zespole Faust.

Jestem tutaj z Blakiem Wilsonem, starszym inżynierem oprogramowania, aby przedstawić wam React-Gutenberg Bridge – obsługę bezgłowych bloków, zapewniającą jeszcze lepsze wrażenia podczas edycji. Powitanie. Zacznijmy.

Więc dzisiaj mamy dużo do omówienia. Przede wszystkim omówię kilka rzeczy związanych z problemem i rozwiązaniem, które mamy dla Ciebie, a także wartość React-Gutenberg Bridge. Następnie udamy się do Blake'a, który dostarczy nam demo React-Gutenberg Bridge w akcji. Później porozmawiamy o kilku szczegółach technicznych. Odwiedzimy również przyszłą mapę drogową tego, co mamy w zanadrzu.

Oto problem. Nie ma usprawnionego sposobu tłumaczenia bloków Gutenberga z WordPress na bezgłowy interfejs użytkownika. Rozwiązania, które istnieją, nie są jeszcze skalowalne ani intuicyjne, aby zapewnić programistom doświadczenie, jakiego mogą oczekiwać programiści bez głowy.

Oddzielenie w naturalny sposób przerywa możliwość korzystania z treści bloku Gutenberga w edytorze. A agencje zastanawiają się, jak zrobić to po swojemu lub od zera bez wskazówek. I wiele pytań bez odpowiedzi pozostaje dla ludzi.

A co ze stylizacją? A co z możliwością ponownego użycia, blokami dynamicznymi, InnerBlocks? Cóż, w tym miejscu wkracza React-Gutenberg Bridge. Jest to rozwiązanie składające się z dwóch części – po pierwsze, sposób programowego udostępniania bloków Gutenberga, aby można je było analizować i czytać na bezgłowym interfejsie użytkownika. Ten element nazywa się Bloki treści WPGraphQL.

Po drugie, mamy złącze ułatwiające konfigurację i renderowanie tych bloków w bezgłowym interfejsie użytkownika. A to jest pakiet o nazwie Faust WP Blocks. Tutaj zobaczysz przewodnik, jak to działa z obydwoma tymi elementami rozwiązania.

Zaplecze Twojej witryny oparte na React ma swoje Gutenberg Blocks, które są ujawniane przez wtyczkę WPGraphQL Content Blocks. Udostępnia zawartość block.json WPGraphQL. Dostarcza go do wtyczki o nazwie WPGraphQL.

A potem dochodzi do pakietu konektora, który umożliwia dostosowywanie, wykrywanie i renderowanie bloków. W rzeczywistości będzie to omawiane znacznie częściej, gdy przejdziemy do dyskusji technicznej i dzisiejszej wersji demonstracyjnej. Jaką wartość wnosi to do Twojego zespołu?

Cóż, jest to kompleksowe rozwiązanie oparte na opiniach, które zmniejsza złożoność i niejednoznaczność. Oszczędza czas programowania, przestrzegając określonych konwencji. Pozwala na łączenie bloków i wzorów bloków. I może być ponownie używany w kółko. Teraz, gdy masz pojęcie o tym, jak działa React-Gutenberg Bridge, przejdźmy do Blake'a, aby zobaczyć jego demonstrację w akcji.

BLAKE WILSON: Dzięki, Tereso. Cześć wszystkim. Jestem Blake Wilson. Jestem starszym inżynierem oprogramowania w WP Engine.

I jestem w zespole Faust JS budującym Faust. Mam dla was dzisiaj naprawdę świetne demo, pokazujące dwa komponenty, które zbudowaliśmy, aby pomóc w orkiestracji tego React-Gutenberg Bridge. Przejdźmy więc do rzeczy.

Na początek pokażę ci, co mam tutaj do mojej konfiguracji. A potem możemy przejść do rzeczywistego kodu i zobaczyć, co tam mamy. Na początek mam tutaj witrynę WordPress działającą w trybie lokalnym.

Mam zainstalowane kilka wtyczek. Więc mam wtyczkę Faust. Pomaga to ułatwić wyświetlanie podglądów i wszelkiego rodzaju dobrych rzeczy na Twojej stronie Faust JS. Mam WPGraphQL, który jest niezbędny do przekształcenia Twojej witryny WordPress w punkt końcowy GraphQL.

A potem mam bloki treści WPGraphQL. Jest to więc jedna z wtyczek, które stworzyliśmy, aby ułatwić korzystanie z mostka React-Gutenberg. To rozwiązanie składa się z dwóch głównych części.

Mamy więc jeden z elementów do faktycznego udostępnienia danych Gutenberg Block programowo za pomocą WPGraphQL, a następnie kolejną część do wykorzystania ich na interfejsie użytkownika Faust JS. Zacznijmy od przyjrzenia się blokom zawartości WPGraphQL i temu, jak to działa.

Wskoczymy więc do naszego graficznego IDE. Skonfigurowałem tutaj to zapytanie, aby pobrać dane strony. Więc w tym przypadku pobieramy tylko tytuł strony.

Więc to, co robi GraphQL Content Blocks, to ujawnia typ bloków treści w twoim schemacie GraphQL. Więc jeśli wpiszemy bloki treści, jak widać tutaj, otrzymamy informacje dla danej strony i wszystkich bloków na tej stronie. Przejdźmy do tej strony i edytujmy ją, dodając trochę treści.

Wejdziemy więc na przykładową stronę. I widzicie tutaj, że mamy czystą kartę. Więc chodźmy dalej i stwórzmy kilka bloków. Utwórzmy tutaj kilka kolumn.

I zrobimy kolumnę 50/50. Dodajmy akapit na tej połowie, a następnie na obrazku na tej połowie. Więc mam obraz tutaj w mojej bibliotece multimediów. Chodźmy i wrzućmy to.

I widzicie tutaj, mamy dwie kolumny. Ponownie akapit po lewej stronie i obraz po prawej stronie. Więc zaktualizujmy to. I wróćmy do bloków treści WPGraphQL i zobaczmy, co otrzymamy w rezultacie.

Więc możesz zobaczyć tutaj, teraz mamy dwa bloki treści. Pierwsza z nich to podstawowa kolumna, podstawowa kolumna. A potem otrzymujemy renderowany HTML wewnątrz tego.

Wspaniałą rzeczą w blokach treści WPGraphQL jest to, że obsługujemy również InnerBlocks. Więc możesz zobaczyć tutaj, jeśli dodamy parametr do bloków treści o nazwie flat true, możesz teraz zobaczyć, że otrzymamy właściwie wszystkie bloki, które były nawet w tych kolumnach. Więc zajmujemy się również tą sprawą za Ciebie.

Otrzymujemy kolumnę rdzenia, kolumnę rdzenia, akapit rdzenia, obraz rdzenia. Wszystko to jest wykonywane programowo za Ciebie. A teraz możesz użyć tych danych blokowych na swoim interfejsie. Więc kopmy trochę głębiej tutaj.

Powiedzmy, że chcemy mieć na nim niektóre atrybuty. Możemy tego użyć, używając unii w GraphQL. Więc zrobimy na obrazie rdzenia, zdobądź atrybuty. I powiedzmy, że chcemy na przykład napis.

Więc możesz zobaczyć tutaj, że nie ma podpisu. Wróćmy do naszej przykładowej strony. Pójdziemy dalej i dodamy tutaj podpis. Mój podpis. Zaktualizuj to.

A jeśli odświeżymy to zapytanie, możemy teraz zobaczyć, że otrzymujemy mój podpis jako właściwy atrybut w blokach treści WPGraphQL. To jest część 1 rozwiązania. Teraz możemy faktycznie uzyskać wszystkie dane z naszego bloku Gutenberga i wykorzystać je do wykorzystania ich w naszym interfejsie użytkownika.

Przejdźmy więc do VS Code i zobaczymy, jak poradzimy sobie z tym elementem. To jest przykładowy projekt Fausta JS, który złożyłem. To jest bardzo proste. Opiera się na schemacie rusztowania Fausta, ale z dodatkową konfiguracją do obsługi tych bloków.

Więc jeśli przyjrzymy się pakietowi JSON, zobaczysz, że mamy tutaj kilka zależności, niektóre ze zwykłych pakietów Fausta, takie jak core i CLI. Mamy również klocki Faust VP. Jest to więc jeden z tych pakietów, który zapewnia wszystkie nasze funkcje pomocnicze.

Mamy też pewne zależności w WordPress do obsługi stylów i tak dalej. Zauważysz tutaj również, że mamy ten katalog WP Blocks. Więc tutaj znajdują się wszystkie nasze bloki dla naszego interfejsu użytkownika i działa on jako rejestr dla wszystkich bloków, których używamy na naszym interfejsie użytkownika.

Jak widać, mamy plik index.js. Zasadniczo jest to obiekt, który określa wszystkie bloki, których używamy w naszym interfejsie. Jak widać, mamy główny akapit, główną kolumnę, główne kolumny i główny obraz.

Jeśli chodzi o ustawienie tego, są dwa główne elementy, o których będziemy mówić. Jednym z nich jest dostawca bloków WordPress i przeglądarka bloków WordPress. Przyjrzyjmy się więc, jak to wygląda w akcji. Najpierw przyjrzyjmy się dostawcy bloków WordPress.

Będzie to dostępne w pages_app. Więc możesz zobaczyć tutaj mamy ten komponent, tego dostawcę, dostawcę WordPress Blocks. I akceptuje rekwizyt konfiguracyjny, który akceptuje bloki. Możesz więc zobaczyć tutaj, że importujemy bloki z WP Blocks, indeksu tego katalogu, i przekazujemy go do obiektu config.

Zasadniczo oznacza to, że dostawca bloków WordPress opakowuje całą aplikację i nadaje kontekst dla wszystkich tych bloków całej aplikacji. Przejdźmy teraz do szablonów WP do naszego pojedynczego szablonu. I możesz zobaczyć tutaj, że wywołujemy przeglądarkę bloków WordPress z rekwizytem bloków treści. To są dane blokowe, które otrzymujemy z WPGraphQL.

Dobra, to tyle na temat konfiguracji. Rozkręćmy to i zobaczmy, jak to wygląda w akcji. Zamierzam więc uruchomić program NPM run dev, który skonfiguruje środowisko deweloperskie na localhost 3000. A strona, nad którą pracowaliśmy wcześniej, była przykładową stroną ukośnika, więc odwiedzę przykładową stronę ukośnika localhost 3000, aby zobaczyć te Gutenberg Bloki, które ustawiliśmy wcześniej.

Więc możesz zobaczyć tutaj, mamy bloki, które są takie same w naszym edytorze Gutenberga. Wróćmy więc do naszego edytora Gutenberga, aby zobaczyć przykładową stronę. Widzicie, że mamy tutaj nasze dwie kolumny, to jest mój akapit, a następnie nasz obraz, który odpowiada temu, co mamy tutaj na froncie.

Więc możesz powiedzieć, że wygląda świetnie iw ogóle, ale czy możemy modyfikować style? Czy możemy zmienić rozmiar czcionki? Na pewno możesz.

Wróćmy więc do naszego edytora Gutenberga i dokonajmy pewnych modyfikacji w tych blokach. Dodajmy więc tutaj kolor tła do naszego akapitu. Zmieńmy też rozmiar na duży. Zaokrąglijmy ten obraz tutaj.

Usuńmy napis. I to zaktualizujemy. Tutaj możesz zobaczyć, że te style mają teraz zastosowanie. I możesz je zobaczyć na swoim froncie.

Tak więc naprawdę zwracamy doświadczenie wydawcy, którego nie oczekujesz w WordPress, do swojej bezgłowej witryny WordPress. Kolejną wspaniałą rzeczą jest to, że teraz, gdy otrzymujesz dane programowe dla tych bloków, możesz stworzyć swój komponent React z funkcjami specyficznymi dla frameworka, takimi jak następny obraz. Teraz, zamiast po prostu renderować kod HTML, który otrzymujesz z WPGraphQL, teraz możemy użyć tych danych programowych do stworzenia komponentu, który renderuje wszystkie nasze obrazy w Gutenberg z następnym obrazem, zapewniając nam leniwe ładowanie, lepszą wydajność i lepiej zoptymalizowane obrazy ogólnie rzecz biorąc, tworząc lepszą obsługę dla naszych użytkowników.

Więc to jest świetne. Widzimy dokładnie to, czego oczekujemy w naszym edytorze Gutenberga, ale powiedzmy, że dodajemy komponent, który być może nie jest jeszcze obsługiwany lub którego nie skonfigurowaliśmy na naszej stronie Fausta. Więc przejdźmy dalej i stwórzmy tutaj nowy komponent. Użyjemy tabeli.

I zrobimy dwa rzędy – rząd 1, rząd 2. Idź i zaktualizuj to. A jeśli spojrzymy wstecz na nasz kod, zobaczymy, że mamy zdefiniowane cztery bloki — główny akapit, główna kolumna, główne kolumny i główny obraz. Nie mamy tutaj tabeli podstawowej.

Co się stanie, gdy obejrzymy tę stronę? Spójrzmy. Wrócimy więc do przykładowej strony na naszym interfejsie Fausta. I widzicie, że nadal mamy tu tabelę z rzędem 1 i rzędem 2.

To dlatego, że jeśli blok nie jest jeszcze zdefiniowany w twoim projekcie Faust JS, zrobimy sensowny inteligentny powrót do wyrenderowanego HTML. W ten sposób nie widzisz niezdefiniowanych, pustych lub po prostu żadnych treści. Przynajmniej odzyskujesz oryginalny renderowany kod HTML.

Mając to wszystko na uwadze, przyjrzyjmy się, co tak naprawdę jest potrzebne do stworzenia bloku – jak to naprawdę wygląda. Więc wrócimy tutaj do VS Code. I wybierzmy na przykład główny obraz.

Jak widać, jest to po prostu tradycyjny komponent React. Nazywamy to obrazem rdzenia. I akceptuje rekwizyty, tak jak każdy inny komponent React.

Blok składa się zasadniczo z dwóch kawałków. Mamy więc właściwy komponent React, czyli warstwę prezentacyjną. Następnie otrzymujemy block.fragments, czyli dane potrzebne do wykonania tego bloku.

Jak widać, tworzymy fragment, fragment obrazu rdzenia na obrazie rdzenia. I otrzymujemy te atrybuty – atrybuty, których potrzebujemy do renderowania tego bloku. Jak widać, otrzymujemy tekst alternatywny, źródło, podpis, nazwę klasy, szerokość, wysokość i tak dalej.

A potem to, co możemy zrobić, to zastosować te atrybuty do naszej rzeczywistej logiki React. Tak więc wszystkie wymagane tutaj pola są dostępne w rekwizytach. Możesz więc zobaczyć, jak wychodzi props.attributes, czyli atrybuty, o które tutaj prosiliśmy, attributes.alt, attributes.source i tak dalej. Jest to więc świetny sposób na umieszczenie wszystkich wymagań dotyczących danych dla twojego bloku w tym samym pliku.

Daje to pewność, że żądasz tylko tych danych, których potrzebujesz, i upewnienie się, że Twoje żądania są ładne i wydajne. W tym przykładowym projekcie mamy również kilka funkcji pomocniczych. Możesz zobaczyć, że jest tu kilka – zdobądź style i zdobądź rekwizyty wielkości obrazu.

Zasadniczo są to po prostu pobieranie tych stylów z WordPress i łączenie ich w rzeczywisty obiekt stylów, z którego może korzystać React. Obecnie style są obsługiwane w przypadku stylów wbudowanych. Możesz także uzyskać globalne arkusze stylów, ale obecnie pracujemy nad zapewnieniem obsługi pliku theme.json.

Więc Teresa opowie trochę o tym w naszej przyszłej mapie drogowej. Ale w idealnej sytuacji nadejdzie moment, w którym będziemy mogli pobrać wszystkie nasze style i dopełnienie, marginesy itd. z pliku theme.json i zastosować to tutaj w bezgłowym interfejsie użytkownika. Mając to wszystko na uwadze, przejdźmy do krótkiej dyskusji technicznej z Teresą i porozmawiajmy o tym, gdzie jesteśmy dzisiaj z tą funkcją i dokąd planujemy pójść w przyszłości.

TERESA GOBBLE: Dziękuję za to demo, Blake. To było świetne. Przejdźmy teraz do szczegółów technicznych i porozmawiajmy o tym, jak to działa. Więc pierwszą, którą mam dla ciebie, jest to, jakie są wymagania, aby korzystać z bloków treści WPGraphQL?

BLAKE WILSON: Tak, tak. Świetne pytanie, Tereso. Tak więc jedynym wymogiem korzystania z wtyczki jest zainstalowanie również WPGraphQL. Oczywiście, jeśli chcesz, aby Twoja witryna była połączona z Faust JS, możesz zainstalować pakiet bloków Faust JS, który ułatwi renderowanie i wszystkie inne dobre rzeczy na bezgłowym interfejsie. Ale aby faktycznie ujawnić dane blokowe, wszystko czego potrzebujesz to WPGraphQL i wtyczka WP GraphQL Content Blocks.

TERESA GOBBLE: Wspaniale. W jaki sposób gromadzone są również dane blokowe?

BLAKE WILSON: Tak, więc wszystkie dane blokowe są gromadzone przez dowolny blok w WordPressie, który używa funkcji rejestru typu bloku. Tak więc prawie każdy blok, którego używasz, który łączy się z tą funkcją, pojawi się w blokach treści. Wspaniałą rzeczą jest to, że przekazuje z plikiem block.json i automatycznie opisuje i dokumentuje wszystkie te pola. Masz więc dokumentację w jednym.

TERESA GOBBLE: Och, wspaniale. Co za oszczędność czasu. Inną rzeczą, o której chciałbym, abyś powiedział trochę więcej, jest to, co dzieje się z nieobsługiwanym blokiem? Co się dzieje, gdy zapytanie dotyczy nieobsługiwanego bloku?

BLAKE WILSON: Tak, to kolejne świetne pytanie. Istnieją dwa realne scenariusze, które mogą się tutaj wydarzyć. Może więc zdarzyć się sytuacja, w której załóżmy, że masz blokadę w danych posta, która została już usunięta z WordPress.

Być może była to blokada strony trzeciej, która została usunięta. Jest to więc jeden przypadek nieobsługiwanego bloku, który nie jest obsługiwany zarówno w interfejsie Fausta, jak iw rejestrze WordPress. W takim przypadku faktycznie zwracamy blok do bloków treści o nazwie niezdefiniowany blok lub nieznany blok, abyś mógł go odpowiednio wpisać w interfejsie headless. A druga część dotyczy tego, że jeśli blok w rejestrze WordPress jest obsługiwany, ale nie jest jeszcze obsługiwany w twoim interfejsie Faust JS, w takim przypadku wracamy do wyrenderowanego HTML. W ten sposób przynajmniej wyrenderowałeś HTML, który się wyświetla, a nie null, undefined lub inne podobne wartości.

TERESA GOBBLE: Och, wspaniale. I to właściwie prowadzi mnie do następnego pytania. Jeśli chodzi o wtyczki stron trzecich w bezgłowej stronie internetowej, czy możesz użyć wtyczki strony trzeciej za pomocą wtyczki WPGraphQL Content Blocks? Jak to wszystko razem działa?

BLAKE WILSON: Tak, tak. Tak więc w przypadku każdej wtyczki innej firmy, wracając do tego pierwszego lub drugiego pytania, o ile łączą się one z zarejestrowaną funkcją typu bloku w WordPress, blok ten zostanie automatycznie wystawiony na działanie bloków treści WPGraphQL. Tak długo, jak te dane są renderowane, możesz utworzyć blok w swoim interfejsie Faust JS. Wspaniałą rzeczą jest to, że załóżmy, że masz blok karuzeli innej firmy. Po utworzeniu go raz w interfejsie Faust JS możesz go ponownie wykorzystać w innych projektach w przyszłości.

TERESA GOBBLE: Och, świetnie. W tym miejscu pojawia się element umożliwiający ponowne użycie. Dzięki tej wtyczce możesz faktycznie wypełnić część tej luki za pomocą wtyczek innych firm, które nie działają od razu z oddzielonymi stronami internetowymi.

Ponadto, jeśli spojrzysz teraz na czat, faktycznie przygotowaliśmy samouczek, który pomoże ludziom stworzyć blok z wtyczki innej firmy. Zajrzyj teraz na czat, zobaczysz to i klikniesz. Daj zakładkę.

Jak więc radzisz sobie z blokami w blokach? To może być naprawdę trudne. Czy możesz nam przybliżyć, jak to będzie wyglądać?

BLAKE WILSON: Jasne, tak. Mamy więc tę flagę lub ten parametr, gdy odpytujemy bloki treści zwane flat. I to albo przyjmuje wartość true, albo false. A więc kiedy to jest podane jako prawda, faktycznie otrzymasz płaską tablicę lub płaską listę wszystkich bloków na tej stronie, niezależnie od tego, czy jest to kolumna, obraz czy akapit.

Będziesz mieć pełną listę wszystkich bloków, o które pytano na tej stronie, z dwoma dodatkowymi właściwościami. Jednym z nich jest identyfikator węzła. Więc to jest rzeczywisty identyfikator tego konkretnego bloku. A wtedy będziesz mieć również identyfikator rodzica, który jest rodzicem tego bloku. Więc to, co możesz wtedy zrobić, to zrekonstruować to na rzeczywistą hierarchiczną listę na twoim interfejsie, prawie rozwiązując zagadkę wewnętrznego bloku, jak widzieliśmy wcześniej w Gutenbergu.

TERESA GOBBLE: Wspaniale. Więc właściwie, podczas pobierania bloków treści istnieje opcja, którą można określić, aby zwrócić płaską listę bloków w ramach ich odpowiednich identyfikatorów nadrzędnych dzieci?

BLAKE WILSON: Tak, tak, dokładnie.

TERESA GOBBLE: Świetnie. Na czacie mamy też kolejny samouczek, aby bloki treści WPGraphQL mogły również przyjrzeć się tej konkretnej funkcji. Więc chciałem zadać ci inne pytanie dotyczące elementu stylizacji – więc stylizacja z globalnymi arkuszami stylów, inline, jakie jest tam podejście? Jak wygląda stylizacja?

BLAKE WILSON: Tak, tak. Tak więc stylizacja jest prawdopodobnie jednym z największych impulsów, nad którymi obecnie pracujemy. W przykładzie, który właśnie pokazałem, używa się stylów wbudowanych.

Obsługiwane są również style globalne, globalne arkusze stylów. Myślę, że poruszycie ten temat w następnej części planu. Ale w idealnej sytuacji chcielibyśmy również wspierać obsługę pliku theme.json, gdzie możemy uzyskać marginesy, dopełnienia, kolory i wszystkie inne dobre informacje z pliku theme.json, a następnie zastosować to. Dlatego będziemy nad tym pracować w następnej fazie rozwoju.

TERESA GOBBLE: Wspaniale. Dziękujemy za przeprowadzenie nas przez to. Wiem, że wiele osób jest tym bardzo podekscytowanych. Jak więc ograniczyć wydawcy korzystanie z bloków, które nie są obsługiwane?

BLAKE WILSON: Tak, tak. Więc jest tam wtyczka. To zależy. Jeśli korzystasz z blokad innych firm, niektóre z nich mają już wbudowaną tę funkcję.

Ale jeśli nie, istnieje wtyczka o nazwie widoczność bloków, którą można faktycznie przełączać określone bloki z perspektywy wydawcy. Załóżmy więc, że masz blok karuzelowy, który nie został jeszcze zaimplementowany w Twojej witrynie Faust. Możesz zainstalować widoczność bloków i odznaczyć ją, aby wydawca nie używał jej, dopóki nie jest obsługiwana lub jest w fazie rozwoju.

TERESA GOBBLE: Och, wspaniale. Aby widoczność bloków wtyczek mogła faktycznie przełączać, ukrywać, pokazywać określone bloki?

BLAKE WILSON: Tak, tak, dokładnie. W ten sposób masz ograniczoną liczbę obsługiwanych bloków, zarówno po stronie WordPressa, jak i bezgłowej witryny, więc wydawcy wiedzą, OK, możemy to wykorzystać z pewnością, że będzie obsługiwany na przód.

TERESA GOBBLE: Och, to z pewnością brzmi jak czystsza dostawa. Ok fajnie. Ostatnie pytanie do ciebie. Czy te bloki interfejsu odpowiadają edytorowi wydawcy?

BLAKE WILSON: Tak, świetne objaśnienie. Więc jeszcze nie. To jest coś, nad czym będziemy pracować w przyszłości, ale na razie te bloki są obsługiwane przez bezgłowy interfejs użytkownika.

Jeśli masz niestandardowy blok, który utworzyłeś w WordPress, jeśli używasz polecenia NPX create block, nadal będziesz musiał obsługiwać ten widok po stronie WordPress. Ale to jest coś, nad czym pracujemy. Mamy to w naszym planie działania.

TERESA GOBBLE: Och, wspaniale. OK. Dziękuję, że omówiłeś z nami te kwestie, Blake. To było naprawdę pomocne, podobnie jak demo.

Chodźmy dalej, zmieńmy biegi i porozmawiajmy trochę więcej o tej mapie drogowej projektu. W rzeczywistości mamy pięć faz, z których dwie są już zakończone – faza 1 i faza 2. W fazie 1 widzieliśmy implementację metody efektywnej dekonstrukcji, a następnie rekonstrukcji bloku.

Następnie przeszliśmy do fazy 2, która skupiała się na ściślejszej integracji Fausta z blokami Gutenberga, aby zapewnić wszystkim dostęp do różnych narzędzi i funkcji pomocniczych, które tam są. Następna faza, w której właśnie się znajdujemy, faza 3, koncentruje się na zapewnieniu obsługi theme.json i bibliotek bloków wielokrotnego użytku, jak wspomniał Blake podczas naszej dyskusji technicznej.

Gdy to zrobimy, nastąpi faza 4 i 5. Faza 4 koncentruje się na ulepszeniu istniejącego doświadczenia w zakresie programowania i edycji, a także faza 5, która koncentruje się na wspieraniu szerszego ekosystemu poza rdzeniem WordPress. Jesteśmy bardzo podekscytowani tymi nadchodzącymi fazami i mamy nadzieję, że będziecie z nami kontaktować się z bazą i zaglądać do naszego posta na blogu, aby być na bieżąco z planem działania.

Możesz zobaczyć link na czacie poniżej do naszych postów na blogu, jeśli rzucisz okiem. Śmiało i dodaj je do zakładek. Cóż, dziękuję wszystkim za przyłączenie się do naszej dyskusji na temat mostu React-Gutenberg. Chcę sprowadzić Blake'a z powrotem na ekran tutaj, aby mógł również podziękować i dać nam trochę więcej informacji o tym, gdzie możesz się udać, jeśli będziesz miał jakieś pytania.

BLAKE WILSON: Tak, dziękuję, Tereso, i dziękuję wszystkim, którzy dołączyli do dzisiejszej sesji i ją oglądali. Nie możemy się doczekać, aby poznać opinie społeczności na temat tej funkcji, abyście wszyscy mogli ją wypróbować.

Więc jeśli ci się spodoba, mamy przykładowy projekt w linku na czacie. Mamy też link na czacie do naszego Headless Discord, czyli po prostu miejsce, w którym ty i inni podobnie myślący twórcy headless możecie dołączyć i porozmawiać o nadchodzących funkcjach i wydaniach w przestrzeni headless. Więc jeszcze raz wam wszystkim dziękuję. Naprawdę to doceniamy.