Umfrage : Um Interesse an optionalen Parametern auszudrücken, antworten Sie bitte mit einem "+1" auf diesen Kommentar.

Hinweis : Optionale Parameter sind mit diesem RFC bereits möglich, sie haben jedoch keine explizite Syntax (siehe Abschnitt Vorsichtsmaßnahmen ).

Umfrage : Um Interesse an Catch-All-Parametern auszudrücken, antworten Sie bitte mit einem "+1" auf diesen Kommentar.

Hinweis : Bitte teilen Sie Ihren Anwendungsfall für Catch-All-Parameter in diesem Thread! Wir würden den Problemraum gerne besser verstehen.

reserviert 3

Auf ricardo.ch verwenden wir für jede Route ein Gebietsschema-Präfix, wodurch das Routing etwas komplexer wird.

Beispiel für gültige Routen:

• / - Homepage mit automatisch erkanntem Gebietsschema
• /:locale - Homepage mit erzwungenem Gebietsschema
• /:locale/search - Suchseite
• /:locale/article/:id - Artikelseite

Denken Sie, dass solche Präfixparameter unterstützt werden könnten?

Im Moment verwenden wir https://www.npmjs.com/package/next-routes

Eine andere Sache: Für die Artikelseite unterstützen wir auch einen Slug vor der ID wie /de/article/example-article-123 wobei die ID 123 wäre. Dies erfolgt über einen recht komplexen regulären Ausdruck mit next-routes und ich nicht Sehen Sie, wie dies mit einer Dateisystem-API ausgedrückt werden kann.

@ValentinH Die angegebenen Routen sind alle über die Dateisystem-API möglich - unter Angabe Ihrer angegebenen Routen:

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

Wir unterstützen auch einen Slug vor der ID wie / de / article / example-article-123, wobei die ID 123 wäre

Dieser Anwendungsfall wurde oben angesprochen:

Benannte Parameter können nicht in der Mitte eines Routennamens angezeigt werden.

Dies bedeutet, dass eine Seite mit dem Namen blog-$id.js wörtlich interpretiert wird und nicht mit /blog-1 übereinstimmt. Sie können Ihre Seiten entweder so umstrukturieren, dass sie /blog/$id.js oder das gesamte URL-Segment in einen benannten Parameter umwandeln und das Entfernen von blog- im Code Ihrer Anwendung behandeln.

Entspricht diese Lösung nicht Ihren Anforderungen? Wir würden gerne mehr über Ihre spezifischen Anforderungen erfahren.

Vielen Dank für die Antwort.

Ich habe nicht daran gedacht, $locale/index.js sowohl als Ordner als auch als Datei zu verwenden, das ist wirklich ordentlich!

In Bezug auf den "benannten Parameter in der Mitte" habe ich ihn übersehen, weil ich dachte, dass es anders ist, wenn der Slug dynamisch ist. Sie haben jedoch völlig Recht, und dies wird in dem von Ihnen erwähnten Absatz angesprochen. Das Entfernen des Slugs im Anwendungscode ist der richtige Weg 🙂

Wäre so etwas möglich (Parameter aus .hidden .files / .folders analysieren) möglich?

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

oder lassen Sie das $, damit man seine Dateien finden kann: D aber immer den Ordner $ verwenden, um einen Parameter anzugeben?

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

Ich hatte diesen Anwendungsfall für optionale Parameter in einer App, die mit npm-Paketen funktionierte. Diese könnten optional einen Geltungsbereich haben. Es gibt Routen wie:

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

Grundsätzlich ist der Parameter scope optional, aber er ist auch nur dann ein Bereich, wenn er mit @ beginnt.
/packages/express/dependencies und /packages/@babel/core haben also die gleiche Anzahl von Segmenten, aber in einem Fall sind es /dependencies von express und in dem anderen /index von @babel/core .

Am Ende wurde es in react-router mit den folgenden Routen gelöst:

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

Ich bin nicht sicher, ob ich in diesem RFC eine Lösung für diesen Anwendungsfall sehe.

In Bezug auf alle Anwendungsfälle denke ich an eine tiefe Verknüpfung mit rekursiv verschachtelten Daten wie Ordnerstrukturen, Baumansichten und Baumkarten.

Meine 2 Cent: Dollarzeichen in Dateinamen sind eine schlechte Idee, weil sie von Muscheln als Siegel verwendet werden. Sie werden Leute verwirren, die versuchen, rm $root.js auszuführen. Unterstriche scheinen eine anständige Alternative zu sein.

Allgemeiner: Wie viele Menschen habe ich in der Vergangenheit versucht, das Dateisystem als Lösung für dieses Problem zu nutzen. Letztendlich denke ich, dass das Dateisystem niemals die volle Ausdruckskraft bieten wird, die Sie suchen. Bei deklarativen Routern können Sie beispielsweise normalerweise ein Validierungsmuster für einen dynamischen Parameter angeben. In diesem Fall befindet sich ein Teil des Schemas im Dateisystem und ein anderer Teil im Code. Die Trennung von Bedenken ist eine gute Sache, aber in diesem Fall ist es mehr als alles andere eine technische Einschränkung.

Wie bei @ValentinH verwenden wir das $ locale var, aber es ist optional.

Sollten wir /page.ts und /page/$locale/page.ts verwenden?

Da wir ein "Standard" -Landschema oder ein vordefiniertes Gebietsschema (Benutzereinstellungen) verwenden können, verwenden wir in diesen Fällen nicht den Parameter "$ locale".

Wir haben jedoch weitere Anwendungsfälle: / car / search / $ optional-filter-1 / $ optional-filter-2 / $ optional-filter-3

Wo optional-Filter-1: Farbe-Rot, optional-Filter-2: Brand-Ford, etc ...

Und für optionale Parameter so etwas wie / $ required-param / und / $$ optional-param /?

Super, dass dies auf der Roadmap steht!

Ich muss mich jedoch an die Unterstützung von @timdp halten . Wenn Sie nicht einmal touch $file können, wird dies zu viel Verwirrung führen. Sie müssen sich daran erinnern, bei jeder Interaktion entkommen zu sein. touch \$file; vim $file öffnet vim ohne Datei (da $ file keine definierte Variable ist).
Ebenso werden alle Variablen durch die Tab-Vervollständigung in einer Shell aufgelistet, was wiederum Verwirrung stiftet.

Ich schlage zwei Alternativen vor, die meiner Meinung nach die richtigen Assoziationen ergeben und in Muscheln funktionieren sollten:

• = Es kann als page is a customer für =customer gelesen werden. Sie können es sogar mental verzerren, ein gerade ausgestreckter Doppelpunkt zu sein, der der gebräuchlichsten Form für benannte Parameter ähnelt.
• @ da es auch etwas gut liest. a customer für @customer

Eine andere Möglichkeit wäre die Verwendung von geschweiften Klammern (es sei denn, es handelt sich bei einigen Dateisystemen um reservierte Zeichen). Diese Parametersyntax ist ebenfalls "Stand der Technik" und wird von vielen anderen Routern verwendet:

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

Dies würde es ermöglichen, Parameter in der Mitte des Routensegments und mehrere Parameter pro Segment zu haben, da klar ist, wo der Parameter beginnt und wo er endet, z. B. /product-{productId}-{productColor} .

So aufgeregt, dass dynamische Routen zu Next.js kommen!

In Bezug auf die Syntax für benannte Parameter wurde dies in Spectrum erläutert: https://spectrum.chat/next-js/general/rfc-move-parameterized-routing-to-the-file-system~ce289c5e-ff66 -4a5b-8e49-08548adfa9c7. Es könnte sich lohnen, dies als Input für die Diskussion hier zu verwenden. Persönlich gefällt mir, wie Sapper es mit [brackets] . Dies wird auch von Nuxt in Version 3 implementiert. Es klingt nach einer guten Sache, wenn verschiedene Frameworks dasselbe Format für dynamische, auf Dateisystemen basierende Routen verwenden.

In Bezug auf die Verwendung von <Link /> werden Entwickler leicht vergessen, die Attribute href und as festzulegen. Ich verstehe, dass es nicht möglich ist, diese in das href -Attribut "zusammenzuführen", da dies eine bahnbrechende Änderung einführen würde, aber ich denke, dass dies auf elegantere Weise gelöst werden könnte.

Geschweifte Klammern werden von Bash leider verwendet, um Befehle zu gruppieren.

Ich stimme @ stephan281094 hinsichtlich der Verwendung von <Link /> , da dies zu Fehlern führen wird.

Dynamisches Routing ist eine äußerst nützliche Funktion, daher ist es wirklich großartig, dass ihr euch das angeschaut und eine Lösung gefunden habt, riesige Requisiten!

Zu diesem Thema wären Platzhalterrouten ebenfalls eine würdige Ergänzung des Vorschlags. Sie haben Catch-All-Parameter als etwas erwähnt, das in Zukunft untersucht werden soll, aber es werden keine Fälle behandelt, in denen Sie möglicherweise etwas wie /category/* ausführen möchten, das N Ebenen haben könnte, und Sie möchten alle sie, um die Seite category zu rendern.

Ist es möglich, : sicher zu verwenden? Wenn ja, wäre das meine Stimme, denn jeder kennt diese Konvention bereits von Express.

Da $ mit Shell-Variablen in Konflikt steht, bin ich persönlich stark dagegen.

Ist es möglich, : sicher zu verwenden? Wenn ja, wäre das meine Stimme, denn jeder kennt diese Konvention bereits von Express.

Anscheinend ist : ein verbotenes Zeichen in Windows, daher ist es wahrscheinlich nicht sicher. Die Entscheidung für _ ist ebenfalls nicht ideal, da Unterstriche in URLs verwendet werden können. Der Grund, warum ich [brackets] für eine gute Lösung halte, ist, dass es zukunftssicherer ist. Wenn Next.js in Zukunft Routen wie post-12345 möchte, kann diese Syntax verwendet werden, ohne dass eine Änderung vorgenommen wird.

Eine Liste der zu vermeidenden Zeichen wäre also:

• Konflikte mit Dateisystemen: : , * , " , < , > , |
• Konflikte mit Shell-Variablen: $
• Konflikte mit der Erweiterung der Bash-Klammer { , }

Noch etwas?

Dies würde unsere Notwendigkeit einer zentralisierten Routendatei aus mehreren Gründen nicht beseitigen:

• Wir haben eine automatisch generierte Sitemap, und das Dateisystem allein reicht nicht aus, um sie zu definieren.
• Wir haben benannte Routen verwendet und Ziel- "Seiten" werden eher durch Daten bestimmt als durch etwas, das zum Zeitpunkt der Erstellung erkennbar ist. Die Logik zum Herausfinden, welche Seite basierend auf Name und Parametern geladen werden soll, wird von der Routenkonfiguration gesteuert.

Wir generieren unseren Seitenordner auch aus folgenden Gründen:

• Wir verwenden Relay, und dies bedeutet, dass Module mit GraphQL eindeutig benannt werden müssen. Aus diesem Grund können die Routensegmentnamen nicht oft mit den Modulnamen übereinstimmen. index.js definitiv nicht eindeutig, und ich sehe Orte, an denen wir mehrere gemeinsame Segmente haben würden, wie edit .
• Wir bevorzugen es, einmalige seitenspezifische Komponenten als Geschwister der Seitenmodule selbst zu lokalisieren, was Next.js im Seitenordner nicht zulässt.

Im Wesentlichen besteht unser Muster darin, unsere zentralisierte Routenkonfiguration zu verwenden, um unseren Seitenordner zu generieren, der Dateien enthält, die nichts anderes als Import- / Exportmodule von anderen Stellen in der Codebasis ausführen.

Zu diesem Zweck liegt mein Fokus eher darauf, ob dieser Vorschlag einfach als erweitertes Ausgabeformat für unseren bestehenden Seitengenerierungsprozess verwendet werden kann, damit wir zumindest den Vorteil haben, dass wir keinen benutzerdefinierten Server benötigen.

Ich habe einige meiner Anwendungsfälle an anderer Stelle durchgesehen :

Die Hauptsache, die ich nicht sehe, ist die Unterstützung impliziter Parameter, die nicht im Dateisystem ausgedrückt werden, z. B. URL-Überschreibungen.

Nehmen wir an, wir haben eine URL wie diese:

/some-vanity-url/

In den aktuellen Begriffen von Next.js möchten wir, dass es einer Produktseite mit einer Reihe von Abfrageparametern zugeordnet wird, z. B. Product.js?id=foo&language=en .

In ähnlicher Weise werden auf unserer Website die "Websites" der meisten Länder von einem Segment der obersten Ebene erfasst, z. B. es oder ie , aber die Website gb wird ohne dieses Segment bereitgestellt. Dies bedeutet, dass alle GB-Seiten einen impliziten country -Parameter haben, während er für alle anderen Länder explizit ist.

Der andere Nachteil ist, dass in unserem Fall dieselbe "Seite" an mehreren Einhängepunkten in der URL-Architektur vorhanden sein kann und wir am Ende eine größere Anzahl von Bundles (dh mehrere doppelte Einstiegspunkte) haben als tatsächlich brauchen in der Praxis.

Im Großen und Ganzen scheint dieser Vorschlag für die meisten gängigen Anwendungsfälle gut zu funktionieren, macht jedoch in allen Fällen keine Routenkonfiguration oder einen benutzerdefinierten Server erforderlich. Aber wenn dies nicht meine Fähigkeit ersetzt, das Framework so zu verwenden, wie ich es heute tue, habe ich keine wirklichen Einwände dagegen, dass dies die bevorzugte Happy-Path-API ist.

Ich unterstütze den Vorschlag {id} . Es erlaubt mehrere Parameter und ich denke, es sieht viel besser aus. Es passt auch besser zu React.

Ich bin für den Charakter file/&param.js . Entnommen direkt aus URLs und es sieht nicht so aus, als ob es mit Dateisystemen oder Bash in Konflikt steht.

Ich würde _ und vielleicht eine Überschreibung in next.config.js für diejenigen zulassen, die wirklich etwas anderes brauchen.

Schätzen Sie die Arbeit daran. Wollte es schon eine Weile! ❤️

Tolle! 🎉🎉🎉

Mein einziges Problem hier ist, dass Link sowohl href als auch as Parameter benötigt.

Ich glaube, wir könnten einfach <Link to="blog/123" /> schreiben: Da Nextjs bereits alle Routen kennt, die auf Dateien im Seitenordner basieren, könnte es leicht in "/blog/$id" .

Eine Liste der zu vermeidenden Zeichen wäre also:

& ist ein Steuerungsoperator in bash, der die linke Seite des Arguments in einer asynchronen Subshell ausführt. Klartext: open pages/&customer würde open pages/ im Hintergrund und den Befehl customer in der Vordergrundschale ausführen.

Das sieht echt cool aus.

Es scheint, dass dadurch eine erhebliche Anzahl von Einzeldateiverzeichnissen erstellt wird (wie /blog/$id im ursprünglichen Beispiel). Dies wird noch umständlicher, wenn Sie zwei nachfolgende Routenparameter (z. B. /git/compare/$hash1/$hash2 ) möchten.

Ich finde es auch nicht toll, dass der Dateiname für das Rendern eines Blogposts $id.js . Der Name blog.js wäre viel aussagekräftiger.

Vielleicht mit einem @customRoute Dekorateur kombinieren?

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

Dies scheint auch für die vorgeschlagenen Gesamtparameter eine sauberere Lösung zu bieten.

Dekorateure können nicht auf Funktionen angewendet werden (möglicherweise hat sich dies geändert, seit ich es das letzte Mal gelesen habe?), Und der Vorschlag ist wahrscheinlich sowieso weit entfernt

Angenommen, Sie gehen diesen Weg, Sie würden es wahrscheinlich so machen, wie AMP jetzt konfiguriert ist:

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

Ich denke jedoch, dass solche Dinge später hinzugefügt werden können, wenn sie irgendwann nützlich erscheinen. Ich denke, ich würde zunächst lieber eine grundlegende Unterstützung sehen, ähnlich wie im RFC beschrieben. Holen Sie sich eine echte Verwendung damit, und verfeinern Sie dann, wo es bricht. Ich denke auch, dass die einzigen Zeichen, die berücksichtigt werden sollten, um dies zu vermeiden, die Dateisystemzeichen sind. Dies sind die wirklichen Blocker für die Erstellung dieser Funktion.

Bitte stellen Sie sicher, dass Sie einen Charakter verwenden, der mit serverlosen Lösungen vertraut ist! (Auf Aws gibt es einige Charaktere, die Probleme verursachen können)

Das Exportieren eines Konfigurationsobjekts mit einem Komponentenschlüssel ist etwas, das ich nicht hasse.

Sie können auch einfach ein HOC verwenden

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

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

Was ist, wenn wir der Seite ein statisches Feld hinzufügen (wie 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 Was passiert, wenn Sie im Browser zu /blog navigieren? A 404?

Da dies zur Kompilierungszeit festgelegt werden muss, benötigen Sie wahrscheinlich etwas, das statisch analysierbar ist. Ein HOC oder eine statische Eigenschaft wäre das nicht.

Sie benötigen etwas, das statisch analysierbar ist. Ein HOC oder eine statische Eigenschaft wäre das nicht

Jedes bisher angegebene Beispiel für statische Eigenschaften wäre statisch analysierbar (obwohl Sie die Dinge sicherlich leicht beschädigen könnten). Wir könnten einfach darauf bestehen, dass Sie Ihre Funktion exportieren und die Route-Eigenschaft auf statisch analysierbare Weise festlegen. Die Laufzeit könnte nach Routeneigenschaften suchen, die zur Laufzeit festgelegt wurden, aber nicht von unserem statischen Analysator erfasst wurden, und eine Warnung ausgeben / einen Fehler auslösen.

Was passiert, wenn Sie im Browser zu / blog navigieren? A 404?

@kingdaro - IMO, ja. Wenn Sie sowohl die Pfade /blog als auch /blog/:blogId möchten, verwenden Sie ein Verzeichnis. Sie überladen diesen Pfad, sodass die Verzeichnisstruktur gerechtfertigt ist.

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

Ein kurzer Überblick über alle bisher genannten Charakteroptionen:

In der Reihenfolge der Erscheinung

Char | Nachteile
--- | --- ---.
$ | Dollarzeichen in Dateinamen sind eine schlechte Idee, da sie von Muscheln als Siegel verwendet werden
_ | typisch für eine interne Route
= |
@ | Splat-Operator in PowerShell
{...} | wird von Bash zum Gruppieren von Befehlen verwendet
[...] | Dateinamengenerierung in zsh
: | kein gültiger Dateiname
& | ist ein Steuerungsoperator in bash, der die linke Seite des Arguments in einer asynchronen Subshell ausführt

Angenommen, Sie gehen diesen Weg, Sie würden es wahrscheinlich so machen, wie AMP jetzt konfiguriert ist:

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

Ich denke jedoch, dass solche Dinge später hinzugefügt werden können, wenn sie irgendwann nützlich erscheinen. Ich denke, ich würde zunächst lieber eine grundlegende Unterstützung sehen, ähnlich wie im RFC beschrieben. Holen Sie sich eine echte Verwendung damit, und verfeinern Sie dann, wo es bricht. Ich denke auch, dass die einzigen Zeichen, die berücksichtigt werden sollten, um dies zu vermeiden, die Dateisystemzeichen sind. Dies sind die wirklichen Blocker für die Erstellung dieser Funktion.

Ich denke, die Verwendung von config ist eine schlechte Idee, da Sie mehrere Dateien durchgehen müssen, um zu sehen, was tatsächlich dynamisch ist. Wenn Sie es im Dateisystem einstellen, können Sie es auf den ersten Blick sehen.

Ich frage mich, ob mehr als eine Standard-Routing-Lösung in Betracht gezogen werden sollte.

Einfaches dateibasiertes Routing ist ein großartiges Verkaufsargument für diejenigen, die Next / React noch nicht kennen oder schnell eine einfache App zum Laufen bringen möchten, aber es kann ziemlich einschränkend sein. Und es scheint mir, dass der Versuch, dynamisches Routing in dieses Muster zu integrieren, diese Einfachheit ruinieren und zu unnötiger Komplexität führen könnte, um alles dateibasiert zu halten.

Nachdem ich diese Diskussion gelesen und über meine eigene Verwendung von Next.js nachgedacht habe, denke ich, dass erstklassige Unterstützung für ein alternatives (zusätzliches) Routing-System der beste Weg sein könnte, dies zu lösen.

Ich mag einige der Out-of-the-Box-Überlegungen in diesem Thread (wie den Vorschlag, Dekorateure zu verwenden), aber diese Ideen haben definitiv ihre eigenen Probleme. Ich hoffe, wir können uns etwas Großartiges einfallen lassen 👍

Das Exportieren eines Konfigurationsobjekts mit einem Komponentenschlüssel ist etwas, das ich nicht hasse.

Sie können auch einfach ein HOC verwenden

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

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

Das ist ziemlich cool, aber ich frage mich, ob Routeninformationen auf viele Dateien verteilt sind
Dies könnte schwierig zu handhaben sein.

Mein ursprünglicher Gedanke beim Vorschlagen einer lokalen Konfiguration (in der Datei) gegenüber einer globalen Konfiguration ( route.js ) war es, die in meinem ersten Kommentar erwähnten spezifischen Szenarien anzusprechen (tief verschachtelte Dateien, die die einzige Datei in ihrem Verzeichnis sind). nicht-semantische Dateinamen und Catch-All-Parameter).

Wenn es ausschließlich in diesen Kontexten verwendet wird, ist es weitaus weniger verwirrend, da die URL direkt dem Dateisystem zugeordnet ist und nur "zusätzliche" Parameter von der lokalen Konfiguration adressiert werden.

Trotzdem bin ich mir nicht sicher, ob ich überhaupt versuchen würde, Benutzer daran zu hindern, es zu tun, wie sie wollen. Wir können die berechnete Routing-Tabelle hübsch auf der Konsole drucken oder sogar in einer vorgegebenen Datei speichern. Dies sollte ausreichen, um die Fehlerbehebung bei Routen zu unterstützen

@merelinguist Ich glaube nicht, dass = in Windows verboten ist, wie Sie in der Übersichtstabelle geschrieben haben. Sie verlinken zurück zu dem Verbot von : , aber gemäß Microsoft Windows-Dateinamensdokumenten ist das gleiche Zeichen zulässig.

Ich portiere bereits mit dynamischen Routen in einem Projekt, das ich in der Produktion verwende (hoffentlich kann ich es diese Woche live bringen).

Spezifische Frage: Unterstützt die neue Next @ Canary API-Funktion _auch_ dynamisches Routing?

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

Ich habe es gerade mit [email protected] versucht und ich bekomme eine 404 nicht gefunden, also vermute ich, dass sie noch nicht da ist. Es scheint nur sinnvoll zu sein, dass diese beiden Funktionen (API + dynamische Routen) eine Parität beim URL-Routing aufweisen.

@remy es ist noch nicht implementiert es ist auf meiner Liste, es bald zu tun

Wir sollten auch nicht nur Windows- und Linux-Systeme berücksichtigen, sondern auch andere:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

Ich möchte weitere Informationen zu meinem Vorschlag hinzufügen:

Was ist, wenn wir der Seite ein statisches Feld hinzufügen (wie 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. Entwickler können keine Laufzeitvariablen für diese Routeneigenschaft verwenden

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

1. Wenn wir ein Seitenmanifest mit diesem aktuellen RFC erstellen (wobei der Ordner ein Zeichen enthält, um zu identifizieren, dass es dynamisch ist), sehe ich keinen Unterschied, wenn wir dieses Seitenmanifest erstellen, indem wir die Datei lesen und die statische Routeneigenschaft auf der Seite finden. Genauso funktioniert Trans dynamisch ist

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

Ich gehe die Liste der bereits aufgelisteten Präfixe durch - ich frage mich, ob es einen starken Grund gibt, kein Symbolpräfix @ .

Ich bezweifle, dass es von Wert ist, aber Sie erhalten Parität mit Nuxt - was bedeutet, dass jemand, der von dem einen oder anderen wechselt, sofort weiß, wie es funktioniert.

Hat jemand darüber nachgedacht, das Präfix zu einer Benutzeroption zu machen? Es macht es für die Leute schwieriger, ein Projekt von einem anderen zu verstehen, aber es bedeutet, wenn ich wollte, könnte ich das Präfix query__{...} oder so machen.

Nur ein Gedanke.

Öffnen Sie nach dem Vorschlag von

@ scf4 Ich hatte eine Bibliothek, die ein PoC ist, die now.json Routenkonfiguration verwendet, um auch hier universelles Routing mit nextjs durchzuführen

Ich hoffe, dass das Zeit-Team auch den Routenparser in der clientseitigen Bibliothek als Open Source anbietet.

Mit Blick auf Nuxt denke ich, dass _id.js nicht schlecht ist. Ja, wir verwenden bereits _app und _document.js wie Sie erwähnt haben, und es ist nicht öffentlich routbar. Eine dynamische Route kann jedoch auch als nicht routingfähig angesehen werden, da dies eine Vorlage für viele Seiten ist

Wie würde dies für statische Site-Exporte gehandhabt werden?

(Macht nichts davon)

Ich denke auch, dass es hilfreich wäre, wenn Next.js die generierten Routen in eine einzelne Datei drucken würde (möglicherweise standardmäßig ausgeblendet). Zumindest würde es als nützliche Referenz für Personen dienen, die an einem Projekt arbeiten, aber es könnte später auch die Tür für ein leistungsfähiges dynamisches Routing öffnen.

Wenn diese Datei zur Laufzeit für die Routenbehandlung verwendet wird, können Benutzer Routen sehr einfach hinzufügen / ändern (z. B. für den komplexen Mustervergleich), ohne die Vorteile der dateisystembasierten API zu verlieren.

Dies würde einige Herausforderungen in Bezug auf die Verfolgung von manuell geänderten Routen mit sich bringen, aber wenn dies gelöst wird, denke ich, dass dies bei weitem die beste Lösung wäre.

@ scf4 Next.js kann bereits komplexe Routen mithilfe der benutzerdefinierten

Ah ja, fair genug.

Ich denke, eine einzelne Routendatei, die bearbeitet werden kann, ist sowieso eine viel bessere Option!

Ich habe einige Gedanken zum Routing mit dem Dateisystem geschrieben , kann aber meine Ergebnisse hier zusammenfassen:

• [param] erscheint am sichersten (und wird von Sapper verwendet).
• : ist Express-Benutzern vertraut, aber ich hätte _geschworen_, dass ich Probleme mit Windows FS hatte.
• $ und {param} werden für die Erweiterung von Variablen und Klammern in Shells verwendet, daher kann dies in der CLI problematischer sein.
• _ _kann_ funktionieren, aber es ist zu häufig als "privater" Indikator.

Ich persönlich habe bessere Erfahrungen mit Whitelist-Dateien für Routen ( /^index\. ) im Vergleich zu einer Blacklist ( /^_/ ) gemacht, aber das wäre ein Abwärtskompatibilitätsproblem mit /pages .

Angesichts der jüngsten Diskussionen zur Unterstützung von API-Routen (# 7297) könnte dies eine Gelegenheit sein, /api und /pages unter einem neuen Zuhause von /routes .

Allerdings ist das Next.js-Ökosystem groß genug, um inkrementelle Funktionserweiterungen zu rechtfertigen, im Gegensatz zu einem "Hey, wenn wir dies noch einmal machen müssten, würden wir es auf diese Weise tun" -Design.

Eckige Klammern ( [example] ) werden von zsh für den Mustervergleich verwendet, sodass dies auch nicht möglich wäre.

Siehe Beispiele unter Dateinamengenerierung

Klammern [] werden von zsh für den Mustervergleich verwendet, sodass dies auch nicht möglich wäre.

Scheint, als hätten sie es gerade in https://github.com/zeit/next.js/pull/7623 geschafft

Danke für die Warnung. Ich habe dort auch einen Kommentar gepostet.

Ich habe [id] ausprobiert und es ist ein Schmerz, es nur in Pfaden zu verwenden (zB cd \[id\]/view.js ). Mir scheint, doppelte Unterstriche __id (zB cd __id/view.js ) funktionieren genauso gut und können von internen Dateien / Ordnern (zB _app.js ) unterschieden werden (Albit vielleicht noch etwas verwirrend).

@AaronDDM Verwenden Sie zsh ? Sie müssen nicht [ oder ] in Bash entkommen.

Ja, das passiert auch bei mir mit zsh - super nervig mit diesen Verzeichnissen zu interagieren.

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

Und da zsh in macOS Catalina zur Standard-Shell wird , sollte vielleicht doch etwas dagegen unternommen werden ...

stimme mit __id.js überein

Hm, liebe die __ wirklich nicht, sieht für mich einfach nicht gut aus.

@merelinguist em, Jest verwendet __tests__ für den Standardtestordner. Ich denke, __ in einigen Fällen sinnvoll.

@YUFENGWANG Vielleicht, aber ich würde wenn möglich einen einzelnen Charakter bevorzugen. Letztendlich denke ich, dass die beste Lösung wäre:

1. Sinnvolle, plattformübergreifende Standardeinstellung wie =
2. Option in next.config.js zum Anpassen des verwendeten speziellen Routenzeichens
3. Dokumentation, welche Zeichen in welchen Situationen problematisch sind

Ich bin mit einem einzelnen Zeichen einverstanden, aber ich würde es vorziehen, eine Nullkonfiguration zu haben. und ich vermute, dass viele Leute alle Probleme durchgehen werden, selbst wenn Sie sie in einer Dokumentation beschreiben

Beachten Sie auch, dass = von zsh reserviert ist. Aus den Dokumenten :

Wenn ein Wort mit einem nicht in Anführungszeichen gesetzten '=' beginnt und die Option EQUALS gesetzt ist, wird der Rest des Wortes als Name eines Befehls verwendet. Wenn ein Befehl mit diesem Namen vorhanden ist, wird das Wort durch den vollständigen Pfadnamen des Befehls ersetzt.

Nur eine Idee; Was ist mit einem Suffix? Zum Beispiel könnte [email protected] oder ähnliches ausreichen. Dies kann das Problem lösen, dass Sie entkommen und über Shells und Dateisysteme hinweg arbeiten müssen, solange der Charakter gültig ist.

Diese funktionieren in zsh und bash, ohne dass bisher entkommen muss:

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

Oh. Kein Suffix, sondern eine Möglichkeit, nachfolgende URL-Parameter zu kennzeichnen.

Aus [email protected] wird also blog/:id .

[email protected]@b.js wird compare/:a/:b .

Dies könnte die tief verschachtelten einzelnen Dateiverzeichnisse lösen, gegen die ich oben Einwände erhoben habe, und das gesamte Dateisystem der Routingdefinition beibehalten.

Es sieht nicht so schick aus, aber wie wäre es mit etwas in der Art von:

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

ein Präfix _var_ Welche Art von Versuchen, JS-Variablendeklarationen nachzuahmen? Oder muss es eine super kurze Sache mit einem Charakter sein?

Wie wäre es mit ~ Zeichen?

Wie /blogs/~id .

Die Verwendung von ~ als Präfix ist ebenfalls nicht möglich, da es zum Erweitern des Basisordners in POSIX-kompatiblen Shells verwendet wird.

Jedes Zeichen, das nicht mit [0-9a-zA-Z-._] (Regex) übereinstimmt, kann nicht als Präfix für Betriebssysteme, Shells und Dateisysteme als sicher angesehen werden.

Einige Zeichen sind auch inline nicht sicher. Siehe zshs Dokumente zu Substitutionen

Ich denke auch, wir sollten nicht danach streben, ob es schick aussieht, sondern intuitiv, lesbar und einfach zu kommunizieren sein.

• Die Verwendung von Klammern für [params].js scheint eleganter und weit verbreitet zu sein. (sapper, nuxt v3?).
• Unterstreichen Sie das Präfix pages/_helper.js normalerweise für eine private Funktion, und möglicherweise sollte dies nicht gerendert werden. Auf diese Weise können wir Hilfskomponenten im Seitenordner erstellen

imho: das fühlt sich wie eine vorübergehende lösung für das größere problem an. Obwohl Routen, die auf der Dateistruktur basieren, anfangs sehr schön sind, lässt sie sich nicht gut skalieren, wenn Sie Hunderte von Routen, Parametern usw. haben. Sie haben eine Routen-Konfigurationsdatei (möglicherweise eine route.js-Datei in jedem Verzeichnis). ist eine bessere langfristige Lösung. Ich persönlich bin von nextjs wegen der sofort einsatzbereiten Funktionen (SSR, Geschwindigkeit usw.) und nicht wegen der einfachen Erstellung von Routen aus Dateien angetan.

@mmahalwy du hast den Nagel auf den Kopf getroffen.

Next.js generiert bereits eine Routenkonfiguration (basierend auf dem Dateisystem). Ich glaube, dass es die nahtloseste Lösung wäre, diese Konfiguration expliziter zu gestalten und / oder dem Benutzer zu erlauben, sie "auszuwerfen", wenn er dies wünscht

@mmahalwy @ scf4 FWIW, eine wichtige Rechtfertigung für Dateisystemrouten besteht darin, die Notwendigkeit einer zentralisierten Datei zu beseitigen. In der Tat könnte man leicht argumentieren, dass die gesamte API von Next.js für Links und Routing auf diese Einschränkung ausgelegt ist.

Das Problem bei einer Routenkonfiguration besteht darin, dass Sie sie am Ende an den Client senden müssen. Dies kann ein ziemlich umfangreiches Codepaket bedeuten, wenn Sie Routen mit einer Nummer von Hunderten bis Tausenden haben.

Es gibt jedoch einige häufige Anwendungsfälle, die (soweit ich feststellen konnte, dass dieses Problem in den letzten Monaten mehrmals mit @timneutkens besprochen wurde ) ohne eine zentralisierte Konfiguration nicht wirklich gelöst werden können. Ich habe einige davon in meinem früheren Kommentar aufgelistet, aber es gibt noch mehr.

Am einfachsten ist ein CMS-gesteuertes Blog, in dem Autoren Links zu Seiten der Website erstellen können. Sie erstellen lediglich Links mit einer einfachen alten URL, ohne zu wissen, was das zugrunde liegende Seitenmodul ist. Mit einer zentralisierten Routenkonfiguration ist es ziemlich einfach, eine URL umzukehren und herauszufinden, welche Seite geladen werden soll (meine eigene Bibliothek, der Next-Route-Resolver unterstützt diese Anwendungsfälle und alle anderen, die ich mir ausgedacht habe). .

Ich sehe nicht, wie ich die Site, an der ich arbeite, ohne Routenkonfiguration zum Laufen bringen kann. Daher habe ich mich nur darauf konzentriert, Wege zu finden, um die Routenkonfiguration innerhalb der Toleranzen der Dateigröße zu halten. Für andere Personen kann das Routing des Dateisystems mehr als ausreichend sein. Ich denke nicht, dass Routing ein Problem ist, bei dem es eine einzige Lösung gibt, die alles löst. Es geht darum, Kompromisse auszugleichen.

Wie ich bereits erwähnt habe, scheint dieser Vorschlag in Ordnung zu sein, solange er verkauft wird, um das Routing-Problem vollständig zu lösen, da dies ein wenig irreführend wäre :)

@ AndrewIngram Ich verstehe, woher du kommst, aber diese Einschränkung schränkt die Leistung von nextjs ein. Nextjs bietet so viel sofort einsatzbereit, dass es für jedes neue Projekt oder Unternehmen ein Kinderspiel sein sollte, es zu verwenden. Die Herausforderung ist jedoch die harte Meinung zum Routing, die es in Zukunft nicht mehr zu beanstanden macht (und als großes Unternehmen denken Sie immer über die Exit-Strategie nach, falls Projekte das Interesse oder die Wartung verlieren).

@mmahalwy Ich denke, Sie haben meinen Standpunkt falsch verstanden. Ich stimme Ihnen zu, ich denke nicht, dass das Routing des Dateisystems ausreicht, um das Routing-Problem als gelöst zu bezeichnen, und wäre enttäuscht, wenn es als solches präsentiert würde. Ich denke, es bietet eine Verbesserung für eine bestimmte Reihe von Anwendungsfällen, aber ich denke auch, dass es auch eine Art Routenmanifestformat für diejenigen geben sollte, die bereit sind, sich für eine andere Reihe von Kompromissen zu entscheiden (z. B. Sie und ich). .

Wenn Sie eine zentralisierte oder erweiterte Routing-Konfiguration wünschen, ist die Verwendung des benutzerdefinierten Servers und / oder externer Pakete nicht gut? Was hoffen Sie, wird hier hinzugefügt?

Von diesem RFC scheint alles nicht zum Thema zu gehören. Ich glaube nicht, dass irgendjemand, einschließlich des OP, vorgeschlagen hat, dass dies die Endlösung für das Routing ist. Dies verbessert nur das dateisystembasierte Routing.

Ich habe in den letzten Wochen die dynamischen Routen für ein Mini-Projekt verwendet (mit $ obwohl ich feststelle, dass es vor 3 Tagen im kanarischen Repo auf [param] verschoben wurde, aber trotzdem).

Ich habe gerade angefangen, getRequestHandler und ich denke, es nimmt das dynamische Routing auf der Serverseite nicht auf.

Ist das ein Fehler oder beabsichtigt (dh eine Änderung an getRequestHandler ), etwas anderes oder deaktiviert die Verwendung von getRequestHandler das dynamische Routing vollständig (was jetzt Sinn macht, wenn ich darüber nachdenke ...) ?

Wenn Sie eine zentralisierte oder erweiterte Routing-Konfiguration wünschen, ist die Verwendung des benutzerdefinierten Servers und / oder externer Pakete nicht gut? Was hoffen Sie, wird hier hinzugefügt?

Eines der Ziele hierbei ist es, die Notwendigkeit zu vermeiden, einen benutzerdefinierten Server zu erstellen, um die Verwendung mit Diensten wie Now zu vereinfachen (für die derzeit alle dynamischen Routen Teil der Konfiguration sein müssen).

Von diesem RFC scheint alles nicht zum Thema zu gehören. Ich glaube nicht, dass irgendjemand, einschließlich des OP, vorgeschlagen hat, dass dies die Endlösung für das Routing ist. Dies verbessert nur das dateisystembasierte Routing.

Hier gibt es tatsächlich einen zusätzlichen Kontext. Dieser Vorschlag hat lange auf sich warten lassen, und basierend auf vielen der Diskussionen, die ich im Zusammenhang damit gesehen habe (einschließlich derer, an denen ich direkt beteiligt war), wurde dies bis zu einem gewissen Grad gehyped, um die Notwendigkeit der Verwendung dieser Route zu beseitigen Verwaltungsbibliotheken wie Next-Routes und meine eigenen. Ich denke nicht, dass es nicht zum Thema gehört, die Anwendungsfälle hervorzuheben, die von diesem RFC nicht erfüllt werden. Einige von ihnen könnten möglicherweise durch einige Änderungen des Vorschlags erfüllt werden, andere möglicherweise nicht. Aber wie auch immer, es ist sicherlich wertvoll, das Bewusstsein für die Grenzen des Vorschlags zu schärfen?

FWIW verwenden wir FS-basierte Routen im Stil von [param] bei Pinterest (allerdings nicht Next). Es ist bisher sehr gut skaliert. Die größte Kritik ist, dass Jest [] als Regexp-Paare interpretiert, so dass es schwierig sein kann, Tests für parametrische Handler durchzuführen.

@chrislloyd Welche Erfahrungen haben Sie mit dem Erstellen und Verwalten von Dateien in diesem Format für Pfade / Dateien in verschiedenen Umgebungen gemacht, wenn man bedenkt, dass jemand zsh verwendet oder ein Tool, das diese unterschiedlich interpretiert?

Da [] für den Mustervergleich in zsh verwendet wird (und wie Sie mit Jest sagen), müssen Sie diesen Pfaden entkommen. Dies ist kein großes Problem, wenn Sie dies wissen, aber da es für Anfänger brauchbar und verständlich sein sollte, habe ich Zweifel, dass dies das richtige Format ist.

Ich habe eine Idee, ! als erforderlichen Parameter zu verwenden, wie /pages/id!.js und ? für optionale Parameter, wie in /pages/posts/id?.js .

Es gibt keine Probleme mit Präfixen wie in den obigen Diskussionen, und es ist bekannt, wie ! erforderliche Parameter darstellt und ? optionale Parameter darstellt.

Windows erlaubt keine Fragezeichen in Dateinamen und beides? und ! haben eine besondere Bedeutung in Bash.

API Routen unterstützen jetzt dynamische Parameter # 7629 🚀

@remy getRequestHandler wird voraussichtlich dynamisches Routing verarbeiten - ich habe dies nur lokal bestätigt. Könnten Sie bitte einen separaten Fehler / ein separates Problem mit Reproduktionsschritten einreichen, damit wir dies untersuchen können? :beten:

Hallo allerseits! Vielen Dank für die unglaubliche Resonanz auf diesen RFC.

Dieser RFC wurde in Next.js 9 implementiert und als stabil veröffentlicht.
Sie können mehr darüber im Blog-Beitrag lesen.

Wir werden in Zukunft einen neuen RFC veröffentlichen, um alle hier gegebenen erweiterten Rückmeldungen zu berücksichtigen. Wir werden hier ein Update veröffentlichen, sobald es verfügbar ist.