Lietuvių

Atraskite mastelio keitimo galimybes ir dinamiškas vartotojo sąsajas su Next.js. Mūsų išsamus gidas apima maršrutų grupes organizavimui ir lygiagrečius maršrutus sudėtingiems prietaisų skydeliams. Kelkite savo lygį dabar!

„Next.js App Router“ įvaldymas: išsami maršrutų grupių ir lygiagrečių maršrutų architektūros analizė

„Next.js App Router“ išleidimas žymėjo paradigmos pokytį, kaip programuotojai kuria žiniatinklio aplikacijas su populiaria „React“ karkasu. Atsitraukdamas nuo failais pagrįstų „Pages Router“ konvencijų, „App Router“ pristatė galingesnį, lankstesnį ir į serverį orientuotą modelį. Ši evoliucija suteikia mums galimybę kurti labai sudėtingas ir našias vartotojo sąsajas su didesne kontrole ir organizacija. Tarp labiausiai transformuojančių pristatytų funkcijų yra maršrutų grupės (Route Groups) ir lygiagretūs maršrutai (Parallel Routes).

Programuotojams, siekiantiems kurti verslo lygio aplikacijas, šių dviejų koncepcijų įvaldymas yra ne tik naudingas – jis yra būtinas. Jos sprendžia dažnas architektūrines problemas, susijusias su maketų valdymu, maršrutų organizavimu ir dinamiškų, kelių skydelių sąsajų, tokių kaip prietaisų skydeliai, kūrimu. Šis gidas pateikia išsamią maršrutų grupių ir lygiagrečių maršrutų apžvalgą, pereinant nuo pamatinių koncepcijų iki pažangių įgyvendinimo strategijų ir geriausių praktikų, skirtų pasaulinei programuotojų auditorijai.

„Next.js App Router“ supratimas: trumpas priminimas

Prieš pasinerdami į detales, trumpai prisiminkime pagrindinius „App Router“ principus. Jo architektūra yra pagrįsta katalogų sistema, kur aplankai apibrėžia URL segmentus. Specialūs failai šiuose aplankuose apibrėžia to segmento vartotojo sąsają ir elgseną:

Ši struktūra, kartu su numatytuoju „React Server Components“ (RSC) naudojimu, skatina į serverį orientuotą požiūrį, kuris gali žymiai pagerinti našumą ir duomenų gavimo modelius. Maršrutų grupės ir lygiagretūs maršrutai yra pažangios konvencijos, kurios remiasi šiuo pagrindu.

Maršrutų grupių demistifikavimas: projekto organizavimas tvarkai ir masteliui

Augant aplikacijai, maršrutų skaičius gali tapti sunkiai valdomas. Galite turėti rinkodaros puslapių rinkinį, kitą – vartotojo autentifikavimui, ir trečią – pagrindiniam aplikacijos prietaisų skydeliui. Logiškai, tai yra atskiros dalys, bet kaip jas organizuoti failų sistemoje, neužteršiant URL? Būtent šią problemą sprendžia maršrutų grupės.

Kas yra maršrutų grupės?

Maršruto grupė yra mechanizmas, leidžiantis organizuoti jūsų failus ir maršruto segmentus į logines grupes nepaveikiant URL struktūros. Jūs sukuriate maršruto grupę, apgaubdami aplanko pavadinimą skliausteliais, pavyzdžiui, (marketing) arba (app).

Aplanko pavadinimas skliausteliuose yra skirtas tik organizaciniams tikslams. „Next.js“ jį visiškai ignoruoja nustatant URL kelią. Pavyzdžiui, failas, esantis app/(marketing)/about/page.js, bus pasiekiamas adresu /about, o ne /(marketing)/about.

Pagrindiniai maršrutų grupių panaudojimo atvejai ir privalumai

Nors paprastas organizavimas yra privalumas, tikroji maršrutų grupių galia slypi jų gebėjime padalinti jūsų aplikaciją į dalis su skirtingais, bendrais maketais.

1. Skirtingų maketų kūrimas maršruto segmentams

Tai yra labiausiai paplitęs ir galingiausias panaudojimo atvejis. Įsivaizduokite žiniatinklio aplikaciją su dviem pagrindinėmis dalimis:

Be maršrutų grupių, skirtingų šakninių maketų pritaikymas šioms dalims būtų sudėtingas. Su maršrutų grupėmis tai yra neįtikėtinai intuityvu. Kiekvienoje grupėje galite sukurti unikalų layout.js failą.

Štai tipiška failų struktūra šiam scenarijui:

app/
├── (marketing)/
│   ├── layout.js      // Viešas maketas su rinkodaros antrašte/porašte
│   ├── page.js        // Atvaizduojamas ties '/'
│   └── about/
│       └── page.js    // Atvaizduojamas ties '/about'
├── (app)/
│   ├── layout.js      // Prietaisų skydelio maketas su šonine juosta
│   ├── dashboard/
│   │   └── page.js    // Atvaizduojamas ties '/dashboard'
│   └── settings/
│       └── page.js    // Atvaizduojamas ties '/settings'
└── layout.js          // Šakninis maketas (pvz., skirtas <html> ir <body> žymėms)

Šioje architektūroje:

2. Segmento atsisakymas bendro maketo

Kartais tam tikram puslapiui ar daliai reikia visiškai atsisakyti aukštesnio lygio maketo. Dažnas pavyzdys yra atsiskaitymo procesas arba specialus nukreipimo puslapis, kuriame neturėtų būti pagrindinės svetainės navigacijos. Tai galite pasiekti, patalpindami maršrutą grupėje, kuri nedalija aukštesnio lygio maketo. Nors tai skamba sudėtingai, tai tiesiog reiškia, kad maršruto grupei suteikiamas nuosavas aukščiausio lygio layout.js failas, kuris neatvaizduoja `children` iš šakninio maketo.

Praktinis pavyzdys: kelių maketų aplikacijos kūrimas

Sukurkime minimalią aukščiau aprašytos rinkodaros/aplikacijos struktūros versiją.

1. Šakninis maketas (app/layout.js)

Šis maketas yra minimalus ir taikomas kiekvienam puslapiui. Jis apibrėžia esminę HTML struktūrą.

// app/layout.js
export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

2. Rinkodaros maketas (app/(marketing)/layout.js)

Šiame makete yra vieša antraštė ir poraštė.

// app/(marketing)/layout.js
export default function MarketingLayout({ children }) {
  return (
    <div>
      <header>Rinkodaros antraštė</header>
      <main>{children}</main>
      <footer>Rinkodaros poraštė</footer>
    </div>
  );
}

3. Aplikacijos prietaisų skydelio maketas (app/(app)/layout.js)

Šis maketas turi kitokią struktūrą, su šonine juosta autentifikuotiems vartotojams.

// app/(app)/layout.js
export default function AppLayout({ children }) {
  return (
    <div style={{ display: 'flex' }}>
      <aside style={{ width: '200px', borderRight: '1px solid #ccc' }}>
        Prietaisų skydelio šoninė juosta
      </aside>
      <main style={{ flex: 1, padding: '20px' }}>{children}</main>
    </div>
  );
}

Su šia struktūra, naršant į /about, puslapis bus atvaizduotas su `MarketingLayout`, o naršant į /dashboard, jis bus atvaizduotas su `AppLayout`. URL išlieka švarus ir semantiškas, o mūsų projekto failų struktūra yra puikiai organizuota ir keičiamo mastelio.

Dinamiškų vartotojo sąsajų atrakinimas su lygiagrečiais maršrutais

Nors maršrutų grupės padeda organizuoti atskiras aplikacijos dalis, lygiagretūs maršrutai sprendžia kitą iššūkį: kelių, nepriklausomų puslapio rodinių rodymą viename makete. Tai yra dažnas reikalavimas sudėtingiems prietaisų skydeliams, socialinių tinklų srautams ar bet kokiai vartotojo sąsajai, kur skirtingus skydelius reikia atvaizduoti ir valdyti vienu metu.

Kas yra lygiagretūs maršrutai?

Lygiagretūs maršrutai leidžia vienu metu atvaizduoti vieną ar daugiau puslapių tame pačiame makete. Šie maršrutai yra apibrėžiami naudojant specialią aplankų konvenciją, vadinamą lizdais (slots). Lizdai sukuriami naudojant @aplankoPavadinimas sintaksę. Jie nėra URL struktūros dalis; vietoj to, jie automatiškai perduodami kaip savybės (props) artimiausiam bendram tėviniam `layout.js` failui.

Pavyzdžiui, jei turite maketą, kuriame reikia rodyti komandos veiklos srautą ir analitikos diagramą vieną šalia kitos, galite apibrėžti du lizdus: `@team` ir `@analytics`.

Pagrindinė idėja: lizdai

Galvokite apie lizdus kaip apie pavadintas vietas jūsų makete. Maketo failas aiškiai priima šiuos lizdus kaip savybes ir nusprendžia, kur juos atvaizduoti.

Apsvarstykite šį maketo komponentą:

// Maketas, kuris priima du lizdus: 'team' ir 'analytics'
export default function DashboardLayout({ children, team, analytics }) {
  return (
    <div>
      {children}
      <div style={{ display: 'flex' }}>
        {team}
        {analytics}
      </div>
    </div>
  );
}

Čia `children`, `team` ir `analytics` yra visi lizdai. `children` yra numanomas lizdas, kuris atitinka standartinį `page.js` tame pačiame kataloge. `team` ir `analytics` yra aiškūs lizdai, kurie turi būti sukurti su `@` priešdėliu failų sistemoje.

Pagrindinės savybės ir privalumai

Realaus pasaulio scenarijus: sudėtingo prietaisų skydelio kūrimas

Sukurkime prietaisų skydelį URL adresu /dashboard. Jame bus pagrindinė turinio sritis, komandos veiklos skydelis ir našumo analitikos skydelis.

Failų struktūra:

app/
└── dashboard/
    ├── @analytics/
    │   ├── page.js          // Vartotojo sąsaja analitikos lizdui
    │   └── loading.js     // Įkėlimo sąsaja specialiai analitikai
    ├── @team/
    │   └── page.js          // Vartotojo sąsaja komandos lizdui
    ├── layout.js            // Maketas, kuris organizuoja lizdus
    └── page.js              // Numanomas 'children' lizdas (pagrindinis turinys)

1. Prietaisų skydelio maketas (app/dashboard/layout.js)

Šis maketas priima ir išdėsto tris lizdus.

// app/dashboard/layout.js
export default function DashboardLayout({ children, analytics, team }) {
  const isLoggedIn = true; // Pakeiskite realia autentifikavimo logika

  return isLoggedIn ? (
    <div>
      <h1>Pagrindinis prietaisų skydelis</h1>
      {children}
      <div style={{ marginTop: '20px', display: 'grid', gridTemplateColumns: '1fr 1fr', gap: '20px' }}>
        <div style={{ border: '1px solid blue', padding: '10px' }}>
          <h2>Komandos veikla</h2>
          {team}
        </div>
        <div style={{ border: '1px solid green', padding: '10px' }}>
          <h2>Našumo analitika</h2>
          {analytics}
        </div>
      </div>
    </div>
  ) : (
    <div>Prašome prisijungti, norėdami peržiūrėti prietaisų skydelį.</div>
  );
}

2. Lizdų puslapiai (pvz., app/dashboard/@analytics/page.js)

Kiekvieno lizdo page.js faile yra to konkretaus skydelio vartotojo sąsaja.

// app/dashboard/@analytics/page.js
async function getAnalyticsData() {
  // Imituoti tinklo užklausą
  await new Promise(resolve => setTimeout(resolve, 3000));
  return { views: '1.2M', revenue: '$50,000' };
}

export default async function AnalyticsPage() {
  const data = await getAnalyticsData();
  return (
    <div>
      <p>Puslapio peržiūros: {data.views}</p>
      <p>Pajamos: {data.revenue}</p>
    </div>
  );
}

// app/dashboard/@analytics/loading.js
export default function Loading() {
  return <p>Kraunami analitikos duomenys...</p>;
}

Su šia sąranka, kai vartotojas pereina į /dashboard, „Next.js“ atvaizduos `DashboardLayout`. Maketas gaus atvaizduotą turinį iš dashboard/page.js, dashboard/@team/page.js ir dashboard/@analytics/page.js kaip savybes ir atitinkamai juos išdėstys. Svarbiausia, kad analitikos skydelis rodys savo `loading.js` būseną 3 sekundes, neblokuodamas likusios prietaisų skydelio dalies atvaizdavimo.

Neatitinkančių maršrutų tvarkymas su default.js

Iškyla svarbus klausimas: kas nutinka, jei „Next.js“ negali gauti aktyvios lizdo būsenos dabartiniam URL? Pavyzdžiui, pradinio įkėlimo ar puslapio perkrovimo metu URL gali būti /dashboard, kuris nepateikia konkrečių nurodymų, ką rodyti @team ar `@analytics` lizduose. Pagal nutylėjimą „Next.js“ atvaizduotų 404 klaidą.

Norėdami to išvengti, galime pateikti atsarginę vartotojo sąsają, sukurdami default.js failą lygiagretaus maršruto viduje.

Pavyzdys:

// app/dashboard/@analytics/default.js
export default function DefaultAnalyticsPage() {
  return (
    <div>
      <p>Nepasirinkta jokių analitikos duomenų.</p>
    </div>
  );
}

Dabar, jei analitikos lizdas neatitinka, „Next.js“ atvaizduos default.js turinį, o ne 404 puslapį. Tai yra būtina norint sukurti sklandžią vartotojo patirtį, ypač pradinio sudėtingos lygiagrečių maršrutų sąrankos įkėlimo metu.

Maršrutų grupių ir lygiagrečių maršrutų derinimas pažangioms architektūroms

Tikroji „App Router“ galia atsiskleidžia, kai derinate jo funkcijas. Maršrutų grupės ir lygiagretūs maršrutai puikiai veikia kartu, kurdami sudėtingas ir labai organizuotas aplikacijų architektūras.

Panaudojimo atvejis: daugiamodalė turinio peržiūros programa

Įsivaizduokite platformą, pavyzdžiui, medijos galeriją ar dokumentų peržiūros programą, kur vartotojas gali peržiūrėti elementą, bet taip pat atidaryti modalinį langą, kad pamatytų jo detales, neprarasdamas fono puslapio konteksto. Tai dažnai vadinama „perimančiu maršrutu“ (Intercepting Route) ir yra galingas modelis, pagrįstas lygiagrečiais maršrutais.

Sukurkime nuotraukų galeriją. Paspaudus nuotrauką, ji atsidaro modaliniame lange. Bet jei atnaujinsite puslapį arba pereisite tiesiai į nuotraukos URL, turėtų būti rodomas specialus puslapis tai nuotraukai.

Failų struktūra:

app/
├── @modal/(..)(..)photos/[id]/page.js  // Perimtas maršrutas modaliniam langui
├── photos/
│   └── [id]/
│       └── page.js                  // Specialus nuotraukos puslapis
├── layout.js                        // Šakninis maketas, kuris priima @modal lizdą
└── page.js                          // Pagrindinis galerijos puslapis

Paaiškinimas:

Šis modelis derina lygiagrečius maršrutus (`@modal` lizdą) su pažangiomis maršrutizavimo konvencijomis, kad sukurtų sklandžią vartotojo patirtį, kurią būtų labai sudėtinga įgyvendinti rankiniu būdu.

Geriausios praktikos ir dažniausios klaidos

Maršrutų grupių geriausios praktikos

Lygiagrečių maršrutų geriausios praktikos

Dažniausios klaidos, kurių reikia vengti

Išvada: kuriant ateities žiniatinklio aplikacijas

„Next.js App Router“ su tokiomis funkcijomis kaip maršrutų grupės ir lygiagretūs maršrutai suteikia tvirtą ir keičiamo mastelio pagrindą šiuolaikiniam žiniatinklio kūrimui. Maršrutų grupės siūlo elegantišką sprendimą kodo organizavimui ir skirtingų maketų taikymui, nekenkiant URL semantikai. Lygiagretūs maršrutai atveria galimybę kurti dinamiškas, kelių skydelių sąsajas su nepriklausomomis būsenomis – tai, kas anksčiau buvo pasiekiama tik per sudėtingą kliento pusės būsenos valdymą.

Suprasdami ir derindami šiuos galingus architektūrinius modelius, galite pereiti nuo paprastų svetainių prie sudėtingų, našų ir lengvai prižiūrimų aplikacijų, atitinkančių šiandienos vartotojų poreikius. Mokymosi kreivė gali būti statesnė nei su klasikiniu „Pages Router“, tačiau nauda aplikacijos architektūros ir vartotojo patirties požiūriu yra didžiulė. Pradėkite eksperimentuoti su šiomis koncepcijomis savo kitame projekte ir atskleiskite visą „Next.js“ potencialą.

„Next.js App Router“ įvaldymas: išsami maršrutų grupių ir lygiagrečių maršrutų architektūros analizė | MLOG