投票：オプションのパラメータに関心を示すには、このコメントに「+1」を付けてください。

注：オプションのパラメーターは、このRFCですでに使用可能であり、明示的な構文がないだけです（「警告」セクションを参照）。

投票：キャッチオールパラメータへの関心を表明するには、このコメントの「+1」に反応してください。

注：このスレッドのキャッチオールパラメータのユースケースを共有してください！ 問題空間をもっと理解したいと思います。

予約済み3

ricardo.chでは、各ルートにロケールプレフィックスを使用しているため、ルーティングが少し複雑になっています。

有効なルートの例：

• / -自動検出されたロケールのホームページ
• /:locale -強制ロケールのホームページ
• /:locale/search -検索ページ
• /:locale/article/:id -記事ページ

そのようなプレフィックスパラメータをサポートできると思いますか？

現時点では、 https：//www.npmjs.com/package/next-routesを使用してい

別のこと：記事ページでは、 /de/article/example-article-123ようなIDの前のスラッグもサポートしています。IDは123です。これは、 next-routesを使用して非常に複雑な正規表現を介して行われますが、私はサポートしていません。これをファイルシステムAPIでどのように表現できるかをご覧ください。

@ValentinH提供されたルートは、ファイルシステムAPIを使用してすべて可能です-提供されたルートが与えられた場合：

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

/ de / article / example-article-123のようなIDの前のスラッグもサポートします。IDは123になります。

このユースケースは上記のとおりです。

名前付きパラメータをルート名の途中に表示することはできません。

これは、 blog-$id.jsという名前のページが文字通りに解釈され、 /blog-1と一致しないことを意味します。 ページを/blog/$id.js再構築するか、URLセグメント全体を名前付きパラメーターに変換して、アプリケーションのコードでblog-削除を処理することができます。

このソリューションはあなたのニーズを満たしていませんか？ 特定の要件について詳しく知りたいと思います。

答えてくれてありがとう。

$locale/index.jsフォルダとファイルの両方として使用することは考えていませんでした。これは本当に素晴らしいです！

「真ん中の名前付きパラメーター」については、スラッグを動的にするのは違うと思ったので見落としていました。 しかし、あなたは完全に正しいです、そしてこれはあなたが言及した段落によって扱われます。 アプリケーションコードのスラッグをストライピングするのが道です🙂

このようなもの（.hidden .files / .foldersからのパラメーターの解析）は可能でしょうか？

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

または、ファイルを見つけることができるように$を残します：Dが、パラメータを示すために常に$ folderを使用しますか？

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

以前は、npmパッケージで動作するアプリのオプションパラメーターにこのユースケースがありました。 これらはオプションでスコープを持つことができます。 次のようなルートがあります。

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

したがって、基本的に、scopeパラメーターはオプションですが、 @で始まる場合のスコープでもあります。
したがって、 /packages/express/dependenciesと/packages/@babel/coreのセグメント数は同じですが、1つのケースではexpressの/dependenciesであり、他のケースでは/index @babel/core 。

最終的に、次のルートでreact-routerで解決されました。

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

このRFCでこのユースケースの解決策が見られるかどうかはわかりません。

キャッチオールのユースケースについては、フォルダー構造、ツリービュー、ツリーマップなど、再帰的にネストされたデータへのディープリンクを考えています。

私の2セント：ファイル名のドル記号は、シェルによって印章として使用されるため、悪い考えです。 rm $root.jsを実行しようとしている人々を混乱させるでしょう。 アンダースコアはまともな選択肢のようです。

もっと広く：多くの人のように、私は過去にこれに対する解決策としてファイルシステムを活用しようとしました。 最終的に、ファイルシステムがあなたが探している完全な表現力を提供することは決してないだろうと思います。 たとえば、宣言型ルーターでは通常、動的パラメーターの検証パターンを指定できます。 その場合、スキーマの一部はファイルシステム上にあり、別の部分はコード内にあります。 関心の分離は良いことですが、この場合、それは何よりも技術的な制限です。

@ValentinHと同様に、$ locale varを使用しますが、これはオプションです。

/page.tsと/page/$locale/page.tsを使用する必要がありますか？

「デフォルト」ロケールまたは事前定義されたロケール（ユーザー設定）を使用できるため、そのような場合は$ localeパラメーターを使用しません。

しかし、もっと多くのユースケースがあります：/ car / search / $ optional-filter-1 / $ optional-filter-2 / $ optional-filter-3

オプションフィルター1：カラーレッド、オプションフィルター2：ブランドフォードなど。

また、オプションのパラメータの場合、/ $ required-param /や/ $$ optional-param /のようなものですか？

これがロードマップに登場するのは素晴らしいことです！

@timdpをサポートするためにチャイムをtouch $fileすらできない場合、これは多くの混乱につながります。 あなたはすべての相互作用で逃げることを覚えておく必要があります。 touch \$file; vim $fileはファイルなしでvimを開きます（$ fileは定義された変数ではないため）。
同様に、シェルのタブ補完ではすべての変数が一覧表示され、再び混乱が生じます。

私は、適切な関連付けを提供し、シェルで機能する必要があると思う2つの代替案を提案しています。

• = =customer場合はpage is a customerと読み取ることができます。 ちょうど伸ばされたコロンであるように精神的に歪めることさえできます。したがって、名前付きパラメーターの最も一般的な形式に似ています。
• @もある程度読みやすいので。 a customer for @customer

別のオプションは、中括弧を使用することです（一部のファイルシステムで予約文字である場合を除く）。 このパラメータ構文も「先行技術」であり、他の多くのルーターで使用されています。

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

これにより、パラメータがどこから始まりどこで終わるかが明確になるため、ルートセグメントの中央にパラメータを配置し、セグメントごとに複数のパラメータを設定できます（例： /product-{productId}-{productColor} 。

ダイナミックルートがNext.jsにやってくるのはとても興奮しています！

名前付きパラメーターの構文に関して、これはSpectrumで説明されているものです： https ： [brackets]を使用してそれを行っている方法が好きです。 これは、Nuxtがバージョン3で実装しようとしていることでもあります。異なるフレームワークで動的ファイルシステムベースのルートに同じ形式を使用することは良いことのように思えます。

<Link />の使用法に関して、開発者はhref as属性とhref属性に「マージ」することは、重大な変更をもたらすため不可能だと思いますが、よりエレガントな方法で解決できると思います。

残念ながら、中括弧はコマンドをグループ化するためにBashによって使用されます。

<Link />使用に関して@ stephan281094に同意します、それは間違いの原因になります。

動的ルーティングは非常に便利な機能なので、皆さんがそれを調べて解決策、巨大な小道具を思いついたのは本当に素晴らしいことです！

このトピックについては、ワイルドカードルートも提案に追加する価値があります。 将来的に調査するものとしてキャッチオールパラメータについて言及しましたが、N個のレベルを持つ可能性のある/category/*ようなことを実行したい場合は、すべてをカバーしていません。 categoryページをレンダリングします。

:安全に使用することは可能ですか？ もしそうなら、それは私の投票です。なぜなら、誰もがすでにエクスプレスからその慣習に精通しているからです。

$がシェル変数と競合するため、私は個人的に強く反対します。

:安全に使用することは可能ですか？ もしそうなら、それは私の投票です。なぜなら、誰もがすでにエクスプレスからその慣習に精通しているからです。

どうやら:はWindowsで禁止されている文字なので、おそらく安全ではありません。 URLでアンダースコアを使用できるため、 _使用することも理想的ではありません。 [brackets]が良い解決策だと思う理由は、それがより将来の証拠だからです。 Next.jsが将来post-12345ようなルートをサポートしたい場合、この構文を使用すると、重大な変更を加えることなく実行できます。

したがって、避けるべき文字のリストは次のようになります。

• ファイルシステムとの競合： : 、 * 、 " 、 < 、 > 、 |
• シェル変数との競合： $
• bashブレース拡張との競合{ 、 }

他に何か？

これは、いくつかの理由で一元化されたルートファイルを持つ必要性を排除するものではありません。

• 自動生成されたサイトマップがあり、ファイルシステムだけではそれを定義するのに十分ではありません。
• 名前付きルートを使用し、宛先の「ページ」は、ビルド時に認識できるものではなく、データによって決定されます。 名前とパラメータに基づいてロードするページを決定するためのロジックは、ルート構成によって駆動されます。

また、次の理由でページフォルダを生成します。

• 私たちはRelayを使用しています。これは、GraphQLを含むモジュールに一意の名前を付ける必要があることを意味します。 そのため、ルートセグメント名をモジュール名と同じにすることはできません。 index.js間違いなく一意ではなく、 editように複数の共通セグメントがある場所があります。
• Next.jsではpagesフォルダー内で許可されていない、ページモジュール自体の兄弟として1回限りのページ固有のコンポーネントを同じ場所に配置することをお勧めします。

基本的に、私たちのパターンは、集中ルート構成を使用してページフォルダーを生成することです。このフォルダーには、コードベースの他の場所からモジュールをインポート/エクスポートするだけのファイルが含まれています。

そのために、私の焦点は、この提案が既存のページ生成プロセスの拡張出力形式として単純に機能し、少なくともカスタムサーバーを必要としないという利点を得ることができるかどうかにあります。

他の場所でいくつかのユースケースを確認しました： https ：

私が見ていない主なことは、ファイルシステムで表現されていない暗黙のパラメーター（URLオーバーライドなど）をサポートしていることです。

次のようなURLがあるとします。

/some-vanity-url/

現在のNext.jsの用語では、 Product.js?id=foo&language=enいくつかのクエリパラメーターを使用して製品ページにマップする必要があります。

同様に、当社のWebサイトでは、ほとんどの国の「サイト」がトップレベルのセグメント（ esやieなど）によってスコープされていますが、 gbサイトはそのセグメントなしでマウントされています。 これは、すべてのgbページに暗黙のcountryパラメーターがあるのに対し、他のすべての国では明示的であることを意味します。

もう1つの欠点は、この場合、同じ「ページ」がURLアーキテクチャの複数のマウントポイントに存在する可能性があるため、実際よりも多くのバンドル（つまり、複数の重複するエントリポイント）が発生することです。実際に必要です。

全体として、この提案はほとんどの一般的なユースケースでうまく機能するように見えますが、すべてのケースでルート構成またはカスタムサーバーの必要性を排除するものではありません。 しかし、これが今日のようにフレームワークを使用する私の能力に取って代わるものではないと仮定すると、これが好ましいハッピーパスAPIであることに真の異議はありません。

{id}提案を支持します。 それは複数のパラメータを可能にし、私はそれがはるかに良く見えると思います。 また、Reactとの適合性も高くなります。

私はfile/&param.js文字に賛成です。 URLから直接取得され、ファイルシステムやbashと競合しているようには見えません。

私は_を使用し、本当に何か別のものが必要な人のためにnext.config.jsオーバーライドを許可するかもしれません。

これに関する作業に感謝します。 しばらく欲しかった！ ❤️

すごい！ 🎉🎉🎉

ここでの私の唯一の問題は、 Linkがhrefとas両方のパラメーターを必要とすることです。

<Link to="blog/123" />書くだけでよいと思います。Nextjsはpagesフォルダー内のファイルに基づいてすべてのルートをすでに知っているので、簡単に"/blog/$id"に変換できます。

したがって、避けるべき文字のリストは次のようになります。

&は、非同期サブシェルで引数の左側を実行するbashの制御演算子です。 平文： open pages/&customerはバックグラウンドでopen pages/ open pages/&customerを実行し、フォアグラウンドシェルでコマンドcustomerを実行します。

これは本当にクールに見えます。

これにより、かなりの数の単一ファイルディレクトリが作成されるようです（元の例の/blog/$idなど）。 2つの後続ルートパラメータ（つまり、 /git/compare/$hash1/$hash2 ）が必要な場合、これはさらに面倒になります。

また、ブログ投稿をレンダリングするためのファイル名が$id.jsになるのも好きではありません。 blog.jsという名前を付けると、はるかにわかりやすくなります。

おそらく@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

これは、提案されたキャッチオールパラメータに対してもよりクリーンなソリューションを提供するようです。

デコレータを関数に適用することはできません（おそらくこれは最後に読んだときに変更されましたか？）そして提案はおそらくとにかく遠く離れています

さて、あなたがその道を進んだとしたら、おそらく今AMPが設定されている方法でそれを行うでしょう：

// /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
};

ただし、このようなものは、ある時点で役立つと思われる場合は、後で追加できると思います。 RFCで説明されているように、最初は基本的なサポートが必要だと思います。 それで実際の使用法をいくつか取得し、それが壊れているところを洗練します。 また、避けるべき文字はファイルシステムのものだけだと思います。 これらは、この機能を構築するための本当のブロッカーです。

サーバーレスソリューションに適したキャラクターを使用してください。 （Awsでは、問題を引き起こす可能性のあるキャラクターがいくつかあります）

コンポーネントキーを使用して構成オブジェクトをエクスポートすることは、私が嫌いではありません。

HOCを使用することもできます

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

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

ページに静的フィールド（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ブラウザで/blogに移動するとどうなりますか？ 404？

これはコンパイル時に決定する必要があるため、静的に分析可能なものが必要になると思います。 HOCまたは静的プロパティはそうではありません。

静的に分析できるものが必要です。 HOCまたは静的プロパティは

これまでに示したすべての静的プロパティの例は、静的に分析可能です（ただし、確かに簡単に壊れることはあります）。 関数をエクスポートし、静的に分析可能な方法で関数にrouteプロパティを設定するように要求することもできます。 ランタイムは、実行時に設定されたが静的アナライザーによってキャッチされなかったルートプロパティをチェックし、警告を発行したり、エラーをスローしたりできます。

ブラウザで/ blogに移動するとどうなりますか？ 404？

@ kingdaro -IMO、はい。 /blogと/blog/:blogId両方のパスを使用する場合は、ディレクトリを使用します。 そのパスをオーバーロードしているので、ディレクトリ構造は正当化されます。

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

これまでに述べたすべてのキャラクターオプションの簡単なレビュー：

出現順に

チャー| 欠点
--- | ---
$ | ファイル名のドル記号は、シェルによって印章として使用されるため、お勧めできません。
_ | 通常、内部ルートを示します
= |
@ | PowerShellのスプラット演算子
{...} | コマンドをグループ化するためにBashによって使用されます
[...] | zshファイル名の生成
: | 有効なファイル名ではありません
& | 非同期サブシェルで引数の左側を実行するbashの制御演算子です

さて、あなたがその道を進んだとしたら、おそらく今AMPが設定されている方法でそれを行うでしょう：

// /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
};

ただし、このようなものは、ある時点で役立つと思われる場合は、後で追加できると思います。 RFCで説明されているように、最初は基本的なサポートが必要だと思います。 それで実際の使用法をいくつか取得し、それが壊れているところを洗練します。 また、避けるべき文字はファイルシステムのものだけだと思います。 これらは、この機能を構築するための本当のブロッカーです。

実際に何が動的であるかを確認するには、複数のファイルを調べる必要があるため、configを使用することは悪い考えだと思います。 ファイルシステムに設定すると、一目でわかります。

複数の標準ルーティングソリューションを検討する必要があるのではないかと思います。

シンプルなファイルベースのルーティングは、Next / Reactを初めて使用する人や、シンプルなアプリをすばやく起動して実行したい人にとっては大きなセールスポイントですが、かなり制限される可能性があります。 そして、このパターンに動的ルーティングをシューホーンしようとすると、その単純さが台無しになり、すべてをファイルベースに保つという名目で、不必要な複雑さにつながる可能性があるように思われます。

この議論を読み、Next.jsの私自身の使用法について考えた後、代替（補足）ルーティングシステムのファーストクラスのサポートがこれを解決するための最良の方法であると思います。

私はこのスレッドの独創的な考え方（デコレータを使用する提案など）のいくつかが好きですが、それらのアイデアには間違いなく独自の問題があります。 何か素晴らしいものを思いつくことができるといいのですが👍

コンポーネントキーを使用して構成オブジェクトをエクスポートすることは、私が嫌いではありません。

HOCを使用することもできます

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

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

それはかなりクールですが、ルート情報を次のような多くのファイルに分割するのではないかと思います
これは管理が難しくなる可能性があります。

ローカル構成（ファイル内）とグローバル構成（ route.js ）を提案するという私の当初の考えは、最初のコメントで述べた特定のシナリオ（ディレクトリ内の唯一のファイルである深くネストされたファイル）に対処することでした。非セマンティックファイル名、およびcatch-all-params）。

これらのコンテキストで厳密に使用すると、URLがファイルシステムに直接マップされ、「余分な」パラメータのみがローカル構成によってアドレス指定されるため、混乱がはるかに少なくなります。

とは言うものの、ユーザーが好きなようにそれを行うことを制限しようとするかどうかさえわかりません。 計算されたルーティングテーブルをコンソールにきれいに印刷したり、事前に定義されたファイルに保存したりすることもできます。 ルートのトラブルシューティングを支援するには、これで十分です。

@merelinguist要約表に書いているように、Windowsでは=が禁止されているとは思いません。 :が禁止されている方法にリンクしていますが、 Microsoft Windowsのファイル命名ドキュメントによると、同じ文字が許可されています。

私はすでに本番環境で使用するプロジェクトに動的ルートを移植しています（今週公開できることを願っています）。

ただし、具体的な質問ですが、新しいnext @ canary API機能は動的ルーティングもサポートしますか？

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

[email protected]で試してみましたが、404が見つからないため、まだ存在しないと思われます。 これらの2つの機能（API +動的ルート）がURLルーティングで同等であることが理にかなっているように思えます。

@remyまだ実装されていませんすぐに実行するために私のリストにあります

また、WindowsおよびLinuxシステムだけでなく、他のシステムも考慮する必要があります。
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

私の提案についてさらに情報を追加したいと思います：

ページに静的フィールド（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. 開発者は、そのルートプロパティにランタイム変数を使用できません

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

1. この現在のRFC（フォルダーに動的であることを識別する文字が含まれている）を使用してページマニフェストを作成する場合、ファイルを読み取ってこのページマニフェストを作成し、ページの静的ルートプロパティを見つけても、違いはわかりません。 linguiが機能するのと同じように、 TransのIDを動的にすることはできません。

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

すでにリストされているプレフィックスのリストを見ていき@シンボルプレフィックスを使用しない強い理由があるのではないかと思います。

それが価値があるかどうかは疑わしいですが、Nuxtと同等になります。つまり、どちらか一方から切り替えると、その動作がすぐにわかります。

あるいは、プレフィックスをユーザーオプションにすることを考えた人はいますか？ あるプロジェクトを別のプロジェクトから理解するのが難しくなりますが、必要に応じて、接頭辞query__{...}などを付けることができます。

ちょっとした考え。

@remyの提案に続いて、Nextがファイルシステムからのルートを解析する方法についてAPIを完全に開いてみませんか。 ユーザーに必要なだけの（または少ない）柔軟性を提供し、信頼性の高いサードパーティルーティングソリューションを刺激します。

@ scf4 PoCであるライブラリがあり、 now.jsonルート構成を使用してnextjsでユニバーサルルーティングを実行します。

Zeitチームもクライアント側ライブラリのルートパーサーをオープンソース化することを望んでいます。

Nuxtを見ると、 _id.jsはそれほど悪くないと思います。 はい、あなたが言ったように、私たちはすでに_appと_document.jsしており、公にルーティングすることはできません。 ただし、これは多くのページのテンプレートであるため、動的ルートはルーティングできないと見なすこともできます。

静的サイトのエクスポートでは、これはどのように処理されますか？

（これは気にしないでください）

また、Next.jsが生成されたルートを単一のファイル（おそらくデフォルトでは非表示）に出力する場合にも役立つと思います。 少なくとも、プロジェクトに取り組んでいる人々への有用な参照として役立ちますが、後で強力な動的ルーティングへの扉を開くこともできます。

つまり、実行時にそのファイルをルート処理に使用する場合、ファイルシステムベースのAPIの利点を失うことなく、ユーザーがルートを追加/変更するのは非常に簡単です（たとえば、複雑なパターンマッチングの場合）。

これにより、手動で変更されたルートを追跡する方法に関していくつかの課題が発生しますが、解決されれば、これがはるかに最善の解決策になると思います。

@ scf4 Next.jsには、カスタムサーバーオプションを使用して複雑なルートを実行する機能がすでにあります。 あなたが提案していることは、すでに利用可能なツールとほぼ同じ量のコードで達成されます。

そうそう、十分に公平だ。

とにかく、編集可能な単一のルートファイルを持つ方がはるかに優れたオプションだと思います！

私はファイルシステムを使用したルーティングに関するいくつかの

• [param]が最も安全に見えます（そしてSapperによって使用されます）。
• :はExpressユーザーにはなじみがありますが、WindowsFSで問題が発生した可能性があります。
• $と{param}は、シェルの変数と中括弧の展開に使用されるため、CLIではさらに問題が発生する可能性があります。
• _機能する可能性がありますが、「プライベート」インジケーターとしてはあまりにも一般的です。

個人的には、ルートのファイルをホワイトリストに登録する（ /^index\. ）とブラックリストに登録する（ /^_/ ）の方が優れていますが、 /pagesとの下位互換性の問題になります。

APIルート（＃7297）をサポートするための最近の議論により、これは/routes新しい家の下で/apiと/pages両方をサポートする機会になる可能性があります。

ただし、_そしてそれは強力な「しかし」_、Next.jsエコシステムは、_インクリメンタル_機能の追加を保証するのに十分な大きさです。

角かっこ（ [example] ）は、パターンマッチングのためにzshによって使用されるため、これも実行可能ではありません。

ファイル名生成の例を参照してください

ブラケット[]は、パターンマッチングのためにzshによって使用されるため、これも実行可能ではありません。

https://github.com/zeit/next.js/pull/7623で成功したようです

ヘッドアップをありがとう。 そこにもコメントを投稿しました。

[id]を試しましたが、パスで使用するのは面倒です（例： cd \[id\]/view.js ）。 私には、二重アンダースコア__id （例： cd __id/view.js ）も同様に機能し、内部ファイル/フォルダー（例： _app.js ）と区別できます（少し混乱するかもしれません）。

@AaronDDMはzshますか？ bashで[または]をエスケープする必要はありません。

ええ、これはzshでも起こります-これらのディレクトリと対話するのは非常に面倒です。

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

そして、 zshはmacOS Catalinaのデフォルトのシェルになるので、結局これについて何かする必要があるかもしれません...

__id.js同意する

うーん、本当に__愛していない、ただ私には見栄えがよくない。

@merelinguist em、Jestはデフォルトのテストフォルダに__tests__を使用しますが、場合によっては__が理にかなっていると思います。

@YUFENGWANGたぶん、でもできれば1文字がいいと思います。 最終的に、最善の解決策は次のようになると思います。

1. =ような、賢明なクロスプラットフォームのデフォルト
2. 使用される特別なルート文字をカスタマイズするためのnext.config.jsオプション
3. どの文字がどの状況で問題があるかに関するドキュメント

単一の文字に同意しましたが、ゼロ構成にしたいです。 私の推測では、ドキュメントで説明しても、多くの人がすべての問題を経験するでしょう。

=はzshによって予約されていることにも注意してください。 ドキュメントから：

単語が引用符で囲まれていない「=」で始まり、EQUALSオプションが設定されている場合、単語の残りの部分がコマンドの名前として使用されます。 コマンドがその名前で存在する場合、その単語はコマンドのフルパス名に置き換えられます。

ただのアイデア。 接尾辞を使用するのはどうですか？ たとえば、 [email protected]などで十分です。 これにより、文字が有効である限り、シェルやファイルシステム間でエスケープして作業する必要があるという問題が解決する場合があります。

これまでのところ、これらはエスケープする必要なしにzshとbashで機能します。

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

ああ。 接尾辞ではなく、末尾のURLパラメータを示す方法です。

したがって、 [email protected]はblog/:idます。

compare@[email protected]はcompare/:a/:bます。

これにより、上記で反対していた深くネストされた単一ファイルディレクトリを解決し、ルーティング定義ファイルシステム全体をベースに保つことができます。

それは派手に見えませんが、次のようなものはどうですか？

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

プレフィックス_var_ JS変数宣言を模倣しようとする種類。 それとも、それは超短い、1文字のものでなければなりませんか？

~文字はどうですか？

/blogs/~id 。

~をプレフィックスとして使用することも、POSIX準拠のシェルのホームフォルダーに展開するために使用されるため、実行可能ではありません。

[0-9a-zA-Z-._] （正規表現）と一致しない文字は、オペレーティングシステム、シェル、およびファイルシステム全体のプレフィックスとして安全であるとは見なされません。

一部の文字もインラインで安全ではありません。 置換についてはzshの

また、見た目が派手かどうかを追求するのではなく、直感的で読みやすく、コミュニケーションしやすいものにする必要があると思います。

• [params].js角かっこを使用すると、よりエレガントで広く使用されているように見えます。 （サッパー、nuxt v3？）。
• アンダースコアプレフィックスpages/_helper.jsは通常、プライベート関数用であり、レンダリングしないでください。 これにより、pagesフォルダー内にヘルパーコンポーネントを作成できます

imho：これはより大きな問題に対する一時的な解決策のように感じます。 ファイル構造に基づいてルートを作成することは、最初は非常に便利ですが、ルートやパラメーターなどが数百ある場合は、適切に拡張できません。ルート構成ファイル（各ディレクトリにroutes.jsファイルがある可能性があります）より良い長期的な解決策です。 私は、ファイルからルートを簡単に作成するのではなく、すぐに使用できる機能（SSR、速度など）を備えているため、個人的にnextjsに惹かれています。

@mmahalwyあなたは頭に釘を打ちました。

Next.jsは、（ファイルシステムに基づいて）ルート構成をすでに生成しています。 この構成をより明示的にしたり、ユーザーが必要に応じて「イジェクト」できるようにすることが、ここで最もシームレスなソリューションになると思います。

@mmahalwy @ scf4 FWIW、ファイルシステムルートの重要な理由は、一元化されたファイルを持つ必要性を排除することです。 実際、リンクとルーティングのためのNext.jsのAPI全体は、この制約を中心に設計されていると簡単に主張できます。

ルート構成の問題は、クライアントに出荷する必要があることです。これは、数百から数千のルートがある場合、非常に大量のコードバンドルを意味する可能性があります。

ただし、（私が知る限り、この問題を@timneutkensと過去数か月にわたって何度も話し合ったことから）一元化された構成なしでは実際には解決できない一般的なユースケースがかなりあります。 以前のコメントにそれらのいくつかをリストしましたが、もっとあります。

最も簡単なのは、作成者がサイト上のページへのリンクを作成できるCMS主導のブログを持つことです。 基になるページモジュールが何であるかを知らずに、単純な古いURLでリンクを作成するだけです。 一元化されたルート構成を使用すると、URLを逆一致させて、ロードするページを決定するのは非常に簡単です（私自身のライブラリ、 next-route-resolverは、このユースケース、および私が思いついた他のすべてのユースケースをサポートするように設計されてい

ルート設定なしで作業中のサイトを機能させる方法がわからないため、ルート設定をファイルサイズの許容範囲内に維持する方法を見つけることに重点を置いています。 他の人にとっては、ファイルシステムのルーティングで十分かもしれません。 すべてを解決する単一のソリューションがある場合、ルーティングは問題ではないと思います。それはすべて、トレードオフのバランスを取ることです。

先に述べたように、この提案に関する限り、ルーティングの問題を完全に解決するものとして販売されている限り、それは少し誤解を招く可能性があるため、問題ないようです:)

@AndrewIngram私はあなたがどこから来ているのか理解していますが、この制限はnextjsが持つ力を制限しています。 Nextjsはすぐに使えるものがたくさんあるので、新しいプロジェクトや会社がそれを使用するのは簡単です。 ただし、課題は、ルーティングに関する難しい意見であり、将来的にそれを排除できなくなります（そして、大企業として、プロジェクトが関心やメンテナンスを失った場合の出口戦略を常に検討しています）。

@mmahalwyあなたは私の

一元化されたルーティング構成または高度なルーティング構成を希望する場合は、カスタムサーバーや外部パッケージを使用して適切に処理されていませんか？ ここに何が追加されることを望んでいますか？

それはすべてこのRFCからトピックから外れているようです。 OPを含め、これがルーティングの最終的なソリューションであると示唆している人はいないと思います。 これは、ファイルシステムベースのルーティングを改善するだけです。

私はここ数週間、ミニプロジェクトに動的ルートを使用しています（3日前にカナリアレポで[param]移動されたことに注意しますが、 $を使用しています）。

私はgetRequestHandlerを使い始めましたが、サーバー側で動的ルーティングを取得していないと思います。

それはバグなのか、それとも意図的なもの（つまり、 getRequestHandlerへの変更）なのか、それともgetRequestHandlerを使用すると、動的ルーティングが完全にオフになるのでしょうか（これは今では理にかなっています…） ？

一元化されたルーティング構成または高度なルーティング構成を希望する場合は、カスタムサーバーや外部パッケージを使用して適切に処理されていませんか？ ここに何が追加されることを望んでいますか？

ここでの目標の1つは、Now（現在、すべての動的ルートを構成の一部にする必要がある）などのサービスで使いやすくするためだけに、カスタムサーバーを作成する必要をなくすことです。

それはすべてこのRFCからトピックから外れているようです。 OPを含め、これがルーティングの最終的なソリューションであると示唆している人はいないと思います。 これは、ファイルシステムベースのルーティングを改善するだけです。

実際、ここにはいくつかの追加のコンテキストがあります。 この提案は久しぶりであり、それに関連して私が見た多くの議論（私が直接関わったものを含む）に基づいて、これはこれらのルートを使用する必要性を排除するものとしてある程度誇大宣伝されていましたnext-routesや私自身のような管理ライブラリ。 このRFCで満たされていないユースケースを強調することはトピックから外れているとは思いません。 それらのいくつかは、おそらく提案へのいくつかの変更によって満たされるかもしれませんが、他はそうではないかもしれません。 しかし、いずれにせよ、提案されているものの限界についての認識を高めることは確かに価値がありますか？

FWIWでは、Pinterestで[param]スタイルのFSベースのルートを使用しています（ただし、Nextではありません）。 これまでのところ、非常に適切にスケーリングされています。 最大の批判は、Jestが[]を正規表現のペアとして解釈するため、param-fulハンドラーのテストをターゲットにすることが難しい場合があることです。

@chrislloyd誰かがzsh、またはこれらを異なる方法で解釈するツールを使用していることを考慮して、さまざまな環境のパス/ファイルにこの形式を使用してファイルを作成および管理した経験は何ですか？

[]がzshでのパターンマッチングに使用しているように見えます（そして、Jestで言うように）、これらのパスをエスケープする必要があります。 これを_知っている_場合、これはそれほど問題にはなりませんが、初心者が使用して理解できるはずであることを考えると、これが適切な形式であるかどうかは疑問です。

私が使用してのアイデア持って!のように、必要なパラメータなどを/pages/id!.jsと?のようにオプションのパラメータのために、 /pages/posts/id?.js 。

上記の説明のようにプレフィックスに問題はなく、 !が必須パラメーターを表し、 ?がオプションのパラメーターを表す方法について!よく知っています。

Windowsでは、ファイル名に疑問符を使用できません。両方とも？ と！ Bashでは特別な意味があります。

APIルートが動的パラメーター＃7629をサポートするようになりました🚀

@remy getRequestHandlerは動的ルーティングを処理することが期待されています-ローカルで処理することを確認しました。 調査できるように、複製手順を含む別のバグ/問題を提出していただけますか？ ：祈る：

皆さんこんにちは！ このRFCへの信じられないほどの応答をありがとう。

このRFCは、Next.js 9で安定したものとして実装され、リリースされています。
詳細については、ブログ投稿をご覧ください。

ここで提供されるすべての高度なフィードバックに対処するために、将来的に新しいRFCを公開する予定です。 利用可能になり次第、ここに更新を投稿します。