Jajak Pendapat : Untuk menyatakan minat pada parameter opsional , beri tanggapan dengan "+1" pada komentar ini.

Catatan : Parameter opsional sudah dimungkinkan dengan RFC ini, mereka hanya tidak memiliki sintaks eksplisit (lihat bagian Peringatan ).

Jajak Pendapat : Untuk menunjukkan minat pada parameter penampung-semua , harap beri tanggapan dengan "+1" pada komentar ini.

Catatan : Silakan bagikan kasus penggunaan Anda untuk parameter penampung semua di utas ini! Kami ingin lebih memahami ruang masalah.

dipesan 3

Di ricardo.ch, kami menggunakan prefiks lokal untuk setiap rute yang membuat perutean menjadi sedikit lebih kompleks.

Contoh rute yang valid:

• / - beranda dengan lokal yang terdeteksi otomatis
• /:locale - beranda dengan lokal paksa
• /:locale/search - halaman pencarian
• /:locale/article/:id - halaman artikel

Apakah menurut Anda parameter awalan seperti itu dapat didukung?

Saat ini, kami menggunakan https://www.npmjs.com/package/next-routes

Hal lain: untuk halaman artikel, kami juga mendukung slug sebelum id seperti /de/article/example-article-123 mana id-nya adalah 123. Ini dilakukan melalui regex yang cukup rumit menggunakan next-routes dan saya tidak lihat bagaimana ini dapat diekspresikan dengan API sistem file.

@ValentinH semua rute yang disediakan dimungkinkan menggunakan API sistem file - mengingat rute yang Anda berikan:

• / => pages/index.js
• /:locale => pages/$locale/index.js
• /:locale/search => pages/$locale/search.js
• /:locale/article/:id => pages/$locale/article/$id.js

kami juga mendukung slug sebelum id like / de / article / example-article-123 di mana id-nya adalah 123

Kasus penggunaan ini dibahas di atas:

Parameter bernama tidak dapat muncul di tengah nama rute.

Ini berarti halaman bernama blog-$id.js akan ditafsirkan secara harfiah dan tidak cocok dengan /blog-1 . Anda dapat merestrukturisasi halaman Anda menjadi /blog/$id.js atau mengubah seluruh Segmen URL menjadi parameter bernama dan menangani penghapusan blog- dalam kode aplikasi Anda.

Apakah solusi ini tidak memenuhi kebutuhan Anda? Kami ingin mempelajari lebih lanjut tentang kebutuhan spesifik Anda.

Terima kasih banyak atas jawabannya.

Saya tidak berpikir untuk menggunakan $locale/index.js baik sebagai folder maupun file, ini benar-benar rapi!

Mengenai "parameter bernama di tengah", saya mengabaikannya karena menurut saya memiliki siput yang dinamis itu berbeda. Namun, Anda sepenuhnya benar dan ini ditangani oleh paragraf yang Anda sebutkan. Mengupas siput dalam kode aplikasi akan menjadi cara yang harus dilakukan 🙂

Apakah hal seperti ini (parse params from .hidden .files / .folders) bisa dilakukan?

pages/
├── .root.js
├── blog/
│ ├── .id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── .customer/
│ │ ├── .post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

atau tinggalkan $ sehingga seseorang dapat menemukan file mereka: D tetapi selalu gunakan $ folder untuk menunjukkan parameter?

pages/
├── $root.js
├── blog/
│ ├── $id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── $customer/
│ │ ├── $post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

Saya dulu memiliki kasus penggunaan ini untuk parameter opsional dalam aplikasi yang bekerja dengan paket npm. Ini secara opsional dapat memiliki ruang lingkup. Ada rute seperti:

• /packages/express
• /packages/express/dependencies
• /packages/@babel/core
• /packages/@babel/core/dependencies

Jadi pada dasarnya, parameter cakupan adalah opsional, tetapi itu juga hanya cakupan ketika dimulai dengan @ .
Jadi /packages/express/dependencies dan /packages/@babel/core memiliki jumlah segmen yang sama, tetapi dalam satu kasus /dependencies dari express dan yang lainnya /index dari @babel/core .

Pada akhirnya diselesaikan dalam react-router dengan rute berikut:

<Switch>
  <Route path={`/packages/`} exact component={PackagesOverview} />
  <Route path={`/packages/:name(@[^/]+/[^/]+)`} component={PackageView} />
  <Route path={`/packages/:name`} component={PackageView} />
</Switch>

Saya tidak yakin saya melihat solusi untuk kasus penggunaan ini di RFC ini.

Untuk kasus penggunaan penampung semua, saya memikirkan segala penautan dalam ke data bersarang secara rekursif, seperti struktur folder, tampilan pohon, peta hierarki.

2 sen saya: tanda dolar dalam nama file adalah ide yang buruk karena mereka digunakan oleh cangkang sebagai sigil. Anda akan membingungkan orang yang mencoba menjalankan rm $root.js . Garis bawah tampak seperti alternatif yang layak.

Secara lebih luas: seperti banyak orang, saya telah mencoba memanfaatkan sistem file sebagai solusi untuk ini di masa lalu. Pada akhirnya, menurut saya sistem file tidak akan pernah menawarkan ekspresi penuh yang Anda cari. Misalnya, router deklaratif biasanya memungkinkan Anda menentukan pola validasi untuk parameter dinamis. Dalam kasus tersebut, bagian dari skema berada di sistem file, dan bagian lain dalam kode. Pemisahan masalah adalah hal yang baik, tetapi dalam kasus ini, ini adalah batasan teknis lebih dari apa pun.

Seperti @ValentinH, kami menggunakan $ locale var, tetapi opsional.

Haruskah kita menggunakan /page.ts dan /page/$locale/page.ts?

Karena kita bisa menggunakan lokal "default" atau lokal yang telah ditentukan (pengaturan pengguna), dalam kasus tersebut kita tidak menggunakan parameter $ locale.

Tetapi kami memiliki lebih banyak kasus penggunaan: / car / search / $ optional-filter-1 / $ optional-filter-2 / $ optional-filter-3

Di mana opsional-filter-1: warna-merah, opsional-filter-2: merek-ford, dll ...

Dan untuk parameter opsional, sesuatu seperti / $ required-param / dan / $$ opsional-param /?

Mengagumkan bahwa ini akan muncul di peta jalan!

Saya harus berpadu dalam mendukung @timdp . Ketika Anda bahkan tidak bisa touch $file ini akan menyebabkan banyak kebingungan. Anda perlu mengingat melarikan diri di setiap interaksi. touch \$file; vim $file akan membuka vim tanpa file (karena $ file bukan variabel yang ditentukan).
Demikian juga penyelesaian tab di shell akan mencantumkan semua variabel, sekali lagi membawa kebingungan.

Saya mengusulkan dua alternatif yang menurut saya memberikan asosiasi yang tepat dan harus bekerja dalam shell:

• = Dapat dibaca sebagai page is a customer untuk =customer . Anda bahkan dapat mengubahnya secara mental menjadi titik dua yang direntangkan, sehingga menyerupai bentuk paling umum untuk parameter bernama.
• @ karena juga terbaca dengan baik. a customer untuk @customer

Pilihan lain adalah menggunakan tanda kurung kurawal (kecuali jika mereka adalah karakter yang dipesan pada beberapa sistem file). Sintaks parameter ini juga "seni sebelumnya" dan digunakan oleh banyak router lain:

pages/
├── {root}.js
├── blog/
│ └── {id}.js
├── customers/
│ ├── {customer}/
│ │ ├── {post}.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

Ini akan memungkinkan untuk memiliki parameter di tengah segmen rute dan beberapa parameter per segmen karena jelas di mana parameter dimulai dan di mana ia berakhir, misalnya /product-{productId}-{productColor} .

Sangat senang bahwa rute dinamis akan hadir di Next.js!

Mengenai sintaks untuk parameter bernama, ini adalah sesuatu yang telah dibahas di Spectrum: https://spectrum.chat/next-js/general/rfc-move-parameterized-routing-to-the-file-system~ce289c5e-ff66 -4a5b-8e49-08548adfa9c7. Mungkin ada baiknya menggunakan itu sebagai masukan untuk diskusi di sini. Secara pribadi, saya suka bagaimana Sapper melakukannya dengan menggunakan [brackets] . Ini juga sesuatu yang Nuxt akan terapkan dalam versi 3. Memiliki kerangka kerja yang berbeda menggunakan format yang sama untuk rute berbasis sistem file dinamis terdengar seperti hal yang baik.

Mengenai penggunaan <Link /> , saya pikir pengembang akan dengan mudah lupa untuk menyetel atribut href dan as . Saya mengerti bahwa tidak mungkin untuk "menggabungkan" ini ke dalam atribut href karena ini akan menyebabkan perubahan besar, tetapi saya merasa hal itu dapat diselesaikan dengan cara yang lebih elegan.

Sayangnya, kurung kurawal digunakan oleh Bash untuk mengelompokkan perintah.

Saya setuju dengan @ stephan281094 mengenai penggunaan <Link /> , itu akan menjadi sumber kesalahan.

Perutean dinamis adalah fitur yang sangat berguna, jadi ini benar-benar luar biasa karena kalian telah memeriksanya dan menemukan solusi, alat peraga yang hebat!

Sementara pada topik ini, rute karakter pengganti juga akan menjadi tambahan yang layak untuk proposal. Anda memang menyebutkan parameter penampung semua sebagai sesuatu untuk diselidiki di masa depan, tetapi itu tidak mencakup kasus di mana Anda mungkin ingin melakukan sesuatu seperti /category/* , yang dapat memiliki jumlah N level, dan Anda menginginkan semua mereka untuk merender halaman category .

Apakah mungkin menggunakan : dengan aman? Kalau begitu, itu akan jadi pilihan saya, karena semua orang sudah familiar dengan konvensi dari ekspres itu.

Karena $ bertentangan dengan variabel shell, saya pribadi sangat menentangnya.

Apakah mungkin menggunakan : dengan aman? Kalau begitu, itu akan jadi pilihan saya, karena semua orang sudah familiar dengan konvensi dari ekspres itu.

Rupanya : adalah karakter terlarang di Windows, jadi mungkin tidak aman. Menggunakan _ juga tidak ideal, karena garis bawah dapat digunakan di URL. Alasan saya berpikir [brackets] adalah solusi yang bagus, adalah karena lebih banyak bukti di masa depan. Jika Next.js ingin mendukung rute seperti post-12345 di masa mendatang, menggunakan sintaks ini dapat dilakukan tanpa memperkenalkan perubahan yang mengganggu.

Jadi daftar karakter yang harus dihindari adalah:

• Bentrok dengan sistem file: : , * , " , < , > , |
• Konflik dengan variabel shell: $
• Konflik dengan ekspansi bash brace { , }

Ada yang lain?

Ini tidak akan menghilangkan kebutuhan kita untuk memiliki file rute terpusat karena beberapa alasan:

• Kami memiliki peta situs yang dibuat secara otomatis, dan sistem filenya saja tidak cukup untuk menentukannya.
• Kami menggunakan rute bernama dan "halaman" tujuan ditentukan oleh data, bukan sesuatu yang dapat diketahui pada waktu pembuatan. Logika untuk mencari tahu halaman apa yang akan dimuat berdasarkan nama dan parameter didorong oleh konfigurasi rute.

Kami juga membuat folder halaman kami karena alasan berikut:

• Kami menggunakan Relay, dan ini berarti modul yang melibatkan GraphQL perlu diberi nama secara unik. Oleh karena itu, kami sering kali tidak dapat memiliki nama segmen rute yang sama dengan nama modul. index.js jelas tidak unik, dan saya melihat tempat-tempat di mana kita memiliki beberapa segmen umum seperti edit .
• Kami lebih suka menempatkan komponen khusus halaman satu kali bersama sebagai saudara dari modul halaman itu sendiri, yang tidak diizinkan oleh Next.js dalam folder halaman.

Pada dasarnya pola kami adalah menggunakan konfigurasi rute terpusat kami untuk menghasilkan folder halaman kami, yang berisi file yang tidak lebih dari mengimpor / mengekspor modul dari tempat lain di basis kode.

Untuk itu, fokus saya lebih pada apakah proposal ini dapat berfungsi hanya sebagai format keluaran yang disempurnakan untuk proses pembuatan halaman yang ada, sehingga setidaknya kita bisa mendapatkan keuntungan dari tidak membutuhkan server khusus.

Saya telah membahas beberapa kasus penggunaan saya di tempat lain: https://gist.github.com/AndrewIngram/8d4c4ccd9bd10415a375caacade9f5ca

Hal utama yang tidak saya lihat adalah mendukung parameter implisit yang tidak diekspresikan dalam sistem file, misalnya penggantian URL.

Katakanlah kita memiliki URL seperti ini:

/some-vanity-url/

Di mana dalam istilah Next.js saat ini, kami ingin memetakan ke halaman produk dengan sejumlah parameter kueri, misalnya Product.js?id=foo&language=en .

Demikian pula, di situs web kami, sebagian besar "situs" negara dibatasi oleh segmen tingkat atas misalnya es atau ie , tetapi situs gb dipasang tanpa segmen itu. Ini berarti semua halaman gb memiliki parameter implisit country , sedangkan untuk semua negara lainnya eksplisit.

Kelemahan lainnya, adalah karena dalam kasus kami, 'halaman' yang sama dapat ada di beberapa titik kait dalam arsitektur URL, kami akan berakhir dengan lebih banyak bundel (yaitu beberapa titik entri duplikat) daripada yang sebenarnya kami lakukan. perlu dalam latihan.

Secara keseluruhan, proposal ini tampaknya akan berfungsi dengan baik untuk sebagian besar kasus penggunaan umum, tetapi tidak menghilangkan kebutuhan akan konfigurasi rute atau server khusus dalam _all_ kasus. Tetapi dengan asumsi ini tidak menggantikan kemampuan saya untuk menggunakan kerangka kerja seperti yang saya lakukan hari ini, saya tidak memiliki keberatan nyata untuk ini menjadi API jalur bahagia yang disukai.

Saya mendukung saran {id} . Ini memungkinkan beberapa params dan saya pikir itu terlihat jauh lebih baik. Ini juga lebih cocok dengan React.

Saya menyukai karakter file/&param.js . Diambil langsung dari url dan sepertinya tidak bentrok dengan sistem file atau bash.

Saya akan menggunakan _ dan mungkin mengizinkan penggantian di next.config.js bagi mereka yang benar-benar membutuhkan sesuatu yang berbeda.

Hargai pekerjaan ini. Sudah lama menginginkannya! ❤️

Luar biasa! 🎉🎉🎉

Satu-satunya masalah saya di sini adalah bahwa Link membutuhkan href dan as params.

Saya yakin kita bisa menulis <Link to="blog/123" /> : karena Nextjs sudah mengetahui semua rute berdasarkan file di folder halaman, itu bisa dengan mudah menerjemahkannya ke dalam "/blog/$id" .

Jadi daftar karakter yang harus dihindari adalah:

& adalah operator kontrol dalam bash yang menjalankan sisi kiri argumen dalam subkulit asinkron. Plaintext: open pages/&customer akan menjalankan open pages/ di latar belakang dan perintah customer di shell latar depan.

Ini terlihat sangat keren.

Tampaknya ini akan membuat sejumlah besar direktori file tunggal (seperti /blog/$id dalam contoh aslinya). Ini menjadi lebih rumit jika Anda menginginkan dua parameter rute tambahan (yaitu /git/compare/$hash1/$hash2 ).

Saya juga tidak suka nama file untuk mengoyak posting blog adalah $id.js . Memiliki nama blog.js akan jauh lebih deskriptif.

Mungkin menggabungkan dengan dekorator @customRoute ?

// pages/blog.js
import {useRouter, @customRoute} from 'next/router'

@customRoute('/blog/:id')
function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

export default BlogPost

Hal ini tampaknya juga memberikan solusi yang lebih bersih untuk parameter penampung-semua yang diusulkan.

Dekorator tidak dapat diterapkan ke fungsi (mungkin ini berubah sejak terakhir kali saya membacanya?) Dan lamarannya mungkin masih jauh

Nah, misalkan Anda menempuh jalan itu, Anda mungkin akan melakukannya dengan cara AMP dikonfigurasi sekarang:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

Namun, saya pikir hal-hal seperti ini dapat ditambahkan nanti jika tampaknya berguna di beberapa titik. Saya pikir saya lebih suka melihat dukungan dasar untuk memulai, seperti yang dijelaskan di RFC. Dapatkan beberapa penggunaan nyata dengan itu, lalu perbaiki bagian mana yang rusak. Saya juga berpikir satu-satunya karakter yang harus dipertimbangkan untuk dihindari adalah sistem file. Itu adalah pemblokir nyata untuk membangun fitur ini.

Harap pastikan untuk menggunakan karakter yang ramah dengan solusi tanpa server! (Di Aws, ada beberapa karakter yang dapat menyebabkan masalah)

Mengekspor objek config dengan kunci komponen adalah sesuatu yang tidak saya benci.

Anda juga bisa menggunakan HOC

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

bagaimana jika kita menambahkan beberapa bidang statis ke halaman (seperti getInitialProps)?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

@ dmytro-lymarenko Apa yang terjadi bila Anda menavigasi ke /blog di browser? A 404?

Karena ini perlu ditentukan pada waktu kompilasi, saya rasa Anda memerlukan sesuatu yang dapat dianalisis secara statis. HOC atau properti statis tidak akan ada.

Anda memerlukan sesuatu yang dapat dianalisis secara statis. HOC atau properti statis tidak akan ada

Setiap contoh properti statis yang diberikan sejauh ini akan dapat dianalisis secara statis (meskipun Anda pasti dapat merusaknya dengan mudah). Kami hanya dapat bersikeras bahwa Anda mengekspor fungsi dan menyetel properti rute di dalamnya dengan cara yang dapat dianalisis secara statis. Runtime dapat memeriksa properti rute yang disetel saat runtime tetapi tidak tertangkap oleh penganalisis statis kami dan mengeluarkan peringatan / melempar kesalahan.

Apa yang terjadi saat Anda membuka / blog di browser? A 404?

@kingdaro - IMO, ya. Jika Anda ingin menggunakan /blog , dan /blog/:blogId paths, maka Anda menggunakan direktori. Anda membebani jalur tersebut secara berlebihan, sehingga struktur direktori dapat dibenarkan.

pages/
├── blog/
│ ├── $id.js
│ └── index.js

Tinjauan singkat dari semua opsi karakter yang disebutkan sejauh ini:

Dalam urutan penampilan

Char | Kekurangan
--- | ---
$ | tanda dolar dalam nama file adalah ide yang buruk karena mereka digunakan oleh cangkang sebagai sigil
_ | biasanya menunjukkan rute internal
= |
@ | operator percikan di PowerShell
{...} | digunakan oleh Bash untuk mengelompokkan perintah
[...] | pembuatan nama file di zsh
: | bukan nama file yang valid
& | adalah operator kontrol di bash yang menjalankan sisi kiri argumen dalam subkulit asinkron

Nah, misalkan Anda menempuh jalan itu, Anda mungkin akan melakukannya dengan cara AMP dikonfigurasi sekarang:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

Namun, saya pikir hal-hal seperti ini dapat ditambahkan nanti jika tampaknya berguna di beberapa titik. Saya pikir saya lebih suka melihat dukungan dasar untuk memulai, seperti yang dijelaskan di RFC. Dapatkan beberapa penggunaan nyata dengan itu, lalu perbaiki bagian mana yang rusak. Saya juga berpikir satu-satunya karakter yang harus dipertimbangkan untuk dihindari adalah sistem file. Itu adalah pemblokir nyata untuk membangun fitur ini.

Saya pikir menggunakan config adalah ide yang buruk karena Anda perlu memeriksa banyak file, untuk melihat apa yang sebenarnya dinamis. Jika Anda mengaturnya di sistem file, Anda dapat melihatnya dari pandangan pertama.

Saya ingin tahu apakah lebih dari satu solusi perutean standar harus menjadi sesuatu yang perlu dipertimbangkan.

Perutean berbasis file sederhana adalah nilai jual yang bagus bagi mereka yang baru mengenal Next / React, atau siapa pun yang ingin segera menjalankan dan menjalankan aplikasi sederhana, tetapi itu bisa agak membatasi. Dan bagi saya tampaknya mencoba untuk menyematkan perutean dinamis ke dalam pola ini dapat merusak kesederhanaan itu dan menyebabkan kerumitan yang tidak perlu, semuanya atas nama menjaga semuanya tetap berbasis file.

Setelah membaca diskusi ini dan memikirkan tentang penggunaan Next.js saya sendiri, saya pikir dukungan kelas satu untuk sistem perutean alternatif (tambahan) bisa menjadi cara terbaik untuk menyelesaikannya.

Saya suka beberapa pemikiran out-of-the-box di utas ini (seperti proposal untuk menggunakan dekorator) tetapi ide-ide itu pasti memiliki masalah sendiri. Saya harap kami dapat menemukan sesuatu yang hebat 👍

Mengekspor objek config dengan kunci komponen adalah sesuatu yang tidak saya benci.

Anda juga bisa menggunakan HOC

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

Itu cukup keren, tapi saya bertanya-tanya apakah informasi rute dibagi menjadi banyak file seperti
ini bisa menjadi sulit untuk dikelola.

Pemikiran asli saya dengan mengusulkan konfigurasi lokal (dalam file) vs konfigurasi global ( route.js ), adalah membahas skenario spesifik yang disebutkan dalam komentar pertama saya (file yang sangat bersarang yang merupakan satu-satunya file di direktori mereka, nama file non-semantik, dan catch-all-params).

Jika digunakan secara ketat dalam konteks tersebut, itu jauh lebih membingungkan, karena URL memetakan langsung ke sistem file, dan hanya parameter "ekstra" yang dialamatkan oleh konfigurasi lokal.

Karena itu, saya tidak yakin saya akan mencoba membatasi pengguna untuk melakukannya sesuka mereka. Kami cukup mencetak tabel perutean yang dihitung ke konsol, atau bahkan menyimpannya ke beberapa file yang telah ditentukan. Itu seharusnya cukup untuk membantu rute pemecahan masalah

@merelinguist Saya tidak percaya = dilarang di Windows seperti yang Anda tulis di tabel ringkasan. Anda menghubungkan kembali ke bagaimana : dilarang, tetapi menurut dokumen penamaan file Microsoft Windows karakter yang sama diperbolehkan.

Saya sudah melakukan porting dengan rute dinamis dalam proyek yang saya gunakan dalam produksi (mudah-mudahan saya bisa menayangkannya langsung minggu ini).

Pertanyaan khusus, apakah fitur API @ canary berikutnya _also_ mendukung perutean dinamis?

{ path: '/api/:customer', page: '/api/$customer/index.js' }

Saya baru saja mencobanya dengan [email protected] dan saya mendapatkan 404 tidak ditemukan, jadi saya curiga belum ada. Sepertinya masuk akal jika kedua fitur ini (API + rute dinamis) memiliki kesamaan pada perutean URL.

@remy itu belum diimplementasikan, itu ada di daftar saya untuk segera melakukannya

Kami juga harus mempertimbangkan tidak hanya sistem Windows dan Linux, tetapi juga yang lain:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

Saya ingin menambahkan lebih banyak info tentang proposal saya:

bagaimana jika kita menambahkan beberapa bidang statis ke halaman (seperti getInitialProps)?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

1. Pengembang tidak dapat menggunakan variabel runtime untuk properti rute itu

const route = `/blog/${somethingElse}`;
BlogPost.route = route; // is not allowed

1. Ketika kita membangun manifes halaman dengan RFC saat ini (di mana folder berisi beberapa karakter untuk mengidentifikasinya dinamis) saya tidak melihat perbedaan jika kita membangun manifes halaman ini dengan membaca file dan menemukan properti rute statis di halaman. Dengan cara yang sama lingui bekerja: mereka tidak mengizinkan id untuk Trans menjadi dinamis

<Trans id="msg.docs" /* id can only be static string */>
   Read the <a href="https://lingui.js.org">documentation</a>
   for more info.
 </Trans>

Melihat daftar prefiks yang sudah terdaftar - Saya ingin tahu apakah ada alasan kuat _not_ menggunakan awalan simbol @ ?

Saya ragu apakah itu bernilai, tetapi Anda mendapatkan kesamaan dengan Nuxt - yang berarti seseorang yang beralih dari satu atau yang lain akan segera tahu cara kerjanya.

Atau, apakah ada yang berpikir untuk menjadikan awalan sebagai opsi pengguna? Itu membuat orang lebih sulit untuk memahami satu proyek dari yang lain, tetapi itu berarti jika saya mau, saya dapat membuat awalan query__{...} atau sesuatu.

Hanya pemikiran saja.

Mengikuti saran @remy , mengapa tidak membuka sepenuhnya API untuk mengetahui bagaimana Next mem-parse rute dari sistem file. Memberikan pengguna fleksibilitas sebanyak (atau sesedikit) yang mereka butuhkan, dan menginspirasi solusi perutean pihak ketiga yang andal.

@ scf4 Saya memiliki perpustakaan yang merupakan PoC, yang menggunakan now.json routes config untuk melakukan perutean universal dengan nextjs juga di sini

Saya berharap tim Zeit juga membuka sumber parser rute di perpustakaan sisi klien juga.

Melihat Nuxt menurut saya _id.js tidak terlalu buruk. Ya, kami sudah menggunakan _app dan _document.js seperti yang Anda sebutkan dan tidak dapat dirutekan secara publik. Tetapi rute dinamis juga dapat dilihat sebagai tidak dapat dirutekan karena ini adalah templat untuk banyak halaman

Bagaimana ini akan ditangani untuk ekspor situs statis?

(Jangan pedulikan yang ini)

Saya juga berpikir akan membantu jika Next.js mencetak rute yang dihasilkan ke satu file (mungkin disembunyikan secara default). Setidaknya ini akan berfungsi sebagai referensi yang berguna untuk orang-orang yang mengerjakan sebuah proyek, tetapi juga dapat membuka pintu untuk beberapa perutean dinamis yang kuat di kemudian hari.

Yaitu, jika menggunakan file itu untuk penanganan rute pada waktu proses, akan sangat mudah bagi pengguna untuk menambahkan / mengubah rute (misalnya, untuk pencocokan pola yang kompleks) tanpa kehilangan manfaat dari API berbasis sistem file.

Ini akan menciptakan beberapa tantangan mengenai bagaimana melacak rute yang telah diubah secara manual, tetapi jika diselesaikan saya pikir itu akan menjadi solusi terbaik sejauh ini.

@ scf4 Next.js sudah memiliki kemampuan untuk melakukan perutean kompleks menggunakan opsi server ubahsuaian. Apa yang Anda usulkan dicapai dalam jumlah kode yang hampir sama dengan perkakas yang sudah tersedia.

Ah ya, cukup adil.

Saya pikir memiliki satu file rute yang dapat diedit adalah pilihan yang jauh lebih baik!

Saya menulis beberapa pemikiran tentang perutean dengan sistem file , tetapi dapat meringkas temuan saya di sini:

• [param] tampaknya paling aman (dan digunakan oleh Sapper).
• : sudah tidak asing lagi bagi pengguna Express, tetapi saya mungkin _sworn_ Saya mengalami masalah pada Windows FS.
• $ dan {param} digunakan untuk variabel & brace ekspansi di shell, jadi ini bisa menjadi lebih bermasalah saat di CLI.
• _ _could_ bekerja, tetapi ini terlalu umum sebagai indikator "pribadi".

Saya pribadi memiliki pengalaman yang lebih baik dengan file daftar putih untuk rute ( /^index\. ) vs. daftar hitam ( /^_/ ), tetapi itu akan menjadi masalah kompatibilitas mundur dengan /pages .

Dengan diskusi terbaru untuk mendukung rute API (# 7297), ini bisa menjadi peluang untuk mendukung /api dan /pages keduanya di bawah rumah baru /routes .

Namun, _dan ini adalah "namun" _ yang kuat, ekosistem Next.js cukup besar untuk menjamin penambahan fitur _incremental_, vs. "hei, jika kami harus melakukan ini lagi, kami akan melakukannya dengan cara _this_ desain".

Tanda kurung siku ( [example] ) digunakan oleh zsh untuk pencocokan pola, jadi itu juga tidak akan layak.

Lihat contoh di Filename Generation

Tanda kurung [] digunakan oleh zsh untuk pencocokan pola, jadi itu juga tidak akan layak.

Sepertinya mereka baru saja berhasil di https://github.com/zeit/next.js/pull/7623

Terimakasih atas peringatannya. Saya juga memposting komentar di sana.

Saya mencoba [id] dan hanya menggunakannya di jalur yang menyebalkan (misalnya cd \[id\]/view.js ). Menurut saya, garis bawah ganda __id (misalnya cd __id/view.js ) bekerja dengan baik dan dapat dibedakan (meskipun mungkin sedikit membingungkan) dari file / folder internal (misalnya _app.js ).

@AaronDDM apakah Anda menggunakan zsh ? Anda tidak perlu keluar dari [ atau ] dalam bash.

Ya, ini juga terjadi pada saya dengan zsh - sangat mengganggu untuk berinteraksi dengan direktori ini.

$ mkdir [asdf]
zsh: no matches found: [asdf]
$ mkdir \[asdf\]
$ cd [asdf]
zsh: no matches found: [asdf]
$ cd \[asdf\]

Dan karena zsh akan menjadi shell default di macOS Catalina , mungkin ada sesuatu yang harus dilakukan tentang ini ...

setuju dengan __id.js

Hm, sungguh tidak suka __ , hanya saja tidak terlihat bagus bagi saya.

@merelinguist em, Jest gunakan __tests__ untuk folder uji default, saya pikir __ masuk akal dalam beberapa kasus.

@YUFENGWANG Mungkin, tapi saya lebih suka satu karakter jika memungkinkan. Pada akhirnya, saya pikir solusi terbaiknya adalah:

1. Standar lintas platform yang masuk akal, seperti =
2. Opsi di next.config.js untuk menyesuaikan karakter rute khusus yang digunakan
3. Dokumentasi tentang karakter mana yang bermasalah dalam situasi apa

Setuju dengan satu karakter tetapi saya lebih suka memiliki konfigurasi nol. dan tebakan saya adalah bahwa banyak orang akan mengalami semua masalah bahkan jika Anda menjelaskannya dalam dokumentasi

Perhatikan juga = dicadangkan oleh zsh. Dari dokumen :

Jika sebuah kata diawali dengan tanda kutip '=' dan opsi EQUALS diatur, kata lainnya akan diambil sebagai nama perintah. Jika ada perintah dengan nama itu, kata tersebut diganti dengan nama jalur lengkap dari perintah tersebut.

Hanya sebuah ide; bagaimana dengan menggunakan sufiks? Misalnya [email protected] , atau sejenisnya sudah cukup. Ini dapat menyelesaikan masalah karena harus keluar dan bekerja di seluruh shell dan sistem file selama karakternya valid.

Ini berfungsi di zsh dan bash tanpa perlu melarikan diri, sejauh ini:

[email protected]
example~.js
example=.js

Ooh. Bukan sufiks tetapi cara untuk menunjukkan parameter URL di belakangnya.

Jadi [email protected] menjadi blog/:id .

compare@[email protected] menjadi compare/:a/:b .

Ini bisa menyelesaikan direktori file tunggal yang sangat bersarang yang saya keberatan di atas, dan menjaga seluruh sistem file definisi perutean tetap berbasis.

Ini tidak terlihat mewah, tapi bagaimana dengan sesuatu di sepanjang baris:

/blogs/_var_blog-id/index.js
/blogs/_var_blog-id.js

awalan _var_ Jenis percobaan apa yang meniru deklarasi variabel JS. Atau harus super pendek, satu karakter?

Bagaimana dengan ~ karakter?

Seperti /blogs/~id .

Menggunakan ~ sebagai prefiks juga tidak dapat dilakukan, karena digunakan untuk memperluas ke folder home di shell yang sesuai dengan POSIX.

Karakter apa pun yang tidak cocok dengan [0-9a-zA-Z-._] (regex) tidak dapat dianggap aman sebagai awalan di seluruh sistem operasi, shell, dan sistem file.

Beberapa karakter juga tidak aman sebaris. Lihat dokumen zsh

Juga saya pikir kita tidak harus memperjuangkan apakah itu terlihat mewah, melainkan intuitif, mudah dibaca dan mudah untuk dikomunikasikan.

• menggunakan tanda kurung untuk [params].js tampak lebih elegan dan banyak digunakan. (pencari ranjau, nuxt v3?).
• garis bawahi awalan pages/_helper.js biasanya untuk fungsi pribadi dan mungkin ini tidak boleh dirender. ini memungkinkan kita untuk membuat komponen pembantu di dalam folder halaman

imho: ini terasa seperti solusi sementara untuk masalah yang lebih besar. Meskipun memiliki rute berdasarkan struktur file sangat bagus untuk memulai, itu tidak berskala dengan baik ketika Anda memiliki ratusan rute, params, dll. Memiliki file konfigurasi rute (mungkin memiliki file routes.js di setiap direktori) adalah solusi jangka panjang yang lebih baik. Saya pribadi tertarik pada nextjs karena fitur out-of-the-box (SSR, kecepatan, dll) yang disediakannya, bukan kemudahan membuat rute dari file.

@mmahalwy Anda memukul paku di kepala.

Next.js sudah membuat konfigurasi routes (berdasarkan filesystem). Saya percaya bahwa membuat konfigurasi ini lebih eksplisit dan / atau mengizinkan pengguna untuk "mengeluarkan" jika mereka ingin menjadi solusi yang paling mulus di sini

@mmahalwy @ scf4 FWIW, pembenaran yang signifikan untuk rute sistem file adalah untuk menghilangkan kebutuhan untuk memiliki file terpusat. Faktanya, orang dapat dengan mudah membantah bahwa keseluruhan API Next.js untuk tautan dan perutean dirancang berdasarkan batasan ini.

Masalah dengan konfigurasi rute adalah Anda akhirnya harus mengirimkannya ke klien, yang bisa berarti bundel kode yang lumayan besar jika Anda memiliki rute yang berjumlah ratusan hingga ribuan.

Namun, ada beberapa kasus penggunaan umum yang (sejauh yang saya ketahui, dari membahas masalah ini dengan @timneutkens berkali-kali selama beberapa bulan terakhir) tidak dapat benar-benar diselesaikan tanpa konfigurasi terpusat. Saya mencantumkan beberapa di antaranya di komentar saya sebelumnya, tetapi masih ada lagi.

Yang paling sederhana adalah memiliki blog yang digerakkan CMS di mana penulis dapat membuat tautan ke halaman di situs. Mereka hanya akan membuat tautan dengan URL lama biasa, tanpa pengetahuan tentang apa modul halaman yang mendasarinya. Dengan konfigurasi rute terpusat, cukup mudah untuk membalikkan pencocokan URL dan menentukan halaman mana yang akan dimuat (perpustakaan saya sendiri, resolver-rute-berikutnya dirancang untuk mendukung kasus penggunaan ini, dan semua yang lain yang saya temukan) .

Saya tidak melihat bagaimana saya dapat membuat situs yang saya kerjakan bekerja tanpa konfigurasi rute, jadi fokus saya hanya menemukan cara untuk menjaga konfigurasi rute dalam toleransi ukuran file. Untuk orang lain, perutean sistem file mungkin lebih dari cukup. Saya tidak berpikir perutean adalah masalah di mana ada satu solusi yang menyelesaikan segalanya, ini semua tentang menyeimbangkan pertukaran.

Jadi seperti yang saya sebutkan sebelumnya, sejauh menyangkut proposal ini, tampaknya baik-baik saja selama itu dijual sebagai menyelesaikan masalah perutean sepenuhnya, karena itu akan sedikit menyesatkan :)

@AndrewIngram Saya mengerti dari mana Anda berasal tetapi batasan ini membatasi kekuatan yang dimiliki nextjs. Nextjs menawarkan begitu banyak di luar kotak sehingga seharusnya tidak ada pemikiran bagi proyek atau perusahaan baru untuk menggunakannya. Tantangannya adalah pendapat keras tentang perutean yang membuatnya tidak dapat ditolak di masa depan (dan sebagai perusahaan besar, Anda selalu mempertimbangkan strategi keluar jika proyek kehilangan minat atau pemeliharaan).

@mmahalwy Saya pikir Anda salah paham tentang maksud saya. Saya setuju dengan Anda, menurut saya perutean sistem file tidak cukup untuk menyebut masalah perutean diselesaikan, dan akan kecewa jika disajikan seperti itu. Saya pikir ini menawarkan peningkatan untuk serangkaian kasus penggunaan tertentu, tetapi saya juga berpikir seharusnya juga ada semacam format manifes rute bagi mereka yang bersedia untuk ikut serta dalam serangkaian pertukaran yang berbeda (misalnya Anda dan saya) .

Bagi mereka yang menginginkan konfigurasi perutean terpusat atau lanjutan, bukankah itu ditangani dengan baik dengan menggunakan server khusus dan / atau paket eksternal? Apa yang Anda harapkan ditambahkan di sini?

Semuanya sepertinya keluar topik dari RFC ini. Saya tidak berpikir siapa pun, termasuk OP, telah menyarankan ini adalah solusi akhir untuk perutean. Ini hanya meningkatkan perutean berbasis sistem file.

Saya telah menggunakan rute dinamis untuk proyek mini selama beberapa minggu terakhir (menggunakan $ meskipun saya perhatikan bahwa itu dipindahkan ke [param] 3 hari yang lalu di repo canary, tapi bagaimanapun).

Saya _just_ mulai menggunakan getRequestHandler dan saya pikir itu tidak mengambil perutean dinamis di sisi server.

Apakah itu bug, atau disengaja (yaitu beberapa perubahan menjadi getRequestHandler ), sesuatu yang lain, atau apakah menggunakan getRequestHandler sepenuhnya mematikan perutean dinamis (yang akan masuk akal sekarang saya memikirkannya…) ?

Bagi mereka yang menginginkan konfigurasi perutean terpusat atau lanjutan, bukankah itu ditangani dengan baik dengan menggunakan server khusus dan / atau paket eksternal? Apa yang Anda harapkan ditambahkan di sini?

Salah satu tujuan di sini adalah untuk menghindari kebutuhan membuat server khusus, jika hanya untuk membuatnya lebih mudah digunakan dengan layanan seperti Now (yang saat ini membutuhkan semua rute dinamis untuk menjadi bagian dari konfigurasinya).

Semuanya sepertinya keluar topik dari RFC ini. Saya tidak berpikir siapa pun, termasuk OP, telah menyarankan ini adalah solusi akhir untuk perutean. Ini hanya meningkatkan perutean berbasis sistem file.

Sebenarnya ada beberapa konteks tambahan di sini. Proposal ini telah lama datang, dan berdasarkan banyak diskusi yang saya lihat terkait dengannya (termasuk yang saya telah terlibat langsung dengannya), ini sedang digembar-gemborkan sampai tingkat tertentu karena menghilangkan kebutuhan untuk menggunakan rute ini perpustakaan manajemen seperti rute berikutnya dan milik saya sendiri. Saya tidak berpikir itu di luar topik untuk menyoroti kasus penggunaan yang tidak dipenuhi oleh RFC ini. Beberapa dari mereka mungkin dipenuhi dengan beberapa perubahan pada proposal, yang lain mungkin tidak. Tapi bagaimanapun juga, tentunya berharga untuk meningkatkan kesadaran akan batasan dari apa yang sedang diusulkan?

FWIW kami menggunakan rute berbasis FS [param] gaya di Pinterest (meskipun tidak Berikutnya). Sejauh ini skalanya sangat baik. Kritik terbesar adalah bahwa Jest menafsirkan [] sebagai pasangan regexp sehingga sulit untuk menargetkan tes untuk penangan yang sangat berguna.

@chrislloyd Apa pengalaman Anda dalam membuat dan mengelola file menggunakan format ini untuk jalur / file di lingkungan yang berbeda, mengingat ada orang yang menggunakan zsh, atau alat yang menafsirkannya secara berbeda?

Dilihat sebagai [] digunakan untuk pencocokan pola di zsh (dan, seperti yang Anda katakan dengan Jest), Anda harus keluar dari jalur ini. Ini tidak terlalu menjadi masalah jika Anda _mengetahui_ ini, tetapi mengingat bahwa ini harus dapat digunakan dan dipahami oleh pemula, saya ragu bahwa ini adalah format yang tepat untuk digunakan.

Saya punya ide untuk menggunakan ! sebagai parameter yang diperlukan, seperti /pages/id!.js dan ? untuk parameter opsional, seperti di /pages/posts/id?.js .

Tidak ada masalah dengan awalan seperti diskusi di atas, dan familiar tentang bagaimana ! mewakili params yang diperlukan, dan ? mewakili parameter opsional.

Windows tidak mengizinkan tanda tanya dalam nama file, dan keduanya? dan! memiliki arti khusus di Bash.

API routes sekarang mendukung parameter dinamis # 7629 🚀

@remy getRequestHandler diharapkan untuk menangani perutean dinamis - Saya baru saja mengkonfirmasi secara lokal. Bisakah Anda mengajukan bug / masalah terpisah dengan langkah-langkah reproduksi sehingga kami dapat menyelidikinya? :berdoa:

Halo semuanya! Terima kasih atas tanggapan yang luar biasa untuk RFC ini.

RFC ini telah diimplementasikan dan dirilis sebagai stabil di Next.js 9.
Anda dapat membaca lebih lanjut tentang itu di posting blog .

Kami akan menerbitkan RFC baru di masa mendatang untuk menangani semua umpan balik lanjutan yang diberikan di sini. Kami akan memposting pembaruan di sini jika tersedia.