Wielkie nadzieje wiązałem z premierą Layout RFC. Podejście do renderowania komponentów po stronie serwera z możliwością bezpośredniego dostępu do bazy oraz mechanizmów cache brzmiało zbawiennie dla czystości i elastyczności kodu. Dobra, ale jak to wyszło w praktyce? Na razie bez konkretnych przykładów, bo jest to temat na co najmniej materiał wideo.
Mam sobie sklep, a ten posiada kategorie. Kategorie mogą mieć swoje pod-kategorie, a te swoje pod-pod-kategorie. I tak dalej i tak dalej. Aktualnie korzystam z Prisma jako ORM, a to rozwiązanie nie posiada rekurencyjnego zwracania wyników. Do tej pory sam sobie to odpalałem korzystając z odczytywania bazy w pętli, lub poprzez „include: {children: {include: {children: {include: {children: true;}}}}}” – masakra. Podejście komponentowe pozwala mi na pobranie wyników podczas renderowania komponentu, dzięki czemu bardzo szybko osiągam rekurencyjność. Pomijam na razie sposoby przechowywania w pamięci podręcznej wyników. Nie wszystko na raz.
Fajne nie? To właśnie to rozwiązanie nie dawało mi spać po nocach. W końcu można pozbyć się przekazywania propsów podczas „getServerSideProps” (ależ musiałem nad tym się nagłówkować, aby potem był do tego dostęp w dowolnym miejscu w aplikacji).
Co jeszcze jest ważne. Layouts usprawniają nawigację. Już nie cały layout się odświeża, a tylko dany segment strony. Strzałów do bazy również nie będzie o kategorie/koszyk/ulubione. Tylko to co faktycznie jest potrzebne w danym momencie np. opis produktu.
Upraszaczam zatem to co da się uprościć. Jeśli komponent będzie wykorzystywał dane tylko u siebie, to nie muszę mieć repozytoriów, abstrakcji i innych mechanizmów. Tak jak dawniej niech bezpośrednio odczyta bazę i wyrenderuje to co trzeba. Nie wiem jak to wpłynie na moje endpointy do API, bo jeszcze nie jestem na tym etapie, ale już nie mogę się doczekać, aż pozbędę się większości zaległości na korzyść nowego podejścia.
Czy to nie brzmi fascynująco?