├── .github
└── ISSUE_TEMPLATE
│ ├── bug_report.md
│ └── feature_request.md
├── 1-react-essentials
└── Readme.md
├── 2-routing
├── 1-defining-routes
│ └── Readme.md
├── 10-route-handlers
│ └── Readme.md
├── 11-middleware
│ └── Readme.md
├── 12-project-organization
│ └── Readme.md
├── 13-internationalization
│ └── Readme.md
├── 2-pages-and-layouts
│ └── Readme.md
├── 3-linking-and-navigating
│ └── Readme.md
├── 4-route-groups
│ └── Readme.md
├── 5-dynamic-routes
│ └── Readme.md
├── 6-loading-UI-and-treaming
│ └── Readme.md
├── 7-error-handling
│ └── Readme.md
├── 8-paralel-routes
│ └── Readme.md
├── 9-intercepting-routes
│ └── Readme.md
└── Readme.md
├── 3-rendering
├── 1-static-and-dynamic-rendering
│ └── Readme.md
├── 2-edge-and-nodejs-runtimes
│ └── Readme.md
└── Readme.md
├── 4-data-fetching
├── 1-fetching
│ └── Readme.md
├── 2-caching
│ └── Readme.md
├── 3-revalidating
│ └── Readme.md
├── 4-server-actions
│ └── Readme.md
└── Readme.md
├── 5-styling
├── 1-css-modules
│ └── Readme.md
├── 2-tailwind-css
│ └── Readme.md
├── 3-css-in-js
│ └── Readme.md
├── 4-sass
│ └── Readme.md
└── Readme.md
├── 6-optimizing
├── 1-images
│ └── Readme.md
├── 2-fonts
│ └── readme.md
├── 3-scripts
│ └── Readme.md
├── 4-metadata
│ └── Readme.md
├── 5-static-assets
│ └── Readme.md
├── 6-lazy-loading
│ └── Readme.md
├── 7-analytics
│ └── Readme.md
├── 8-open-telemetery
│ └── Readme.md
├── 9-instrumentation
│ └── Readme.md
└── Readme.md
├── 7-configuring
├── 1-typescript
│ └── Readme.md
├── 2-eslint
│ └── Readme.md
├── 3-enviroment-variables
│ └── Readme.md
├── 4-absolute-imports-and-module-path-aliases
│ └── Readme.md
├── 5-MDX
│ └── Readme.md
├── 6-src-directory
│ └── Readme.md
├── 7-draft-mode
│ └── Readme.md
└── Readme.md
├── 8-deploying
├── 1-static-exports
│ └── Readme.md
└── Readme.md
├── 9-upgrading
├── 1-codemods
│ └── Readme.md
├── 2-app-router-migration
│ └── readme.md
└── Readme.md
├── CONTRIBUTIONS.md
└── README.md
/.github/ISSUE_TEMPLATE/bug_report.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Bug report
3 | about: Create a report to help us improve
4 | title: ''
5 | labels: ''
6 | assignees: ''
7 |
8 | ---
9 |
10 | **Describe the bug**
11 | A clear and concise description of what the bug is.
12 |
13 | **To Reproduce**
14 | Steps to reproduce the behavior:
15 | 1. Go to '...'
16 | 2. Click on '....'
17 | 3. Scroll down to '....'
18 | 4. See error
19 |
20 | **Expected behavior**
21 | A clear and concise description of what you expected to happen.
22 |
23 | **Screenshots**
24 | If applicable, add screenshots to help explain your problem.
25 |
26 | **Desktop (please complete the following information):**
27 | - OS: [e.g. iOS]
28 | - Browser [e.g. chrome, safari]
29 | - Version [e.g. 22]
30 |
31 | **Smartphone (please complete the following information):**
32 | - Device: [e.g. iPhone6]
33 | - OS: [e.g. iOS8.1]
34 | - Browser [e.g. stock browser, safari]
35 | - Version [e.g. 22]
36 |
37 | **Additional context**
38 | Add any other context about the problem here.
39 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/feature_request.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Feature request
3 | about: Suggest an idea for this project
4 | title: ''
5 | labels: ''
6 | assignees: ''
7 |
8 | ---
9 |
10 | **Is your feature request related to a problem? Please describe.**
11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
12 |
13 | **Describe the solution you'd like**
14 | A clear and concise description of what you want to happen.
15 |
16 | **Describe alternatives you've considered**
17 | A clear and concise description of any alternative solutions or features you've considered.
18 |
19 | **Additional context**
20 | Add any other context or screenshots about the feature request here.
21 |
--------------------------------------------------------------------------------
/2-routing/1-defining-routes/Readme.md:
--------------------------------------------------------------------------------
1 | # Rotaların Tanımlanması
2 |
3 | ## Rotalar Oluşturma
4 |
5 | Next.js, rotaları tanımlamak için **klasörlerin** kullanıldığı dosya sistemi tabanlı bir yönlendirici kullanır.
6 |
7 | Her klasör, bir **URL** segmentiyle eşleşen bir rota segmentini temsil eder. İç içe bir rota oluşturmak için, klasörleri birbirinin içine yerleştirebilirsiniz.
8 |
9 |
10 |
11 | Rota segmentlerini genel erişime açmak için özel bir `page.js` dosyası kullanılır.
12 |
13 |
14 |
15 | Bu örnekte, `/dashboard/analytics` URL yolu, karşılık gelen bir `page.js` dosyasına sahip olmadığı için _genel erişime_ açık değildir. Bu klasör bileşenleri, stil sayfalarını, görüntüleri veya diğer ortak dosyaları depolamak için kullanılabilir.
16 |
17 | ## Kullanıcı Arayüzü Oluşturma
18 |
19 | Her bir rota segmenti için kullanıcı arayüzü oluşturmak üzere özel dosya kuralları kullanılır. En yaygın olanları, bir rotaya özgü kullanıcı arayüzünü gösteren sayfalar ve birden fazla rotada paylaşılan kullanıcı arayüzünü gösteren düzenlerdir.
20 |
21 | Örneğin, ilk sayfanızı oluşturmak için `app` dizininin içine bir `page.js` dosyası ekleyin ve bir React bileşenini dışa aktarın:
22 |
23 | ```tsx
24 | export default function Page() {
25 | return
Hello, Next.js!
;
26 | }
27 | ```
28 |
--------------------------------------------------------------------------------
/2-routing/12-project-organization/Readme.md:
--------------------------------------------------------------------------------
1 | # Proje Organizasyonu ve Dosya Kolokasyonu (Project Organization and File Colocation)
2 |
3 | Yönlendirme klasörü ve dosya kurallarının yanı sıra Next.js, proje dosyalarınızı nasıl düzenlediğiniz ve konumlandırdığınız konusunda görüş bildirmez.
4 |
5 | ## Varsayılan olarak güvenli ortak yerleşim (Safe colocation by default)
6 |
7 | `app` dizininde, iç içe klasör hiyerarşisi rota yapısını tanımlar.
8 |
9 | Her klasör, URL yolunda karşılık gelen bir segmentle eşlenen bir rota segmentini temsil eder.
10 |
11 | Ancak, rota yapısı klasörler aracılığıyla tanımlansa da, bir rota segmentine bir `page.js` veya `route.js` dosyası eklenene kadar bir rota genel olarak erişilebilir değildir.
12 |
13 |
14 |
15 | Ve bir rota genel erişime açık hale getirildiğinde bile, istemciye yalnızca `page.js` veya `route.js` tarafından döndürülen içerik gönderilir.
16 |
17 |
18 |
19 | Bu, proje dosyalarının yanlışlıkla yönlendirilebilir olmadan `app` dizinindeki rota segmentlerinin içine güvenli bir şekilde yerleştirilebileceği anlamına gelir.
20 |
21 |
22 |
23 | Bilmekte fayda var:
24 |
25 | - Bu, sayfalardaki herhangi bir dosyanın bir rota olarak kabul edildiği `pages` dizininden farklıdır.
26 | - Proje dosyalarınızı `app` dizinine yerleştirebilirsiniz ancak bunu yapmak zorunda değilsiniz. Tercih ederseniz, bunları `app` dizininin dışında tutabilirsiniz.
27 |
28 | ## Proje organizasyon özellikleri (Project organization features)
29 |
30 | Next.js, projenizi düzenlemenize yardımcı olacak çeşitli özellikler sunar.
31 |
32 | ### Özel Klasörler
33 |
34 | Özel klasörler, bir klasörün önüne alt çizgi getirilerek oluşturulabilir: `_folderName`
35 |
36 | Bu, klasörün özel bir uygulama ayrıntısı olduğunu ve yönlendirme sistemi tarafından dikkate alınmaması gerektiğini gösterir, böylece klasör ve tüm alt klasörleri yönlendirme dışında bırakılır.
37 |
38 |
39 |
40 | `app` dizinindeki dosyalar varsayılan olarak güvenli bir şekilde ortak konumlandırılabildiğinden, özel klasörler ortak konumlandırma için gerekli değildir. Ancak, şunlar için yararlı olabilirler:
41 |
42 | - UI mantığını yönlendirme mantığından ayırma.
43 | - Dahili dosyaları bir proje ve Next.js ekosistemi genelinde tutarlı bir şekilde düzenleme.
44 | - Kod düzenleyicilerde dosyaları sıralama ve gruplama.
45 | - Gelecekteki Next.js dosya kurallarıyla olası adlandırma çakışmalarını önleme.
46 |
47 | Bilmekte fayda var:
48 |
49 | - Bir çatı kuralı olmamakla birlikte, özel klasörlerin dışındaki dosyaları da aynı alt çizgi kalıbını kullanarak "private" olarak işaretlemeyi düşünebilirsiniz.
50 | - Klasör adının önüne `%5F` (alt çizginin URL ile kodlanmış biçimi) ekleyerek alt çizgi ile başlayan URL segmentleri oluşturabilirsiniz: `%5FfolderName`.
51 | - Özel klasörler kullanmıyorsanız, beklenmedik adlandırma çakışmalarını önlemek için Next.js özel dosya kurallarını bilmek yararlı olacaktır.
52 |
53 | ## Rota Grupları (Route Groups)
54 |
55 | Rota grupları bir klasör parantez içine alınarak oluşturulabilir: `(folderName)`
56 |
57 | Bu, klasörün organizasyonel amaçlar için olduğunu ve rotanın URL yoluna dahil edilmemesi gerektiğini gösterir.
58 |
59 |
60 |
61 | Rota grupları şunlar için kullanışlıdır:
62 |
63 | - Rotaları gruplar halinde düzenleme, örneğin site bölümüne, amaca veya ekibe göre.
64 | - Aynı rota segmenti düzeyinde iç içe düzenleri etkinleştirme:
65 | - Birden fazla kök düzen dahil olmak üzere aynı segmentte birden fazla iç içe düzen oluşturma
66 | - Ortak bir segmentteki rotaların alt kümesine bir düzen ekleme
67 |
68 | ## `src` Dizini
69 |
70 | Next.js, uygulama kodunun (`app` dahil) isteğe bağlı bir `src` dizini içinde saklanmasını destekler. Bu, uygulama kodunu çoğunlukla bir projenin kök dizininde bulunan proje yapılandırma dosyalarından ayırır.
71 |
72 |
73 |
74 | ## Modül Yolu Takma Adları (Module Path Aliases)
75 |
76 | Next.js, derinlemesine iç içe geçmiş proje dosyalarında içe aktarmaları okumayı ve sürdürmeyi kolaylaştıran Modül Yolu Takma Adlarını destekler.
77 |
78 | ```ts
79 | // önce
80 | import { Button } from "../../../components/button";
81 |
82 | // sonra
83 | import { Button } from "@/components/button";
84 | ```
85 |
86 | ## Proje organizasyon stratejileri (Project organization strategies)
87 |
88 | Bir Next.js projesinde kendi dosyalarınızı ve klasörlerinizi düzenlemek söz konusu olduğunda "doğru" veya "yanlış" bir yol yoktur.
89 |
90 | Aşağıdaki bölüm, yaygın stratejilerin çok üst düzey bir özetini listelemektedir. En basit çıkarım, sizin ve ekibiniz için işe yarayan bir strateji seçmek ve proje genelinde tutarlı olmaktır.
91 |
92 | Bilmekte fayda var: Aşağıdaki örneklerimizde, `components` ve `lib` klasörlerini genelleştirilmiş yer tutucular olarak kullanıyoruz, bunların adlandırılmasının özel bir çerçeve önemi yoktur ve projeleriniz `ui`, `utils`, `hooks`, `styles` vb. gibi başka klasörler kullanabilir.
93 |
94 | ### Proje dosyalarını `app` dışında saklama
95 |
96 | Bu strateji, tüm uygulama kodunu projenizin kök dizinindeki paylaşılan klasörlerde saklar ve `app` dizinini yalnızca yönlendirme amacıyla tutar.
97 |
98 |
99 |
100 | ### Proje dosyalarını `app` içindeki üst düzey klasörlerde saklayın
101 |
102 | Bu strateji, tüm uygulama kodunu `app` dizininin kök dizinindeki paylaşılan klasörlerde saklar.
103 |
104 |
105 |
106 | ### Proje dosyalarını özellik veya rotaya göre bölme
107 |
108 | Bu strateji, genel olarak paylaşılan uygulama kodunu kök `app` dizininde depolar ve daha spesifik uygulama kodunu bunları kullanan rota segmentlerine böler.
109 |
110 |
111 |
--------------------------------------------------------------------------------
/2-routing/13-internationalization/Readme.md:
--------------------------------------------------------------------------------
1 | # Uluslararasılaştırma (Internationalization)
2 |
3 | Next.js, birden fazla dili desteklemek için içeriğin yönlendirilmesini ve oluşturulmasını yapılandırmanıza olanak tanır. Sitenizi farklı yerel ayarlara uyumlu hale getirmek, çevrilmiş içerik (yerelleştirme) ve uluslararasılaştırılmış rotaları içerir.
4 |
5 | ## Terminoloji
6 |
7 | - Yerel ayar: Bir dizi dil ve biçimlendirme tercihi için bir tanımlayıcı. Bu genellikle kullanıcının tercih ettiği dili ve muhtemelen coğrafi bölgesini içerir.
8 | - `en-US`: Amerika Birleşik Devletleri'nde konuşulan İngilizce
9 | - `nl-NL`: Hollanda'da konuşulduğu şekliyle Hollandaca
10 | - `nl`: Hollandaca, belirli bir bölge yok
11 |
12 | ## Yönlendirmeye Genel Bakış (Routing Overview)
13 |
14 | Hangi yerel ayarın kullanılacağını seçmek için kullanıcının tarayıcıdaki dil tercihlerini kullanmanız önerilir. Tercih ettiğiniz dili değiştirmek, uygulamanıza gelen `Accept-Language` başlığını değiştirecektir.
15 |
16 | Örneğin, aşağıdaki kütüphaneleri kullanarak, Üstbilgilere, desteklemeyi planladığınız yerel ayarlara ve varsayılan yerel ayara göre hangi yerel ayarı seçeceğinizi belirlemek için gelen bir İsteğe bakabilirsiniz.
17 |
18 | ```ts
19 | import { match } from "@formatjs/intl-localematcher";
20 | import Negotiator from "negotiator";
21 |
22 | let headers = { "accept-language": "en-US,en;q=0.5" };
23 | let languages = new Negotiator({ headers }).languages();
24 | let locales = ["en-US", "nl-NL", "nl"];
25 | let defaultLocale = "en-US";
26 |
27 | match(languages, locales, defaultLocale); // -> 'en-US'
28 | ```
29 |
30 | Yönlendirme, alt yol (`/fr/products`) veya etki alanı (`my-site.fr/products`) ile uluslararasılaştırılabilir. Bu bilgilerle artık kullanıcıyı Middleware içindeki yerel ayara göre yönlendirebilirsiniz.
31 |
32 | ```ts
33 | import { NextResponse } from 'next/server'
34 |
35 | let locales = ['en-US', 'nl-NL', 'nl']
36 |
37 | // Yukarıdakine benzer şekilde veya bir kütüphane kullanarak tercih edilen yerel ayarı alın
38 | function getLocale(request) { ... }
39 |
40 | export function middleware(request) {
41 | // Yol adında desteklenen herhangi bir yerel ayar olup olmadığını kontrol edin
42 | const pathname = request.nextUrl.pathname
43 | const pathnameIsMissingLocale = locales.every(
44 | (locale) => !pathname.startsWith(`/${locale}/`) && pathname !== `/${locale}`
45 | )
46 |
47 | // Yerel ayar yoksa yönlendirme
48 | if (pathnameIsMissingLocale) {
49 | const locale = getLocale(request)
50 |
51 | // örneğin gelen istek /products
52 | // Yeni URL artık /en-US/products şeklindedir
53 | return NextResponse.redirect(
54 | new URL(`/${locale}/${pathname}`, request.url)
55 | )
56 | }
57 | }
58 |
59 | export const config = {
60 | matcher: [
61 | // Tüm dahili yolları atla (_next)
62 | '/((?!_next).*)',
63 | // İsteğe bağlı: yalnızca kök (/) URL'de çalıştır
64 | // '/'
65 | ],
66 | }
67 | ```
68 |
69 | Son olarak, `app/` içindeki tüm özel dosyaların `app/[lang]` altında yuvalandığından emin olun. Bu, Next.js yönlendiricisinin rotadaki farklı yerel ayarları dinamik olarak işlemesini ve `lang` parametresini her düzene ve sayfaya iletmesini sağlar. Örneğin:
70 |
71 | ```ts
72 | // Artık geçerli yerel ayara erişiminiz var
73 | // örneğin /en-US/products -> `lang` "en-US "dir
74 | export default async function Page({ params: { lang } }) {
75 | return ...
76 | }
77 | ```
78 |
79 | Kök düzen de yeni klasörün içine yerleştirilebilir (örn. `app/[lang]/layout.js`).
80 |
81 | ## Yerelleştirme (Localization)
82 |
83 | Görüntülenen içeriğin kullanıcının tercih ettiği yerel ayara veya yerelleştirmeye göre değiştirilmesi Next.js'ye özgü bir şey değildir. Aşağıda açıklanan modeller herhangi bir web uygulamasında aynı şekilde çalışacaktır.
84 |
85 | Uygulamamız içinde hem İngilizce hem de Hollandaca içeriği desteklemek istediğimizi varsayalım. Bize bazı anahtarlardan yerelleştirilmiş bir dizeye eşleme sağlayan nesneler olan iki farklı "sözlük" tutabiliriz. Örneğin:
86 |
87 | ```ts
88 | {
89 | "products": {
90 | "cart": "Add to Cart"
91 | }
92 | }
93 | ```
94 |
95 | ```ts
96 | {
97 | "products": {
98 | "cart": "Voeg toe aan winkelwagen"
99 | }
100 | }
101 | ```
102 |
103 | Ardından, istenen yerel ayar için çevirileri yüklemek üzere bir `getDictionary` işlevi oluşturabiliriz:
104 |
105 | ```ts
106 | import "server-only";
107 |
108 | const dictionaries = {
109 | en: () => import("./dictionaries/en.json").then((module) => module.default),
110 | nl: () => import("./dictionaries/nl.json").then((module) => module.default),
111 | };
112 |
113 | export const getDictionary = async (locale) => dictionaries[locale]();
114 | ```
115 |
116 | O anda seçili olan dil göz önüne alındığında, bir düzen veya sayfanın içindeki sözlüğü getirebiliriz.
117 |
118 | ```ts
119 | import { getDictionary } from "./dictionaries";
120 |
121 | export default async function Page({ params: { lang } }) {
122 | const dict = await getDictionary(lang); // en
123 | return ; // Add to Cart
124 | }
125 | ```
126 |
127 | `app/` dizinindeki tüm düzenler ve sayfalar varsayılan olarak Sunucu Bileşenleri olduğundan, çeviri dosyalarının boyutunun istemci tarafı JavaScript paket boyutumuzu etkilemesi konusunda endişelenmemize gerek yoktur. Bu kod yalnızca sunucuda çalışacak ve tarayıcıya yalnızca ortaya çıkan HTML gönderilecektir.
128 |
129 | ## Statik Üretim (Static Generation)
130 |
131 | Belirli bir yerel ayar kümesi için statik rotalar oluşturmak üzere `generateStaticParams`'ı herhangi bir sayfa veya düzenle birlikte kullanabiliriz. Bu, örneğin kök düzeninde global olabilir:
132 |
133 | ```ts
134 | export async function generateStaticParams() {
135 | return [{ lang: "en-US" }, { lang: "de" }];
136 | }
137 |
138 | export default function Root({ children, params }) {
139 | return (
140 |
141 | {children}
142 |
143 | );
144 | }
145 | ```
146 |
--------------------------------------------------------------------------------
/2-routing/2-pages-and-layouts/Readme.md:
--------------------------------------------------------------------------------
1 | # Sayfalar ve Düzenler
2 |
3 | ## Sayfalar
4 |
5 | Sayfa, bir rotaya **özgü** kullanıcı arayüzüdür. Bir `page.js` dosyasından bir bileşeni dışa aktararak sayfaları tanımlayabilirsiniz. Bir rota tanımlamak için iç içe klasörler ve rotayı genel erişime açmak için bir `page.js` dosyası kullanın.
6 |
7 | `app` dizini içine bir `page.js` dosyası ekleyerek ilk sayfanızı oluşturun:
8 |
9 |
10 |
11 | ```tsx
12 | // `app/page.tsx` is the UI for the `/` URL
13 | export default function Page() {
14 | return
Hello, Home page!
;
15 | }
16 | ```
17 |
18 | ```tsx
19 | // `app/dashboard/page.tsx` is the UI for the `/dashboard` URL
20 | export default function Page() {
21 | return
Hello, Dashboard Page!
;
22 | }
23 | ```
24 |
25 | ## Düzenler
26 |
27 | Düzen, birden fazla sayfa arasında **paylaşılan** kullanıcı arayüzüdür. Gezinme sırasında düzenler durumu korur, etkileşimli kalır ve yeniden oluşturulmaz. Düzenler iç içe de yerleştirilebilir.
28 |
29 | Bir `layout.js` dosyasından bir React bileşenini dışa aktararak `default` olarak bir düzen tanımlayabilirsiniz. Bileşen, render sırasında bir alt düzen (varsa) veya bir alt sayfa ile doldurulacak bir `children` prop kabul etmelidir.
30 |
31 |
32 |
33 | ```tsx
34 | export default function DashboardLayout({
35 | children, // will be a page or nested layout
36 | }: {
37 | children: React.ReactNode;
38 | }) {
39 | return (
40 |
41 | {/* Include shared UI here e.g. a header or sidebar */}
42 |
43 |
44 | {children}
45 |
46 | );
47 | }
48 | ```
49 |
50 | Bilmekte fayda var:
51 |
52 | - En üstteki düzen Kök Düzen olarak adlandırılır. Bu **gerekli** düzen, bir uygulamadaki tüm sayfalarda paylaşılır. Kök düzenler `html` ve `body` etiketlerini içermelidir.
53 | - Herhangi bir rota segmenti isteğe bağlı olarak kendi Düzenini tanımlayabilir. Bu düzenler o segmentteki tüm sayfalarda paylaşılır.
54 | - Bir rotadaki düzenler varsayılan olarak **iç içedir**. Her üst düzen, React `children` prop kullanarak altındaki alt düzenleri sarar.
55 | - Paylaşılan düzenlere belirli rota segmentlerini dahil etmek ve hariç tutmak için Rota Gruplarını kullanabilirsiniz.
56 | - Düzenler varsayılan olarak Sunucu Bileşenleridir ancak İstemci Bileşeni olarak ayarlanabilir.
57 | - Düzenler veri getirebilir.
58 | - Bir üst düzen ile onun alt düzenleri arasında veri aktarımı mümkün değildir. Bununla birlikte, aynı verileri bir rotada birden fazla kez getirebilirsiniz ve React, performansı etkilemeden istekleri otomatik olarak çıkaracaktır.
59 | - Düzenlerin geçerli rota segmentlerine erişimi yoktur. Rota segmentlerine erişmek için, bir İstemci - Bileşeninde `useSelectedLayoutSegment` veya `useSelectedLayoutSegments` kullanabilirsiniz.
60 | - Düzenler için `.js`, `.jsx` veya `.tsx` dosya uzantıları kullanılabilir.
61 | - Bir `layout.js` ve `page.js` dosyası aynı klasörde tanımlanabilir. Düzen, sayfayı saracaktır.
62 |
63 | ## Kök Düzeni (Gerekli)
64 |
65 | Kök düzen, `app` dizininin en üst düzeyinde tanımlanır ve tüm rotalar için geçerlidir. Bu düzen, sunucudan döndürülen ilk HTML'yi değiştirmenize olanak tanır.
66 |
67 | ```tsx
68 | export default function RootLayout({
69 | children,
70 | }: {
71 | children: React.ReactNode;
72 | }) {
73 | return (
74 |
75 | {children}
76 |
77 | );
78 | }
79 | ```
80 |
81 | Bilmekte fayda var:
82 |
83 | - `app` dizini **mutlaka** bir kök düzen içermelidir.
84 | - Next.js `` ve `` etiketlerini otomatik olarak oluşturmadığı için mutlaka kök düzen tanımlamalıdır.
85 | - `` HTML öğelerini yönetmek için yerleşik SEO desteğini kullanabilirsiniz, örneğin, `` öğesi.
86 | - Birden fazla kök düzen oluşturmak için rota gruplarınıkullanabilirsiniz.
87 | - Kök düzen varsayılan olarak bir Sunucu Bileşenidir ve İstemci Bileşeni olarak ayarlanamaz.
88 |
89 | ## İç içe Düzenler
90 |
91 | Bir klasör içinde tanımlanan düzenler (örn. `app/dashboard/layout.js`) belirli rota segmentlerine (örn. `acme.com/dashboard`) uygulanır ve bu segmentler etkin olduğunda oluşturulur. Varsayılan olarak, dosya hiyerarşisindeki mizanpajlar **iç içe geçmiştir**, bu da children düzenlerini `children` prop'ları aracılığıyla sardıkları anlamına gelir.
92 |
93 |
94 |
95 | ```tsx
96 | export default function DashboardLayout({
97 | children,
98 | }: {
99 | children: React.ReactNode;
100 | }) {
101 | return {children};
102 | }
103 | ```
104 |
105 | Yukarıdaki iki düzeni birleştirecek olursanız, kök düzen (`app/layout.js`) gösterge tablosu düzenini (`app/dashboard/layout.js`) saracak ve bu da `app/dashboard/*` içindeki rota segmentlerini saracaktır.
106 |
107 | İki düzen bu şekilde iç içe geçecektir:
108 |
109 |
110 |
111 | Rota Gruplarını, belirli rota segmentlerini paylaşılan düzenlere dahil etmek ve bu düzenlerden çıkarmak için kullanabilirsiniz.
112 |
113 | ## Şablonlar
114 |
115 | Şablonlar, her bir alt düzeni veya sayfayı sarması bakımından düzenlere benzer. Rotalar arasında kalıcı olan ve durumu koruyan düzenlerin aksine, şablonlar gezinme sırasında alt öğelerinin her biri için yeni bir örnek oluşturur. Bu, bir kullanıcı bir şablonu paylaşan rotalar arasında gezindiğinde, bileşenin yeni bir örneğinin monte edildiği, DOM öğelerinin yeniden oluşturulduğu, durumun korunmadığı ve efektlerin yeniden senkronize edildiği anlamına gelir.
116 |
117 | Bu belirli davranışlara ihtiyaç duyduğunuz durumlar olabilir ve şablonlar düzenlerden daha uygun bir seçenek olabilir. Örneğin:
118 |
119 | - CSS veya animasyon kütüphaneleri kullanarak giriş/çıkış animasyonları.
120 | - `useEffect` (örneğin sayfa görüntülemelerini kaydetme) ve `useState` (örneğin sayfa başına geri bildirim formu) kullanan özellikler.
121 | - Varsayılan framework davranışını değiştirmek için. Örneğin, düzenlerin içindeki Askıya Alma Sınırları, geri dönüşü yalnızca Düzen ilk kez yüklendiğinde gösterir ve sayfalar arasında geçiş yaparken göstermez. Şablonlar için, geri dönüş her gezinmede gösterilir.
122 |
123 | Öneri: Şablon kullanmak için özel bir neden yoksa Düzenleri kullanmanız önerilir.
124 |
125 | Bir `template.js` dosyasından varsayılan bir React bileşeni dışa aktarılarak bir şablon tanımlanabilir. Bileşen, iç içe segmentler olacak bir `children` prop kabul etmelidir.
126 |
127 |
128 |
129 | ```tsx
130 | export default function Template({ children }: { children: React.ReactNode }) {
131 | return