 Przejdę w sumie do Meritum, bo już wszystko zostało opowiedziane. To co chciałbym przedstawić to jakie zalety posiada astro i jakie możliwości optymalizacyjne oraz pokaże case study jak można przenieść front end strony do innej technologii, czyli templatka WordPressa przeniesiona do innej technologii front endowej i wykorzystać wtedy WordPressa jako headless CMSa bez żadnych zmian w samym CMSie. To tak, jeśli chodzi o aktualne wdrożenie, jest to templatka WordPressa, która była oparta o Hizela. Jest to framework, który oddziela back end od front endu, czyli mamy dwie warstwy oddzielone, co jest wygoda przy developerce. Trejstron była oparta o pole ACFa flexible content. Jest to taki layout do wyboru danego modułu i wtedy pojawiają się pola według modułu, który wybierzemy. Formularze były oparte o kontakt form 7, multi języczność strony była WPML oraz metatagi były oparte o wtyczkę Yoast. Więc było zadanie przenieść te funkcjonalności do nowej technologii. To tak, zaobserwane problemy, które były w aktualnym wdrożeniu. Na pewno moduły niektóre wykorzystywały jQuery oraz ciężkie biblioteki np. do sliderów, więc to wymagało na pewno przepisania JavaScriptu, co przekładało też się na średnią wydajność. Projekt stał się mało skalowalny, bo jeśli była potrzeba dołożyć jakieś komponenty, które wymagały do dania trochę JSa, spadała wydajność strony, więc to było bardzo problematyczne. Rozwiązanie to przeniesienie strony do Astro samego frontendu, wykorzystanie WordPressa do wystawienia danych, następnie takie dynamiczne, interaktywne komponenty jak slidery, formularze przenieść do technologii Vue.js, w której się super czuję. Typowanie danych, które pomoże nam zbudować strukturę używanych danych, które pobieramy oraz pomoże nam uniknąć potencjalnych błędów z typem danych. A sama architektura CSSa będzie oparta o popularny framework Tilewind. To tak na początek, dlaczego wybrałem Astro? Czym jest w ogóle Astro? O jest framorkiem JS, który jest skoncentrowany na tym, aby jak najszybciej wyświetlić te statyczne treści, a dynamiczne treści takie interaktywne załadować z odpowiednim projektywem. I dzięki temu on jest tworzony do tworzenia turbo szybkich stron, gdzie wydajność ma znaczenie. Jedna zalet Astro to jest serendowanie po stronie servera, czyli server site rendering. Drugi tryb to jest generowanie stron statycznych. Aktualnie w tym wdrożeniu wykorzystałem SSG, ponieważ treści rzadko się zmieniają i nowe rzadko się pojawiają. Podejście zero JS chodzi o to, że w porównaniu do np. view czy reacta Astro nie potrzebuje żadnego JSa do załadowania strony, co jest dużą zaletą. Możemy zintegrować swój ulubiony framework, czy to svelte, view, react, solid JS jest tego mnóstwo. Są to chorowe integracje przygotowane przez Astro. Architektura wysp to duża zaleta, o której potem opowiem dokładniej. Wysoka wydajność oraz ci co znają JSa jest bardzo niski próg wejścia. Sama implementacja Astro musiałem na początku postawić sobie pytanie co wybrać, czy WPRS API, czyli natywne API WordPressa, czy wtyczkę WPR GraphQL. To tak, na pewno płaska struktura danych przemawia przez res API. WPR GraphQL mamy zagnieżdżoną. Przy typowaniu danych, budowania struktury danych to nie jest zbyt wygodne. Możemy w WPRS API stworzyć łatwo dodatkowe rucy, czy dodatkowe pola, które możemy wykorzystywać w Endpointach. WPR GraphQL posiada taki budowany builder zapytań, który pomaga przyspieszyć budowanie zapytań do wybierania danych. Takim minusem WPRS API jest sytuacja, gdy potrzebujemy wyciągnąć więcej potrzebnych danych z WPRS API, potrzebujemy więcej zapytań, a WPR GraphQL zrobi to jednym zapytaniem i to jest jego przewaga. Ale wybrałem z uwagi na TypeScripta i wygodę, wybrałem WPRS API i zoptymalizowałem pobranie danych co do minimum. To tak, to jest przykład Endpointu z WPRS API. Gdzie mamy pobranie postów i jak widzimy, nie wiem czy to jest widoczne, tam jest ID kategorii. Czyli tutaj byśmy potrzebowali dodatkowego zapytania, aby pobrać dane na przykład, jaki ma tytuł kategoria. Mam nadzieję, że jest widoczne, to jest przykładowe query z WPR GraphQL. Jak widzimy, on automatycznie już wyciąga dane o tej kategorii, jaki ma tytuł. Więc tutaj mamy to wszystko za jednym zapytań. Sama struktura projektu Astros oparta głównie o dwa katalogi, czyli katalog public, gdzie mamy takie statyczne pliki jak fonty, obrazki i katalog SRC, gdzie mamy głównie pliki i strukturę naszego modelu danych, które odpowiada za zbudowanie statycznych stron. Jeden katalog, warto uwagi to pages, gdzie w wersji drugiej to już jest content. Jestem jeszcze przed migracją do wersji drugiej astro. I tutaj są pliki, które są odpowiedzialne za zbudowanie statycznych stron, czyli jak widzimy, oparłem to potrzebowałem tylko czterech plików, aby zbudować wszystkie strony WordPressa. Tutaj jeśli chodzi o składnie astro, jest bardzo podobna do wyrażeń J6. Są tam drobne tylko różnice. Możemy używać strukturze HTML'a bezpośrednio JavaScripta i astro umożliwia dodanie takiego nagówka pomiędzy myślnikami, gdzie możemy zainportować jakieś komponenty, możemy zainicjować propsy, do których możemy potem używając ten komponent przekazać dane. Możemy przetwarzać tam te dane oraz z automatu mamy dostępny obiekt astro props, gdzie tu jest użyta destrukturyzacja i można używać wtedy te dane przekazane z komponentu w strukturze HTML. Tam jeszcze dodam, że można załączyć tak script i tak style i w momencie, kiedy astro przetwarza na serwerze plik dorzuca do header przetworzony ten style i script. Jeśli chodzi o dynamiczne dodawanie klasy, jest bardzo proste, możemy przekazać tablicę ze stringiem i obiektem i w momencie, kiedy warunek jest spełniony, to wtedy klasa jest dodawana, albo przekazać sam obiekt. Tutaj jest na przykład pobrania danych jednego z plików. Jak widać jest taki operator spread przy slagu. On informuje astro, że tutaj może wystąpić zagniżony slag, czyli możemy na przykład stworzyć sobie w tym miejscu strukturę, na przykład case study business i on wtedy automatycznie wygeneruje te takie ścieżki. Mamy dostępną taką funkcję jsową get static pass, która generuje te wszystkie ścieżki i pliki. Przygotowałem sobie taką funkcję use pages, która zwraca mi dane i mogę używać w każdym miejscu używając jednej funkcji. Z automatu astro wyrzuca w propsach zwrócony props i możemy przekazać dalej do komponentu. Ja to przekazają do komponentu template, w którym dzieje się logika, dzieje wybierany dany modu i przekazywany dalej dane z danego modułu. Architektura wysp. Na czym to w ogóle polega? Wyobraźmy sobie, że mamy już wyrendorowaną stronę i niektóre fragmenty, jak tutaj jest załączone na obrazku możemy wczytać z odpowiednim priorytetem bez blokowania wczytania strony. Przygotowałem taki przykład, to jest formularz kontaktowy stworzony w UJS i mamy takie trzy podstawowe dyrektywy, które pozwolą wczytać komponent pierwsza dyrektywa client load. Wczytuję komponent najszybciej, jak to możliwe, czyli jest to wysoki priorytet. Możemy to wykorzystać do wczytania elementów, które są kluczowe z punktu widzenia użytkownika, np. menu. Następnie klient idl. W momencie zostanie komponent wczytany, kiedy zwolni się główny wątek, czyli w momencie wczytania strony. I ostatnia, najlepsza według mnie dyrektywa, klient visible, wczyta komponent dopiero wtedy, wykorzystując Interface Intersection Observer. W momencie, gdy użytkownik zeskroluje do miejsca, gdzie zaraz ma się pojawić dany komponent, i on dopiero w momencie tym zostanie załadowany. Czyli jak stworzyłem sobie formularz kontaktowy, Recapcha sam formularz zostanie załadowany dopiero, kiedy użytkownik zeskroluje do tego formularza. Astro umożliwia takie integracje wbudowanych komponentów image i picture. Jest to partę o przetwarzanie obrazów za pomocą biblioteki sharp. Takie zalety to możemy wtedy mieć kontrolę i przetwarzać obrazy co do pixela. Jest wygodny format wydajny, format webp. Oraz współczynnik proporcji. W momencie, kiedy potrzebujemy użyć się, nie wiem, kwadratu z obrazka, no to automatycznie on zostanie docięty i wykorzystujemy już odpowiednio przeskalowany obraz. Jak wdrożyłem CF7? Jedyne co trzeba zrobić to zarejestrować ruta, na którym odpalimy funkcję, która odpali shortcode, czyli wygeneruje nam HTML, i następnie pobierając HTML mamy tam wszystko dostępne, żeby stworzyć formularz. Jedynie co musimy pamiętać, to trzeba własnoręcznie już napisać komunikację z API, czyli wszystkie errorsy, które przychodzą do danego pola, to trzeba to obsłużyć. I w momencie, kiedy mamy integrację z rekapczą ustawioną w konfigu CF7, no to musimy zadbać o to, żeby pobrać token przed wysłaniem, przed wysłaniem formularza. Jeśli chodzi o WPML, tłumaczone treści, wystarczy tylko przekazać atrybut lang, raczej paramet lang do WPS API, i jak na przykład przekazujemy lang.pl, no to automatycznie zwraca nam tłumaczoną treść w języku polskim. Switcher i języków trzeba pobrać hreflangi dla danych stron, pokażę wdrożenie, jak to zrobiłem, a tłumaczenie layoutu akurat w tym projekcie tego nie potrzebowałem, ale możemy stworzyć JSON-a z tłumaczeniami danego języka, nie możemy wykorzystać wbudowanego wykrywania wraz do tłumaczenia WPML-a, bo mamy odsparowany front od backendu i z tego wtedy nie możemy skorzystać. Switcher i języków, nie wiem czy kod dobrze widać, ale jedyne co tam trzeba zrobić to pobrać aktywne języki i po prostu pobrać linki według tego, czy jest to aktywna strona, czy kod językowy jest nieaktywny, no to wtedy musimy pobrać ID przetłumaczonego postu. I następnie zwracamy już przetłumaczoną tablicę i możemy zbudować sobie switcher i języków. Yoast był chyba najprostszy do wdrożenia. Dodajemy do endpointa pole Yoasthead i z automatu mamy wszystkie tagi, które są zainplementowane na danej stronie. Wykorzystujemy taki wbudowany komponent fragment, do którego przekazujemy dane i on renderuje go wtedy tam, gdzie go przekażemy. Jeśli chodzi o deployment, mamy do wykorzystania gotowe rozwiązania, to można sobie przeczytać, jedynie body nie obsługuje serwer side renderingu, reszta tak, są to patne rozwiązania, możemy się pokusić o własne rozwiązania, czyli możemy sobie zrobić jakiegoś batona wad imimince, który odpali skryt baszowy, który zbuduje w odpowiednim katalogu na serwerze odpali tego builda, potencjalne papki i będy. Na pewno jeśli użyjemy w nagłówku astro, pliku astro, użyjemy interfejsu, który jest dostępny tylko po stronie klienta, czyli window document oraz inne też interfejsy. Dostaniemy błąd, że nie jest definiowany, więc możemy tylko użyć wtedy tych interfejsów w tagu script, który zostanie załączony po stronie klienta i to jest taka potencjalna puapka. Następnie brak użycia słówka kluczułego await. W momencie tutaj mam funkcję, która jest promisem. Jak nie użyjemy awaita, to w danej zmiennej dostajemy promisa zamiast zwróconych danych, ale jak użyjemy awaita, wtedy funkcja poczeka i zwróci dane otrzymane z API. Kolejna puapka to import pliku astro do view czy reacta. Nie możemy bezpośrednio tego zrobić, bo view nie zrozumie składnie astro i wywali błędem. Możemy użyć astroslota i wtedy możemy wrzucić komponent, który zostanie przetworzony po serwerze i on zostanie załadowany dopiero po stronie klienta, czyli jest wyrendorowany na stronie po stronie serwera i jest wrzucony do komponentu w tym wypadku view. W jakich projektach się sprawdzi? Myślę, że sprawdzi się strona firmowa landing page, sklep internetowy, bo tam wydajność ma znaczenie oraz jakaś prosta aplikacja. Nie sprawdzi się w dużych portalach z dużą ilością treści, bo jeśli sobie wyobrazimy, że treść stron jest oparta o flexible content i mamy dużo tych modułów na stronie, to strasznie baza zacznie się rozrastać. Myślę, że wtedy zamiast astro i headless bym po prostu użył Gutenberg, bo to byłoby lepsze rozwiązanie. Aplikacja webowa oraz panel administracyjny, jeśli tak byśmy chcieli wykorzystać framework astro, myślę, że on nie jest przeznaczony do tego typu rozwiązań, lepiej jest wykorzystać technologie, które są do tego przeznaczone, typu view czy react. Porównanie wydajności, jak widzimy, 68 na desktopie, tu mamy setkę, total blocking time 0ms i mobilka 96 punktów poprawiona, więc jak widzimy, astro daje nam dużą wygodę, dużą wydajność, tak jak Maciek wspomniał, są pewne problemy, tak jak deployment, dodatkowy build i trzeba po prostu używać takiej architektury w projektach, do których ma to sens. Ja dziękuję za uwagę.