Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Przepisy optymalizacji Next.js

Next.js App Router zmienił model mentalny dla aplikacji React. Server Components, streaming, parallel routes, intercepting routes — powierzchnia jest ogromna, a narzędzia AI czasem generują wzorce Pages Router przez pomyłkę. Te przepisy generują kod App Router wyłącznie, z prawidłowymi granicami serwer/klient i właściwymi wzorcami danych.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Przepisy Server Component i Server Action z prawidłowymi granicami
  • Wzorce pobierania danych używające RSC, streaming i Suspense
  • Przepisy uwierzytelniania i middleware dla App Router
  • Prompty optymalizacji wydajności dla Core Web Vitals

Przepis 1: Streaming z niezależnymi granicami Suspense

Dział zatytułowany „Przepis 1: Streaming z niezależnymi granicami Suspense”

Scenariusz: Twoja strona pulpitu wykonuje 4 niezależne wywołania API. Wszystkie blokują renderowanie, dopóki najwolniejsze się nie zakończy.

Oczekiwany wynik: Strona z 4 granicami Suspense, 4 komponentami asynchronicznymi sekcji, 4 szkieletami i metadane.

Przepis 2: Server Actions do obsługi formularzy

Dział zatytułowany „Przepis 2: Server Actions do obsługi formularzy”

Scenariusz: Potrzebujesz formularza kontaktowego walidującego po stronie serwera, obsługującego błędy i pokazującego stan oczekiwania bez osobnej trasy API.

Oczekiwany wynik: Akcja serwera, komponent strony, komponent formularza klienta i testy.

Przepis 3: Uwierzytelnianie z NextAuth.js v5

Dział zatytułowany „Przepis 3: Uwierzytelnianie z NextAuth.js v5”

Scenariusz: Potrzebujesz uwierzytelniania email/hasło i OAuth z zarządzaniem sesją i chronionymi trasami.

Rusztowanie NextAuth obejmuje auth.ts, middleware.ts, handler trasy [...nextauth], wrapper klienta i komponenty — a granica serwer/klient to miejsce, gdzie narzędzia AI potykają się najczęściej, więc wybierz workflow, który pozwala ci ją pilnować.

Użyj trybu agenta, aby zbudować auth.ts, middleware.ts i handler trasy razem, a następnie zrób checkpoint przed zaakceptowaniem. Auth to klasyczny przypadek, gdzie AI dorzuca "use client" do Server Component i po cichu zabija SSR — inline diff pozwala wyłapać błędną dyrektywę, zanim trafi na produkcję.

Oczekiwany wynik: Konfiguracja auth, middleware, handler tras, narzędzia klienta, komponenty, HOC i testy.

Przepis 4: Parallel i Intercepting Routes dla modali

Dział zatytułowany „Przepis 4: Parallel i Intercepting Routes dla modali”

Scenariusz: Szczegóły produktu powinny otwierać się w modalu z listy, ale pokazywać pełną stronę przy bezpośrednim dostępie.

Oczekiwany wynik: Strony produktów, intercepting route, layout ze slotami równoległymi, komponent modalu i testy.

Przepis 5: Edge API Route Handlers

Dział zatytułowany „Przepis 5: Edge API Route Handlers”

Scenariusz: Potrzebujesz niskopóźnieniowych tras API działających na edge z typowaniem, walidacją i cache’owaniem.

Oczekiwany wynik: Handlery tras, biblioteka narzędzi API i testy dla każdego endpointu.

Przepis 6: Incremental Static Regeneration dla bloga

Dział zatytułowany „Przepis 6: Incremental Static Regeneration dla bloga”

Scenariusz: Twój blog ma 500 postów. Pełna generacja statyczna trwa 10 minut. Potrzebujesz ISR.

Oczekiwany wynik: Strony bloga z ISR, webhook rewalidacji, sitemap, generowanie obrazu OG i testy.

Przepis 7: Edge Middleware dla testów A/B i flag funkcji

Dział zatytułowany „Przepis 7: Edge Middleware dla testów A/B i flag funkcji”

Scenariusz: Podziel ruch między wariantami strony docelowej i bramkuj funkcje za flagami na edge.

Oczekiwany wynik: Middleware, funkcje narzędziowe, katalogi wariantów i testy.

Przepis 8: System dynamicznych metadanych i danych strukturalnych

Dział zatytułowany „Przepis 8: System dynamicznych metadanych i danych strukturalnych”

Scenariusz: Każda strona potrzebuje unikalnych meta tagów, dynamicznych obrazów OG i danych strukturalnych JSON-LD.

Oczekiwany wynik: Narzędzie metadanych, generowanie obrazu OG, helpery JSON-LD, robots.ts, sitemap.ts i testy.

Przepis 9: Optymalizacja Core Web Vitals

Dział zatytułowany „Przepis 9: Optymalizacja Core Web Vitals”

Scenariusz: Wynik wydajności Lighthouse to 65. LCP 4.2s, CLS 0.25, INP 320ms.

Praca nad Vitals dzieli się czysto na dwie połowy: rozproszone edycje komponentów (obrazy, czcionki, dynamiczne importy) i bramkę budżetu w CI. Różne narzędzia lepiej obsługują każdą połowę.

Użyj trybu agenta, aby przejść edycje komponentów — konwersje na next/image, podmiany na next/font, useDeferredValue na filtrze — w wielu plikach naraz, obserwując inline diffy, by prop priority nie wylądował na każdym obrazie. Wizualna recenzja Cursora jest najszybsza dla tego rodzaju szerokiej, powtarzalnej zmiany.

Oczekiwany wynik: Zoptymalizowane komponenty, zmiany konfiguracji, setup czcionek, workflow Lighthouse CI i metryki.

Przepis 10: Architektura multi-tenant SaaS

Dział zatytułowany „Przepis 10: Architektura multi-tenant SaaS”

Scenariusz: Twój SaaS obsługuje wielu najemców z pojedynczego wdrożenia z routingiem opartym na subdomenach i izolacją danych.

Oczekiwany wynik: Middleware, narzędzie tenant, provider, zapytania scopowane, tematyczny layout i testy izolacji.

Przepis 11: Architektura wtyczek dla rozszerzalnych pulpitów

Dział zatytułowany „Przepis 11: Architektura wtyczek dla rozszerzalnych pulpitów”

Scenariusz: Twój pulpit potrzebuje wtyczek instalowanych przez użytkownika dodających strony, trasy API i komponenty UI.

Oczekiwany wynik: Interfejs wtyczki, rejestr, catch-all routes, integracja sidebar, przepływ instalacji i testy.

Przepis 12: End-to-End bezpieczeństwo typów z tRPC

Dział zatytułowany „Przepis 12: End-to-End bezpieczeństwo typów z tRPC”

Scenariusz: Twoje 20 endpointów API ma typy zawsze niezsynchronizowane z frontendem.

Sednem tRPC jest end-to-end wnioskowanie typów, więc prawdziwym testem każdego narzędzia tutaj jest to, czy zmiana wyjścia routera ujawnia się jako błąd kompilacji po stronie klienta — a nie to, czy pliki zostały wygenerowane.

Zbuduj server/trpc.ts, routery i okablowanie klienta w trybie agenta, a następnie udowodnij pętlę interaktywnie: zmień typ zwracany przez procedurę i obserwuj, jak czerwona falka pojawia się w komponencie konsumującym. Sprawdzanie typów na żywo w edytorze to najszybszy sposób na potwierdzenie, że wnioskowanie jest faktycznie przeprowadzone.

Oczekiwany wynik: Setup tRPC, routery, handler, typowany klient, integracja React Query i weryfikacja bezpieczeństwa typów.

Gdy przepisy nie działają

Dział zatytułowany „Gdy przepisy nie działają”

Co dalej

Dział zatytułowany „Co dalej”

Zobacz co nowego na platformie.

Polityka prywatności Regulamin