Mi az a Next.js? Egyszerű útmutató alkalmazásépítőknek

A Next.js webhelyek és webalkalmazások építésére szolgáló keretrendszer, amely a Reactra épül. A React a felület építőelemeit adja — gombokat, űrlapokat, listákat. A Next.js hozzáadja köréjük a weboldal többi részét: oldalakat és URL-eket, oldalak szerveroldali renderelését, hogy kész állapotban érkezzenek meg, adatok betöltését, és háttérkód futtatását ugyanabban a projektben. Nyílt forráskódú, a Vercel nevű cég készíti, és az egyik legszélesebb körben használt módja React-oldalak építésének.

Miért fontos a Next.js AI-val építve

Amikor egy alkalmazást leírsz egy AI-építőnek, az műszaki alapot választ. Ez a választás később befolyásolja azt, ami számodra fontos:

• Keresési láthatóság. Egy nyilvános oldal, amelynek a Google-ben kell szerepelnie, abból profitál, ha valódi HTML-t küld, és ezt a Next.js jól csinálja.
• Hol él a háttérrendszer. A Next.js lehetővé teszi, hogy a frontend oldalak és a szerveroldali kód (például „ezt az űrlapot mentsd el” vagy „hívd a fizetési API-t”) egy projektben legyenek.
• Tárhely. Egy szerveres funkciókat használó Next.js-alkalmazásnak szerver kell, amelyen fut, míg egy egyszerű Vite-alkalmazás statikus fájlokként is kiszolgálható.

A Mythex új projekteket alapértelmezetten Vite + React + TypeScript + Tailwind alapon indít, és Next.js-t akkor használ, ha kéred — elég az első promptban a „Use Next.js” (hogyan választódik a technológia). Ezért érdemes tudni, mikor érdemes ezt kérni.

Hétköznapi hasonlat

Ha a React egy doboz kiváló minőségű Lego-kocka, a Next.js egy Lego-készlet, amelyben benne van a útmutató, az alaplap és az ajtók meg a vezetékek alkatrészei.

Ugyanazt a házat ki tudnád rakni laza kockákból is — csak neked kellene eldöntened, hogyan kapcsolódnak a szobák, hol van a bejárati ajtó és hogyan jut be a víz. A Next.js ezeket a döntéseket szabványos módon hozza meg helyetted, így minden Next.js-projekt hasonlóan épül fel, és egy új fejlesztő (vagy egy AI) gyorsan megtalálja magát benne.

Mit ad a Next.js a Reacthez

A Next.js kétféleképpen szervezi az oldalakat. Az App Router (az app/ mappa) az újabb, és támogatja a szerver-komponenseket. A Pages Router (a pages/ mappa) az eredeti, és továbbra is támogatott. Az új projektek általában az App Routert használják. Ha az AI-építőd kódja vagy egy oktatóanyag ismeretlennek tűnik, gyakran ez az oka.

Példa: egy nyilvános kávézó-könyvtár

Képzeld el, hogy egy oldalon a városod kávézóit listázod, kávézónként egy oldallal, és azt szeretnéd, hogy megjelenjenek a keresési találatokban.

Egy kávézó Next.js-oldala nagyjából így nézhet ki:

// app/cafes/[slug]/page.tsx  →  /cafes/blue-door, /cafes/hilltop ...
export default async function CafePage({ params }) {
  const { slug } = await params;
  const cafe = await db.cafe.findUnique({ where: { slug } });
  return (
    <main>
      <h1>{cafe.name}</h1>
      <p>{cafe.address}</p>
    </main>
  );
}

Mi történik, amikor valaki (vagy a Google) meglátogatja a /cafes/blue-door címet:

1. A Next.js összeilleszti az URL-t ezzel a fájllal. Az [slug] mappa azt jelenti: „bármelyik kávézó”.
2. A komponens a szerveren fut, kiolvassa a kávézót az adatbázisból, és felépíti a HTML-t.
3. A böngésző egy teljes oldalt kap a kávézó nevével és címével — nem kell várni, hogy a JavaScript lekérje az adatokat.

Egy sima kliensoldali React-alkalmazásnál a böngésző először egy szinte üres oldalt kapna, majd letöltené a JavaScriptet, lekérné a kávézót, és csak utána mutatná. A keresőmotorok ezt gyakran kezelik, de a teljes oldal megbízhatóbb. Lásd: SEO AI-val épített weboldalakhoz.

Hasonlítsd ezt egy belépés mögötti, csak munkatársaknak szánt műszerfallal: a keresőmotorok úgysem látják, így a szerveroldali renderelés kevesebb előnyt hoz, és egy egyszerűbb Vite-alkalmazás gyakran jobb illeszkedés.

Kulcsfogalmak

Gyakori tévhitek

• „A Next.js helyettesíti a Reactot.” Nem. A Reactot használja. A komponenseid továbbra is React-komponensek.
• „A Next.js mindig a jobb választás.” Képesebb, de több mindent kell érteni hozzá. A szerveroldali renderelés, a gyorsítótárazás és a szerver- és kliensoldali kód különbsége gyakori forrása zavaros hibáknak. Egy főleg bejelentkezés mögött működő alkalmazásnál egy sima React-alkalmazás gyakran egyszerűbb.
• „A Next.js csak a Verceleken fut.” Nyílt forráskódú, és bármely Node.js-szerveren vagy Docker-konténerben futhat. Teljesen statikus export is lehetséges, ha nem használsz szerveroldali funkciókat.
• „A Next.js használata garantálja a jó SEO-t.” Az olvasható oldalakat könnyebbé teszi. A rangsorolás továbbra is a címektől, a tartalomtól, a sebességtől és a linkektől függ.
• „A Next.js szerverkódja automatikusan privát.” A kliensnek jelölt kód a böngészőbe kerül. A titkoknak szerveroldali kódban és környezeti változókban kell maradniuk.

Mit kérdezz az AI-építődtől

• „Használj Next.js-t App Routerrel” — az első promptban, ha ezt szeretnéd.
• „Mely oldalak épülnek szerveren, melyek statikusak, és melyek futnak a böngészőben — és miért?”
• „A nyilvános marketing- és listaoldalak legyenek szerveroldalon renderelve vagy statikusak, megfelelő címekkel és leírásokkal.”
• „Az API-kulcsok szerveroldali kódban és környezeti változókban maradjanak. Mutasd meg, hol olvassa be őket mindegyik.”
• „Szükséges ehhez az alkalmazáshoz a Next.js, vagy egy Vite + React egyszerűbb lenne ahhoz, amit építünk?”

Next.js a Mythexben

A Mythex alapértelmezetten Vite + React + TypeScript + Tailwind alapot használ, és Next.js-re vált, ha a promptodban kéred; ha már az elején megnevezed, kreditet spórolsz, mintha később váltanál. Az alkalmazást az élő előnézetben látod, a Publish pedig élő URL-re telepíti anélkül, hogy neked kellene tárhelyet beállítanod. A Mythex dokumentációja megjegyzi, hogy a kliensoldalon renderelt egyoldalas alkalmazások SEO-szempontból gyengébbek, mint a szerveroldalon renderelt vagy statikus HTML-oldalak, ezért egy marketingoldalnál, ahol a keresés számít, érdemes ezt előre jelezni (SEO az alkalmazásodhoz).

Kérdések