M

MLOG

Magyar

Fedezze fel a Next.js App Directory átalakító erejű, fájl-alapú útválasztási rendszerét, amely jobb szervezést, teljesítményt és fejlesztői élményt kínál a modern webalkalmazások számára.

Next.js App Directory: Egy fájl-alapú útválasztási forradalom

A Next.js folyamatosan feszegeti a webfejlesztés határait, erőteljes eszközöket és funkciókat kínálva a fejlesztőknek a teljesítmény-orientált, skálázható és felhasználóbarát alkalmazások készítéséhez. Az App Directory bevezetése jelentős előrelépést képvisel, különösen az innovatív, fájl-alapú útválasztási megközelítésével. Ez a cikk mélyen beleássa magát az App Directory útválasztási mechanizmusába, feltárva annak előnyeit, kulcsfogalmait és gyakorlati következményeit a modern webalkalmazások Next.js-szel történő építése során.

Az útválasztás fejlődésének megértése a Next.js-ben

Az App Directory előtt a Next.js a Pages Directory-ra támaszkodott az útválasztás során. Bár hatékony volt, ennek a megközelítésnek voltak bizonyos korlátai. A Pages Directory egy egyszerű, fájl-alapú útválasztási rendszert használt, ahol minden fájl a `pages` mappában egy útvonalnak felelt meg. Például a `pages/about.js` a `/about` útvonalhoz tartozott.

Bár egyszerű volt, a Pages Directory nem rendelkezett beépített támogatással a komplex elrendezésekhez, adatlekérdezési stratégiákhoz és szerveroldali renderelési mintákhoz, ami gyakran arra kényszerítette a fejlesztőket, hogy ezeket a funkciókat manuálisan implementálják. Továbbá az adatlekérdezés és a komponens renderelés szoros kapcsolata néha teljesítménybeli szűk keresztmetszetekhez vezethetett.

Az App Directory ezeket a korlátokat egy rugalmasabb és erősebb útválasztási rendszer bevezetésével orvosolja, amely a React Server Components-re, Layoutokra és más fejlett funkciókra épül. Túllép az egyszerű fájl-útvonal megfeleltetésen, és egy deklaratívabb és komponálhatóbb megközelítést kínál az alkalmazás útvonalainak és elrendezéseinek meghatározásához.

Az App Directory bemutatása: Új paradigma az útválasztásban

Az App Directory, amely a Next.js projekt gyökerében, az `app` mappában található, egy alapvetően más megközelítést vezet be az útválasztás terén. Ahelyett, hogy közvetlenül a fájlokat rendelné az útvonalakhoz, az App Directory egy konvenció-alapú rendszert használ, ahol a mappák és speciális fájlok struktúrája határozza meg az alkalmazás útvonalait.

Ez a megközelítés számos kulcsfontosságú előnyt kínál:

Az App Directory útválasztási rendszerének kulcsfogalmai

Az App Directory útválasztási rendszerének hatékony használatához elengedhetetlen a működését megalapozó kulcsfogalmak megértése:

1. Útvonal szegmensek és mappák

Az `app` mappán belüli minden mappa egy útvonal szegmenst képvisel. A mappa neve megegyezik az URL-ben szereplő útvonal szegmenssel. Például egy `app/blog/posts` mappastruktúra a `/blog/posts` útvonalhoz fog tartozni.

Vegyük ezt a struktúrát:

app/
  blog/
    posts/
      page.js

Ez a struktúra egy útvonalat definiál a `/blog/posts` helyen. A `posts` mappán belüli `page.js` fájl az útvonal szegmens komponens, amely az adott útvonal tartalmát rendereli.

2. A `page.js` fájl: Az útvonal tartalmának renderelése

A page.js (vagy TypeScript esetén page.tsx) egy speciális fájl, amely meghatározza az adott útvonal szegmenshez renderelendő tartalmat. Ez az útvonal belépési pontja. Ennek a fájlnak alapértelmezett exportként egy React komponenst kell exportálnia.

Példa:

// app/blog/posts/page.js

export default function PostsPage() {
  return (
    <div>
      <h1>Blogbejegyzések</h1>
      <p>Itt fog megjelenni a blogbejegyzések listája.</p>
    </div>
  );
}

3. Layoutok (elrendezések): Megosztott UI definiálása

A Layoutok (elrendezések) lehetővé teszik olyan felhasználói felület definiálását, amely több oldalon vagy útvonal szegmensen is megosztható. Egy elrendezés tartalmazhat olyan elemeket, mint fejlécek, láblécek, oldalsávok vagy bármely más komponenst, amelynek konzisztensnek kell lennie az alkalmazás egy adott szakaszában. Az elrendezéseket a `layout.js` (vagy `layout.tsx`) fájllal definiáljuk.

Az elrendezések egymásba ágyazódnak. Ez azt jelenti, hogy a gyökér elrendezés (`app/layout.js`) az egész alkalmazást körbeveszi, a beágyazott elrendezések pedig specifikus útvonal szegmenseket. Amikor olyan útvonalak között navigálunk, amelyek ugyanazt az elrendezést használják, a Next.js megőrzi az elrendezés állapotát és elkerüli annak újrarenderelését, ami jobb teljesítményt és gördülékenyebb felhasználói élményt eredményez.

Példa:

// app/layout.js

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <header>
          <nav>
            <a href="/">Kezdőlap</a> |
            <a href="/blog">Blog</a>
          </nav>
        </header>
        <main>{children}</main>
        <footer>
          <p>Copyright 2023</p>
        </footer>
      </body>
    </html>
  );
}

Ebben a példában a `RootLayout` definiálja az alapvető HTML struktúrát, a fejlécet, a láblécet és a navigációt az egész alkalmazás számára. Bármely, az `app` mappán belül renderelt oldal körbe lesz véve ezzel az elrendezéssel.

4. Sablonok (Templates): Az állapot megőrzése útvonalak között

Az elrendezésekhez hasonlóan a sablonok (templates) is körbeveszik a gyermek útvonalakat. Azonban az elrendezésekkel ellentétben a sablonok minden egyes gyermek útvonalhoz új komponens példányt hoznak létre. Ez azt jelenti, hogy a sablon állapota nem marad meg, amikor a sablonon belüli útvonalak között navigálunk. A sablonok olyan esetekben hasznosak, amikor az állapotot vissza kell állítani vagy újra kell inicializálni az útvonalváltások során. Sablonok létrehozásához használja a template.js (vagy template.tsx) fájlt.

5. Útvonal csoportok (Route Groups): Útvonalak szervezése URL szegmensek nélkül

Az útvonal csoportok lehetővé teszik az útvonalak szervezését az App Directory-n belül anélkül, hogy befolyásolnák az URL struktúrát. Az útvonal csoportokat a mappa nevének zárójelbe tételével definiáljuk, pl. `(group-name)`. Ezek a zárójelek jelzik a Next.js-nek, hogy a mappát logikai csoportosítási mechanizmusként kezelje, nem pedig útvonal szegmensként.

Ez különösen hasznos nagy, sok útvonallal rendelkező alkalmazások szervezésénél. Például útvonal csoportokat használhatunk az alkalmazás különböző szakaszainak szétválasztására, mint például `(marketing)` és `(app)`. Ezek a csoportok csak a fájlstruktúrát befolyásolják, az URL útvonalakat nem.

Példa:

app/
  (marketing)/
    home/
      page.js  // Elérhető a /home címen
    about/
      page.js  // Elérhető a /about címen
  (app)/
    dashboard/
      page.js  // Elérhető a /dashboard címen

6. Dinamikus útvonalak: Változó szegmensek kezelése

A dinamikus útvonalak lehetővé teszik változó szegmensekkel rendelkező útvonalak létrehozását. Ez olyan esetekben hasznos, amikor adat alapján kell útvonalakat generálni, mint például blogbejegyzések, termékoldalak vagy felhasználói profilok. A dinamikus útvonal szegmenseket a szegmens nevének szögletes zárójelbe tételével definiáljuk, pl. `[id]`. Az `id` egy paramétert képvisel, amely a `page.js` komponensen belül érhető el.

Példa:

app/
  blog/
    [slug]/
      page.js

Ebben a példában a `[slug]` egy dinamikus útvonal szegmens. Egy `/blog/my-first-post` URL illeszkedne erre az útvonalra, és a `slug` paraméter értéke `my-first-post` lenne. A `slug` paramétert a `page.js` komponensen belül a `params` prop segítségével érheti el.

// app/blog/[slug]/page.js

export default function BlogPost({ params }) {
  const { slug } = params;
  return (
    <div>
      <h1>Blogbejegyzés: {slug}</h1>
      <p>A blogbejegyzés tartalma a következő sluggal: {slug}</p>
    </div>
  );
}

Ezen dinamikus útvonalak lehetséges értékeit generálnia kell. A Next.js a `generateStaticParams` funkciót biztosítja a statikus webhely generáláshoz (SSG) és a szerveroldali rendereléshez (SSR). Ez a funkció lehetővé teszi, hogy megadja, mely dinamikus útvonalakat kell előre renderelni a buildelés során.

// app/blog/[slug]/page.js

export async function generateStaticParams() {
  const posts = [
    { slug: 'elso-bejegyzesem' },
    { slug: 'masodik-bejegyzesem' },
  ];

  return posts.map((post) => ({ slug: post.slug }));
}

export default function BlogPost({ params }) {
  const { slug } = params;
  return (
    <div>
      <h1>Blogbejegyzés: {slug}</h1>
      <p>A blogbejegyzés tartalma a következő sluggal: {slug}</p>
    </div>
  );
}

7. Mindent elkapó szegmensek (Catch-All Segments): Ismeretlen útvonalak kezelése

A mindent elkapó szegmensek egy olyan dinamikus útvonal típus, amely lehetővé teszi tetszőleges számú szegmens illesztését egy URL-ben. Ezeket a szegmens nevének három ponttal való előtagolásával definiáljuk, pl. `[...path]`. A mindent elkapó szegmensek hasznosak rugalmas útvonalak létrehozásához, amelyek különféle URL struktúrákat képesek kezelni.

Példa:

app/
  docs/
    [...path]/
      page.js

Ebben a példában a `[...path]` egy mindent elkapó szegmens. Az olyan URL-ek, mint a `/docs/introduction`, `/docs/api/reference` és `/docs/examples/basic` mind illeszkednének erre az útvonalra. A `path` paraméter egy tömb lenne, amely az illesztett szegmenseket tartalmazza.

// app/docs/[...path]/page.js

export default function DocsPage({ params }) {
  const { path } = params;
  return (
    <div>
      <h1>Dokumentáció</h1>
      <p>Útvonal: {path.join('/')}</p>
    </div>
  );
}

8. Párhuzamos útvonalak (Parallel Routes): Több oldal egyidejű renderelése

A párhuzamos útvonalak lehetővé teszik több oldal egyidejű renderelését ugyanazon az elrendezésen belül. Ez különösen hasznos összetett UI minták létrehozásához, mint például több panellel rendelkező irányítópultok vagy az aktuális oldal tetején megjelenő modális párbeszédablakok. A párhuzamos útvonalakat a @ szimbólummal definiáljuk, pl. `@children`, `@modal`. Megadhatók közvetlenül az URL-ben, vagy a `useRouter` hook segítségével navigálhatunk hozzájuk.

Példa:

app/
  @children/
    page.js // A fő tartalmat rendereli
  @modal/
    login/
      page.js // A bejelentkezési modált rendereli

A párhuzamos útvonalak megjelenítéséhez használja a `` komponenst.

9. Elfogó útvonalak (Intercepting Routes): Kifinomult UI átmenetek létrehozása

Az elfogó útvonalak lehetővé teszik egy útvonal betöltését az alkalmazás egy másik részéből az aktuális útvonal kontextusában. Ezt kifinomult UI átmenetek létrehozására lehet használni, mint például egy modális párbeszédablak megjelenítése egy linkre kattintva anélkül, hogy elnavigálnánk az aktuális oldalról. A (...) szintaxissal definiáljuk őket.

Adatlekérdezés az App Directory-ban

Az App Directory új és továbbfejlesztett módokat vezet be az adatlekérdezésre, kihasználva a React Server Components és a `fetch` API beépített gyorsítótárazási és újraérvényesítési képességeit. Ez jobb teljesítményhez és egyszerűsített fejlesztési élményhez vezet. Mind a szerver-, mind a kliensoldali komponensek lekérhetnek adatokat, de a stratégia eltérő.

1. Adatlekérdezés szerver komponensekben

A szerver komponensek, amelyek az App Directory-ban az alapértelmezettek, közvetlenül lekérhetnek adatokat adatbázisokból vagy API-kból. Ez a komponens függvényen belül történik a renderelés előtt. Mivel a szerver komponensek a szerveren futnak, biztonságosan tartalmazhat titkos kulcsokat és hitelesítő adatokat anélkül, hogy azokat a kliensnek kiadnánk. A `fetch` API automatikusan memoizálva van, ami azt jelenti, hogy az azonos adatkérések deduplikálódnak, tovább javítva a teljesítményt.

// app/page.js

async function getData() {
  const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
  // A visszatérési érték *nem* szerializálódik
  // Visszaadhat Date, Map, Set, stb. objektumokat.

  if (!res.ok) {
    // Ez aktiválja a legközelebbi `error.js` hibahatárt (Error Boundary)
    throw new Error('Nem sikerült az adatlekérdezés');
  }

  return res.json();
}

export default async function Page() {
  const data = await getData();

  return <div>{data.title}</div>;
}

2. Adatlekérdezés kliens komponensekben

A kliens komponensek, amelyeket a fájl tetején lévő 'use client' direktíva jelez, a felhasználó böngészőjében futnak. A kliens komponensekben az adatlekérdezés általában a `useEffect` hook és egy olyan könyvtár, mint az `axios` vagy a `fetch` API használatát jelenti. A Server Actions biztonságos módot kínál a szerveradatok módosítására kliens komponensekből. Ez biztonságos módot kínál a kliens komponensek számára, hogy közvetlenül interakcióba lépjenek a szerveren lévő adatokkal anélkül, hogy az API végpontokat közvetlenül felfednék.

// app/components/ClientComponent.js
'use client';

import { useState, useEffect } from 'react';

export default function ClientComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    async function fetchData() {
      const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
      const data = await res.json();
      setData(data);
    }

    fetchData();
  }, []);

  if (!data) {
    return <div>Betöltés...</div>;
  }

  return <div>{data.title}</div>;
}

SEO szempontok az App Directory-val

Az App Directory szerver-központú megközelítése jelentős előnyöket kínál a SEO szempontjából. Mivel a tartalom a szerveren renderelődik, a keresőmotorok robotjai könnyen hozzáférhetnek és indexelhetik az oldal tartalmát. Íme néhány kulcsfontosságú SEO szempont:

Az App Directory útválasztási rendszerének használatának előnyei

A App Directory útválasztási rendszere számos előnyt kínál, amelyek javítják a fejlesztési folyamatot, növelik az alkalmazás teljesítményét és hozzájárulnak a jobb felhasználói élményhez. Vizsgáljuk meg ezeket az előnyöket részletesebben: * **Fokozott szervezettség és karbantarthatóság:** A fájl-alapú útválasztási rendszer eleve egy strukturált és szervezett kódbázist támogat. Az útvonalak közvetlen leképezésével a könyvtárstruktúrára a fejlesztők könnyen megérthetik az URL-ek és a megfelelő komponensek közötti kapcsolatot. Ez a tiszta struktúra leegyszerűsíti a kódbázisban való navigációt, és megkönnyíti az alkalmazás karbantartását és frissítését az idő múlásával. * **Jobb teljesítmény a szerver komponensek révén:** Az App Directory a React Server Components-t használja a tartalom szerveroldali renderelésére, csökkentve a böngészőben letöltendő és végrehajtandó JavaScript mennyiségét. Ez gyorsabb kezdeti oldalbetöltési időket és jobb általános teljesítményt eredményez, különösen a lassabb internetkapcsolattal vagy kevésbé erőteljes eszközökkel rendelkező felhasználók számára. * **Egyszerűsített adatlekérdezés és -kezelés:** Az App Directory leegyszerűsíti az adatlekérdezést azáltal, hogy lehetővé teszi a fejlesztők számára az adatok közvetlen lekérdezését a szerver komponenseken belül. Ez kiküszöböli a bonyolult kliensoldali adatlekérdezési logika szükségességét, és csökkenti az érzékeny adatok kliens felé történő kiszivárgásának kockázatát. * **Deklaratív és intuitív útválasztás:** A fájl-alapú útválasztási rendszer deklaratív és intuitív módot biztosít az alkalmazás útvonalainak meghatározására. Egyszerűen fájlok és könyvtárak létrehozásával az `app` könyvtáron belül a fejlesztők könnyen definiálhatják alkalmazásuk navigációjának szerkezetét és viselkedését. Ez a megközelítés csökkenti a bonyolult konfigurációs fájlok szükségességét, és könnyebben érthetővé és használhatóvá teszi az útválasztási rendszert. * **Beépített elrendezések és sablonok a konzisztens felhasználói felületért:** Az App Directory beépített támogatást nyújt az elrendezésekhez és sablonokhoz, amelyek lehetővé teszik a fejlesztők számára, hogy több oldalon konzisztens, megosztott UI elemeket definiáljanak. Ez csökkenti a kódduplikációt, és megkönnyíti a konzisztens megjelenés fenntartását az egész alkalmazásban. * **Fejlett útválasztási funkciók komplex felhasználási esetekhez:** Az App Directory számos fejlett útválasztási funkciót kínál, mint például dinamikus útvonalak, mindent elkapó szegmensek, párhuzamos útvonalak és elfogó útvonalak. Ezek a funkciók lehetővé teszik a fejlesztők számára, hogy bonyolult útválasztási forgatókönyveket kezeljenek, és olyan kifinomult UI mintákat hozzanak létre, amelyeket hagyományos útválasztási rendszerekkel nehéz vagy lehetetlen lenne elérni. ## Gyakorlati példák az App Directory útválasztás működésére Az App Directory útválasztási rendszerének erejének és rugalmasságának szemléltetésére nézzünk meg néhány gyakorlati példát: ### 1. Egyszerű blog építése dinamikus útvonalakkal Vegyünk egy blog alkalmazást, ahol minden blogbejegyzésnek saját egyedi URL-je van a slugja alapján. Az App Directory segítségével ez könnyen megvalósítható dinamikus útvonalakkal: ``` app/ blog/ [slug]/ page.js ``` A `[slug]` könyvtár egy dinamikus útvonal szegmenst képvisel, amely bármely URL-re illeszkedik a `/blog/` útvonal alatt. A `[slug]` könyvtáron belüli `page.js` fájl fogja renderelni a megfelelő blogbejegyzés tartalmát. ```javascript // app/blog/[slug]/page.js export async function generateStaticParams() { // Az összes blogbejegyzés lekérdezése az adatbázisból vagy API-ból const posts = await fetchPosts(); // A bejegyzések leképezése egy slug paraméterekből álló tömbre return posts.map((post) => ({ slug: post.slug })); } export default async function BlogPost({ params }) { const { slug } = params; // A megfelelő sluggal rendelkező blogbejegyzés lekérdezése const post = await fetchPost(slug); if (!post) { return <div>A bejegyzés nem található</div>; } return ( <article> <h1>{post.title}</h1> <p>{post.content}</p> </article> ); } ``` Ez a példa bemutatja, hogyan lehet dinamikus útvonalakat használni egyedi oldalak létrehozására minden blogbejegyzéshez egyszerű és hatékony módon. ### 2. Modális párbeszédablak megvalósítása elfogó útvonalakkal Tegyük fel, hogy egy modális párbeszédablakot szeretne megvalósítani, amely akkor jelenik meg, amikor a felhasználó egy linkre kattint, anélkül, hogy elnavigálna az aktuális oldalról. Ezt elfogó útvonalakkal lehet elérni: ``` app/ (.)photos/ [id]/ @modal/ page.js page.js ``` Itt a `(.)photos/[id]/@modal/page.js` elfogja a `photos/[id]` címre irányuló kéréseket az aktuális oldalról. Amikor a felhasználó egy adott fotó linkjére kattint, a modális párbeszédablak az aktuális oldal tetején jelenik meg, ahelyett, hogy egy új oldalra navigálna. ### 3. Irányítópult elrendezés létrehozása párhuzamos útvonalakkal Képzelje el, hogy egy irányítópult alkalmazást épít több panellel, amelyeket egyidejűleg kell renderelni. Párhuzamos útvonalakkal érhető el ez az elrendezés: ``` app/ @analytics/ page.js // Analitikai irányítópult @settings/ page.js // Beállítások panel page.js // Fő irányítópult elrendezés ```

Ebben a struktúrában az `@analytics` és a `@settings` párhuzamos útvonalakat képviselnek, amelyek a fő irányítópult elrendezésen belül renderelődnek. Minden párhuzamos útvonalnak saját page.js fájlja van, amely meghatározza az adott panel tartalmát. Az elrendezés döntheti el, hova helyezi ezeket a <Slot> komponens segítségével.

Migráció a Pages Directory-ról az App Directory-ra

Egy meglévő Next.js alkalmazás migrálása a Pages Directory-ról az App Directory-ra gondos tervezést és végrehajtást igényel. Bár az App Directory jelentős előnyöket kínál, új koncepciókat és mintákat is bevezet, amelyeket a fejlesztőknek meg kell érteniük. Íme egy lépésről-lépésre útmutató, amely segít a migrálási folyamatban:

  1. Értse meg a kulcsfontosságú különbségeket: Mielőtt elkezdené a migrációt, győződjön meg róla, hogy alaposan megérti a Pages Directory és az App Directory közötti kulcsfontosságú különbségeket, beleértve az útválasztási rendszert, az adatlekérdezést és a komponens architektúrát.
  2. Hozzon létre egy `app` könyvtárat: Hozzon létre egy új, `app` nevű könyvtárat a Next.js projekt gyökerében. Ez a könyvtár fogja tartalmazni az összes komponenst és útvonalat, amelyek az App Directory részét képezik.
  3. Migrálja az útvonalakat fokozatosan: Kezdje az útvonalak fokozatos, egyenkénti migrálásával. Ez lehetővé teszi az egyes útvonalak egyéni tesztelését és hibakeresését, minimalizálva a hibák bevezetésének kockázatát.
  4. Alakítsa át a komponenseket szerver komponensekké: Alakítsa át a meglévő React komponenseit szerver komponensekké, amikor csak lehetséges. Ez javítja a teljesítményt és csökkenti a böngészőben letöltendő és végrehajtandó JavaScript mennyiségét.
  5. Frissítse az adatlekérdezési logikát: Frissítse az adatlekérdezési logikát, hogy kihasználja az App Directory beépített adatlekérdezési képességeit. Ez magában foglalhatja az adatlekérdezési kód áthelyezését a kliens komponensekből a szerver komponensekbe.
  6. Implementáljon elrendezéseket és sablonokat: Implementáljon elrendezéseket és sablonokat a több oldalon konzisztens, megosztott UI elemek definiálásához.
  7. Teszteljen alaposan: Alaposan teszteljen minden migrált útvonalat, hogy megbizonyosodjon arról, hogy helyesen működik, és nincsenek regressziók.
  8. Távolítsa el a `pages` könyvtárat: Miután az összes útvonalat migrálta, eltávolíthatja a `/pages` könyvtárat.

Következtetés

A Next.js App Directory jelentős fejlődést képvisel a fájl-alapú útválasztásban, szervezettebb, teljesítmény-orientáltabb és rugalmasabb módot kínálva a fejlesztőknek a modern webalkalmazások építésére. A kulcsfogalmak megértésével és az új funkciók elfogadásával a fejlesztők kihasználhatják az App Directory-t, hogy kivételes felhasználói élményt teremtsenek és nagyobb termelékenységet érjenek el. A Next.js fejlesztés jövője az App Directory-ban rejlik, és annak elfogadása stratégiai lépés a csúcstechnológiás webalkalmazások építésében. Ez egy erőteljes eszköz a fejlesztők számára világszerte.

Ahogy a Next.js ökoszisztéma tovább fejlődik, az App Directory készen áll arra, hogy a robusztus, skálázható és teljesítmény-orientált webalkalmazások építésének szabványává váljon. Fogadja el a változást, fedezze fel a lehetőségeket, és aknázza ki a Next.js teljes potenciálját!