Ten post jest szybkim wprowadzeniem do sposobu, aby Twój kod Gutenberga był zgodny z aktualnymi standardami za pomocą haków React. Zobaczymy, jak to jest korzystne, dlaczego powinniśmy to robić i jak.
Co, haki?
Zakładam, że masz już pewne doświadczenie w pracy z nieco bardziej złożonymi blokami lub wtyczkami Gutenberga, które wysyłają zapytania do postów lub pobierają i aktualizują meta postów. I w ten sposób pracowałem z [withSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withSelect)i/lub [withDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withDispatch). Są to komponenty wyższego rzędu w WordPressie, które umożliwiają dostęp do sklepów WordPressa w celu pobrania lub wypchnięcia informacji, które nieco wykraczają poza „normalny" blok lub edycję postów. Prawdopodobnie zostałeś również zmuszony do użycia composew celu połączenia swoich komponent z wieloma komponentami wyższego rzędu. Jeśli Twój kod używa tych wzorców, nie martw się – działają doskonale i będą działać nadal! Ale w miarę rozwoju technologii możemy działać lepiej.
Na początku 2019 r. React wypuścił hooki (wersja 16.8) – które pozwalają używać stanu bez użycia klasy i ulepszać inne funkcje, co daje bardziej czytelny i wielokrotnego użytku kod. Na przykład usunięcie konieczności pakowania kodu w komponenty wyższego rzędu w celu uzyskania dostępu do rejestrów. A latem 2019 pojawił się WordPress, uruchamiając niestandardowe hooki: [useDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useDispatch)i [useSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useSelect).
Zalet haczyków jest wiele. Najczęstszym przykładem jest umożliwienie korzystania ze stanu komponentu bez konieczności pisania klasy JavaScript (useState). Ale moim zdaniem największą zaletą jest możliwość ponownego użycia. Eliminując konieczność używania wzorców, takich jak rekwizyty renderowania i komponenty wyższego rzędu, komponenty mogą być zapisywane w znacznie bardziej niezależnych fragmentach. Kolejną zaletą hooków jest to, że twój kod jest łatwiejszy do odczytania i zrozumienia!
Przejdźmy od razu do kilku przykładów i zobaczmy, jak zaimplementować useSelecti useDispatchzahaczyć w naszym kodzie!
RealizowanieuseSelect
Zacznijmy od withSelecti odpowiadającego mu haka useSelect. Są one używane do pobierania właściwości wywodzących się ze stanu z zarejestrowanych selektorów. Typowe przykłady to dostęp do selektorów „ core” lub „ core/editor” w celu wykonania zapytań o posty (getEntityRecords), dostęp do meta postu (getEditedPostAttribute) lub po prostu uzyskanie bieżącego typu posta lub innych informacji.
W celach demonstracyjnych zacznę od prostego przykładu. Załóżmy, że mam komponent blokowy, w którym mam gdzieś selektor postów. Aby uzupełnić listę wpisów, muszę uzyskać dostęp do rejestru „ core” i wykonać GetEntityRecords()połączenie.
Stary sposób przy użyciuwithSelect
Jeśli chcę kwestionować posty w bloku, musiałbym zawinąć mój składnik w withSelect. Zwykle robi się to w exportoświadczeniu.
Należy pamiętać, że ten przykład kodu nie jest kompletny jako prawdziwy blok funkcjonalny lub wtyczka JS, został usunięty, aby pokazać podstawowe koncepcje withSelect. Jeśli szukasz praktycznych przykładów kodu, mam inne artykuły, które to opisują: np. jak zaimplementować bloki z opcją post select lub jak dodać meta post do inspektora. Te są napisane za pomocą withSelecti withDispatch, więc zrób to, a następnie wróć tutaj, aby dowiedzieć się, jak przekształcić je w haki.
Jak widać w linii #12-16, owijam swój komponent za pomocą withSelect. Wewnątrz funkcji withSelect mogę uzyskać dostęp do sklepu, który chcę, i zwracam zapytanie o post w rekwizycie „ somePosts“. Ta podpora będzie wtedy dostępna w moim AWP_Example_Pluginkomponencie (jak widać, zdestrukturyzowałem somePostsz podpór w wierszu #3).
Jak wspomniano wcześniej, ta metoda działa dobrze – i będzie to robić nadal. Ale ma to kilka wad. Po pierwsze, nie jest to łatwe do zrozumienia. Jasne, to był bardzo prosty przykład. Na pierwszy rzut oka na sam komponent nie masz pewności, skąd somePostspochodzi rekwizyt lub co to jest. Musisz wiedzieć, aby poszukać instrukcji eksportu i sprawdzić, czy są jakieś opakowania. Czuje się też trochę chaotyczny. Wykonujesz znaczną część ważnej pracy poza swoim komponentem, aby uzyskać coś, co naprawdę chcesz, aby było dostępne w twoim komponencie.
Zróbmy to lepiej za pomocą haków.
Konwersja nauseSelect
Konwersja a withSelectna useSelectjest tak prosta, jak to tylko możliwe. Pierwszym krokiem jest zdefiniowanie zmiennej somePostswewnątrz naszego komponentu, a nie na zewnątrz przez exportinstrukcję. Drugim krokiem jest przeniesienie całej funkcji, którą mieliśmy withSelectdo useSelect. I to wszystko.
Powyższy kod daje dokładnie taki sam wynik jak ten z withSelect. Różnica polega na tym, że kod jest teraz znacznie bardziej zrozumiały! Możemy teraz bardzo łatwo zobaczyć, że zmienna somePostsprzechowuje wynik zapytania post, bezpośrednio w naszym komponencie.
Ważna uwaga: useSelectakceptuje drugi parametr; szereg zależności. Zależności to zmienne, które zapewniają, że uruchamiamy się tylko wtedy, useSelectgdy zmieni się jedna z zależności (wartości zmiennych). Ten fragment jest ważniejszy useDispatchniż tutaj, więc wyjaśnię to nieco dalej w useDispatchsekcji poniżej.
RealizowanieuseDispatch
Przyjrzyjmy się teraz withDispatchi odpowiadającemu mu hakowi useDispatch. Służą do wysyłania rekwizytów do rejestrów. Na przykład mówiąc Gutenbergowi, aby zaktualizował meta postu za pomocą „ core/editor“.
Ponownie, dla celów demonstracyjnych, moje przykłady kodu nie są kompletnymi funkcjonalnymi fragmentami kodu – ilustrują tylko części dotyczące tych wzorców. W tym przykładzie zakładam, że mam pole tekstowe pokazujące meta postu – i chcę zaktualizować wartość meta postu po zmianie.
Stary sposób przy użyciuwithDispatch
Ponieważ withDispatchjest to komponent wyższego rzędu, musiałbym owinąć w to mój komponent. Zwykle robi się to w exportoświadczeniu. Aby pole tekstowe dla naszej meta działało,
Na przykład:
W wierszu #20-26zawijamy komponent do środka withDispatch, w którym zwracamy funkcję „ setPostMeta“, która wysyła meta posta (aby ją zaktualizować). W wierszu #6destrukturyzujemy podpórkę, aby można było jej użyć w zdarzeniu pola tekstowego onChangew wierszu #13. (Pamiętaj, że powyższy przykład nie będzie działał, ponieważ ustawiliśmy wartość pola tekstowego na pusty ciąg. To tylko po to, aby zademonstrować, jak użyjemy wysyłki).
Ponownie widzimy, że kod nie jest tak prosty do zrozumienia. Musiałbyś wiedzieć, jak poszukać opakowania, aby dowiedzieć się, z czego rekwizyt „ setPostMeta” jest lub z którego pochodzi. Zróbmy to lepiej za pomocą haków!
Konwersja nauseDispatch
Zmiana withDispatchna useDispatchnie jest tak prosta, jak withSelectna useSelect. Jednak nadal jest to dość łatwe. Należy pamiętać o dwóch rzeczach. Jednym z nich jest to, że useDispatchjako pierwszy parametr przyjmuje nazwę sklepu. onChangeUzyskalibyśmy wtedy dostęp do sklepu i wywołalibyśmy jego dostępne funkcje, gdy z niego korzystamy (np. w zdarzeniu pola tekstowego ). Po drugie, tablica zależności od useDispatchdrugiego parametru jest ważniejsza niż z useSelect. Możesz ryzykować, że kod skończy się w nieskończonej pętli, jeśli nie będziesz prawidłowo zarządzać zależnościami. Dopiero po zmianie zmiennych zależności skrypt zostanie ponownie uruchomiony useDispatch.
Na przykład:
Na linii #8destrukujemy to, czego potrzebujemy od sklepu ‘ core/editor‘. Interesuje nas tylko editPostfunkcja, której możemy użyć do aktualizacji postu meta. Jako drugi parametr useDispatchpodajemy zależności. Jeśli chodzi o przykład aktualizacji meta postu, użycie wartości meta posta (za pomocą useSelect) byłoby idealne jako zależność. W tym przykładzie ustawiłem ją jako zmienną fikcyjną. Poszukaj bardziej kompletnego i realistycznego przykładu. A następnie w wierszu zdarzenia #16pola tekstowego onChangewywołujemy editPostaktualizację meta. Zwróć uwagę na różnicę w tej linii z użyciem withDispatchpowyżej! Ponieważ używamy editPostbezpośrednio zamiast zwracać funkcję do aktualizacji meta postu dla nas (setPostMeta), musimy dostarczyć obiekt zmetajako klucz, a następnie obiekt z meta postu, który chcemy zaktualizować. Podzieliliśmy withDispatchkod na kawałki.
Mimo to użycie useDispatchsprawia, że kod jest znacznie bardziej czytelny i zrozumiały. Koniec z dodawaniem kodu poza naszym komponentem, którego musimy użyć wewnątrz.
Pełniejszy przykład i eliminacja potrzebycompose
Są szanse, że jeśli używasz withDispatch, będziesz potrzebować withSelectrównież tego komponentu. W powyższych przykładach do konwersji useDispatchaktualizujemy wartość meta postu. Ale aby pole tekstowe działało poprawnie (a także pokazywało aktualną wartość), musielibyśmy również pobrać wartość meta postu.
Jeśli potrzebujesz użyć wielu komponentów wyższego rzędu owiniętych wokół twojego komponentu, najprawdopodobniej użyjesz jeszcze innej funkcji Gutenberga; [compose](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-compose/). Jest to przydatna funkcja łączenia wielu komponentów wyższego rzędu w jeden komponent wyższego rzędu, wokół którego możesz owinąć swój komponent.
Przyjrzyjmy się pełniejszemu przykładowi komponentu, który pobiera wartość meta posta w polu tekstowym i aktualizuje się, gdy jego wartość zostanie zmieniona. Zaczniemy od tego, jak musielibyśmy się do tego zabrać za pomocą withSelecti withDispatch(a więc także compose).
Korzystanie withSelectz, withDispatchicompose
Na linii #21-34komponujemy withSelecti withDispatchowijamy je wokół naszego komponentu. postMetafrom withSelecti setPostMetafrom withDispatchsą teraz dostępne w naszym komponencie jako rekwizyty. Destrukujemy je na linii #7i wykorzystujemy w #13i #14.
Jak widać, niezbędny kod poza naszym komponentem jest dłuższy niż sam komponent. Nie wiem jak wy, ale dla mnie to trochę chaotyczne. Deweloperzy mogą zacząć czytać ten kod od góry, nie widząc dolnej części, i zacząć się zastanawiać, skąd postMetai setPostMetaskąd – wydają się być magicznie dostępne. Dla mnie jest to bardzo nieintuicyjne.
Przyjrzyjmy się, jak zamienilibyśmy powyższy przykład na haki.
Korzystanie useSelectiuseDispatch
Jak piękne i czytelne jest to?! Od razu widzimy w naszym komponencie, skąd postMetajest pobierany i jak uzyskujemy dostęp do editPost. Nasz komponent stał się również znacznie łatwiejszy w ponownym użyciu.
Zauważ, że w useDispatchlinii #12dodajemy postmetę, którą aktualizujemy jako zależność (postMeta.example_post_meta). Jeśli miałbyś aktualizować wiele zmiennych meta postu w tym komponencie, musiałbyś dodać każdą z nich jako zależność, aby upewnić się, że wysyłanie zostanie uruchomione (właściwie zapisując meta post), gdy wartość jednej z nich ulegnie zmianie.
Mam nadzieję, że było to dla kogoś pouczające i pomocne. Wciąż nie jestem zaznajomiony z haczykami, ale widząc korzyści z ich używania, nie cofam się!