• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Next static pre rendering

VPS Starter Arubacloud
+2 głosów
236 wizyt
pytanie zadane 17 maja 2022 w JavaScript przez szym89 Początkujący (350 p.)
Cześć,

załóżmy ze klient ma sklep. Developer przygotwał sklep ,zrobił wszędzie static prerendering i zbudował aplikacje.

Po kilku dniach klient dodał produkty do swojego sklepu w cmsie. Czy te produkty będą widoczne dla odwiedzajacych czy trzeba zrobić server side rendering?

2 odpowiedzi

+2 głosów
odpowiedź 17 maja 2022 przez rafal.budzis Szeryf (85,260 p.)
wybrane 28 maja 2022 przez szym89
 
Najlepsza

Masz kilka opcji aby zachować całość jako SSG bez SSR

1) Postawić serwer który bedzie obsługiwał całego Next.JSa + opcja fallback. Wtedy nowe strony zbudują się tylko raz a następni odwiedzający będą korzystać z prerenderowanej strony za pierwszym razem. 

https://nextjs.org/docs/api-reference/data-fetching/get-static-paths

2) nasłuchiwać na zmiany w CMS eventy, hooki i budować aplikacje next.js na nowo.

3) Uruchomić co np co 1h  skrypt który zbuduje nexta ponownie.

P.S. Kolejność nie jest przypadkowa ;) 

+3 głosów
odpowiedź 17 maja 2022 przez niezalogowany
Na stronie SSG nowe produkty nie będą widoczne po wejściu bezpośrednio na dany URL (na przykład z Googla, czy linku w wiadomości) - co warto mieć na uwadze, to w większości implementacji SPA, aplikacja "odzyskuje" pełną komunikację z API, gdy user przechodzi pomiędzy podstronami.

Osobiście mocno odradzam SSR przez Development Experience - cała masa problemów niespotykanych w innych podejściach. Sherowany state, mem leaki, błędy w hydracji, niekompatybilne biblioteki ze środowiskiem node'a, problemy z wydajnością i wiele wiele więcej.

Jeśli nie masz zasobów, aby użerać się z SSR - polecam spojrzeć na Dynamic Rendering
2
komentarz 17 maja 2022 przez rafal.budzis Szeryf (85,260 p.)
edycja 17 maja 2022 przez rafal.budzis

Jeśli piszesz samemu SSR to się zgodzę jeśli piszesz w frameworku takim jak Next.JS to to co piszesz to jakieś bzdury. Nigdy nie miałem żadnych problemów wymienionych przez Ciebie.

Sherowany state - jeśli się trzymasz zasady że w state mają być tylko obiekty które można serializować do JSONa to zaden problem

błędy w hydracji - jeśli renderujesz coś warunkowo dla mobile np to wystarczy poprawnie użyć propsa key w React.

niekompatybilne biblioteki - wystarczy wczytywać je dynamicznie z uzyciem paczki next/dynamic oraz opcji { ssr: false }

2
komentarz 17 maja 2022 przez niezalogowany

Jeśli piszesz samemu SSR to się zgodzę jeśli piszesz w frameworku takim jak Next.JS to to co piszesz to jakieś bzdury. 

Wszystkie błędy które wymieniłem są niezależne od frameworków 

Nigdy nie miałem żadnych problemów wymienionych przez Ciebie.

Dowód trochę anegdotyczny. Jeśli nie napotkałeś żadnych z tych problemów, zaryzykuję stwierdzeniem, że pisałeś tylko proste aplikacje

Memleaków przy niskim natężeniu ruchu nie widać, ponieważ skutecznie są "likwidowane" przez CD

Niekontrolowanego współdzielenia stanu aplikacji - jeśli nie wiesz gdzie i jak szukać - nie wyłapiesz testami e2e, ani testerem manualnym. Czasem potrzeba mniej niż kilkunastu milisekund pomiędzy zapytaniami dwóch różnych użytkowników, żeby dopiero zobaczyć błąd. 

Błędy w hydracji, niekompatybilne biblioteki ze środowiskiem node'a - wystarczy, że biblioteka renderuje kawałek HTML-a i jednocześnie korzysta z API przeglądarki. Witamy w piekle if process.browser

Problemy z wydajnością - akurat Next, o którym mówisz, ma sporo ciekawych mechanizmów optymalizacyjnych do wykorzystania. Tutaj react + community robi świetną robotę (na ciebie Nuxt patrzę). Jednak z tych mechanizmów nadal trzeba świadomie korzystać

1
komentarz 18 maja 2022 przez niezalogowany

Sherowany state - jeśli się trzymasz zasady że w state mają być tylko obiekty które można serializować do JSONa to zaden problem

błędy w hydracji - jeśli renderujesz coś warunkowo dla mobile np to wystarczy poprawnie użyć propsa key w React.

niekompatybilne biblioteki - wystarczy wczytywać je dynamicznie z uzyciem paczki next/dynamic oraz opcji { ssr: false }

Odpowiedź do komentarza pisz jako odpowiedź do komentarza, a nie jako edycja swojego poprzedniego komentarza. Dla osób, które to czytają mocno zaburzasz flow


Sherowany state - jeśli się trzymasz zasady że w state mają być tylko obiekty które można serializować do JSONa to zaden problem

Stan aplikacji to też różnego rodzaju instancje bibliotek.

Czasami nawet człowiek nie zdaje sobie sprawy, że sheruje pojedynczą instancje pomiędzy użytkownikami: 

import iAmASingleton from 'someLib or ./customClass.ts'

Nie bardzo również rozumiem, jak trzymanie tylko obiektów, które można serialzować do JSON-a, ma zapobiegać sherowaniu danych.

Prosty przykład, wystarczy do zagnieżdżonego state'u wrzucać na starcie jakiś wcześniej zdefiniowany obiekt - na przykład z innego pliku

export const DEFAULT_NUMBERS = [1, 2, 3]

 i już mamy sherowany state.


błędy w hydracji - jeśli renderujesz coś warunkowo dla mobile np to wystarczy poprawnie użyć propsa key w React.

 niekompatybilne biblioteki - wystarczy wczytywać je dynamicznie z uzyciem paczki next/dynamic oraz opcji { ssr: false }

Podałem przykład gdzie potrzebujesz libki do wyrenderowania jakiegoś kawałka HTML-a (czyli nie możesz zrobić ssr: false)

Tutaj tak naprawdę nie trzeba nawet bardzo wymyślać - spróbuj wyrenderować losową liczbę, lub aktualną datę :)

1
komentarz 18 maja 2022 przez rafal.budzis Szeryf (85,260 p.)

Sorry za edycje nie wiedziałem że tak szybko mi odpiszesz. Edytowałem komentarz bo przez przypadek wysłałem komentarz zanim go skończyłem ;) 

Ok rozumiem o co chodzi z tym sherowanym state. Myślałem że problem leży w głownym state aplikacji. Niektórzy do redux wciskają funkcje i dziwią się że nie działa. W takim razie problem rozwiąże Ci immutable-js. Kreatory zamiast stałych.

const GET_DEFAULT_NUMBERS = () => [1, 2, 3]

 lub Object.freez() jednak wszystkie wspomniane techniki mają również zastosowanie przy działaniu tylko po stronie przeglądarki. 

Wydaje mi się że wszystko da się zrobić za pomocą {ssr:false}. Bez ifów, czasem tylko musisz  libkę otoczyć jakimś komponentem. Korzystając z ssr:false hydracja ma się dobrze mimo brakujących kawałków HTMLa. Możesz też skorzystać z loading w next/dynamic aby uniknąć przesuwania układu w trakcie ładowania strony.

Losowa liczba to nic trudnego ;) 
 

const RandomNumber = () => {
    const random = Math.round((Math.random() * 100));

    return <div key={random}>{random}</div>
}

Dzięki podaniu propsa key React wie że to inny obiekt i że tak ma go traktować dzięki temu nie będzie na nim próbował hydracji i wszystko zadziała prawidłowo. 

Możesz też losować liczbę w funkcji getServerSideProps i zapewnić sobie tą samą liczbę co po stronie serwera. Zależy na co masz ochotę. key jest szybszym rozwiązaniem getServerSideProps wydaje się lepszym.
 

Dowód trochę anegdotyczny. Jeśli nie napotkałeś żadnych z tych problemów, zaryzykuję stwierdzeniem, że pisałeś tylko proste aplikacje

Może i tak jest nie wiem od kiedy można uznać aplikacje za rozbudowaną ;) Jednak może autor pytania również pisze mało rozbudowaną aplikację ;) Jednak w mojej ocenie za szybko skreśliłeś bardzo fajną technologie bo każdy z wymienionych problemów da się rozwiązać.

2
komentarz 18 maja 2022 przez niezalogowany
Pracuję jako tech lead i od 2018 roku siedzę w SSR-rach. Przeszedłem przez Nuxty, Nexty i SvelteKita (nawet miałem nieprzyjemność pisać w Nuxt3). Ja nie skreślam tej technologii, ja ją po prostu odradzam ze względu na DX i potencjalne problemy, które są trudne do naprawienia.

Jeśli Cię stać na dobrych programistów i wiesz, że biznesowo potrzebujesz SSR-a z hydracją do SPA - to masz mój miecz i bierz Nexta, ponieważ to najlepsze dostępne rozwiązanie.
1
komentarz 18 maja 2022 przez rafal.budzis Szeryf (85,260 p.)
Dzięki! Ja miałem nieprzyjemność pracowania z Gatsby i go na pewno odradzam. Fancy graphQL który daje dodatkowy narzut przy operacjach oraz brak SSR to duże minusy tej technologii. Z next.JS działam dopiero od 9 miesięcy i narazie sobie chwale. Dużo rzeczy jest po prostu lepiej przemyślana. Jednak dalej są jakieś nie dociągnięcia. W next.js brakuje mi wbudowanego mechanizmu na tworzenie jednego builda pod wiele środowisk. Nie podoba mi się to że NEXT_PUBLIC są brane pod uwagę przy buildzie zamiast przy starcie. Ale da się to łatwo obejść.

Wydaje mi się że możesz pamiętać "problemy wieku dziecięcego" W tej chwili wydaje mi się że technologie SSR są bardziej dojrzałe i może dlatego nie trafiłem jeszcze na jakieś duże wyzwania.

Ja SSR traktuje jako technologie wspierającą szybkość strony.  Dlatego nie jestem przekonany do Dynamic Rendering dla robotów bo user dostanie i tak białą migającą kartkę. Na punkcie szybkości mam hopla. Lubię wykręcać wyniki na poziomie 100 w lighthouse. Ale wiadomo zawsze coś za coś.

Podobne pytania

+1 głos
0 odpowiedzi 76 wizyt
0 głosów
2 odpowiedzi 195 wizyt
pytanie zadane 26 kwietnia 2022 w JavaScript przez Bakkit Dyskutant (7,600 p.)
+1 głos
1 odpowiedź 469 wizyt
pytanie zadane 18 lutego 2022 w JavaScript przez Oskar Szkurłat Bywalec (2,780 p.)

92,453 zapytań

141,262 odpowiedzi

319,088 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...