Next.js: [RFC] Dynamische Routen

Erstellt am 19. Juni 2019  Â·  90Kommentare  Â·  Quelle: vercel/next.js

Dynamische Routen

Hintergrund

Dynamisches Routing (auch als URL Slugs oder Pretty / Clean URLs bezeichnet) ist eine seit langem angeforderte Funktion von Next.js.

Aktuelle Lösungen umfassen das Platzieren eines L7-Proxys , eines benutzerdefinierten Servers oder einer Benutzerland-Middleware vor Ihrer Anwendung. Keine dieser Lösungen bietet eine ausreichend _ergonomische_ Entwicklererfahrung.

DarĂŒber hinaus deaktivieren Benutzer, die nach einem benutzerdefinierten Server greifen, versehentlich erweiterte Funktionen auf Framework-Ebene wie serverlose Funktionen pro Seite.

Tore

  1. Nutzen Sie die Konvention, um URL Slug-UnterstĂŒtzung bereitzustellen, ĂŒber die Sie leicht nachdenken können
  2. Decken Sie einen Großteil der in freier Wildbahn beobachteten AnwendungsfĂ€lle ab
  3. Beseitigen Sie die Notwendigkeit eines benutzerdefinierten Servers zur UnterstĂŒtzung von /blog/:post
  4. ÜberprĂŒfen Sie nach Möglichkeit <Link /> RoutenĂŒbergĂ€nge
  5. Vermeiden Sie eine Implementierung, fĂŒr die ein Routenmanifest erforderlich ist
  6. Routen mĂŒssen ĂŒber das Dateisystem ausdrĂŒckbar sein

Vorschlag

Next.js sollte benannte URL-Parameter unterstĂŒtzen, die mit einem gesamten URL-Segment ĂŒbereinstimmen. Diese Routen wĂŒrden ĂŒber das Dateisystem ausgedrĂŒckt:

  1. Ein Dateiname oder Verzeichnisname, der mit [] umschlossen ist, wird als benannter Parameter betrachtet
  2. Explizite Routensegmente haben Vorrang vor dynamischen Segmenten, die von links nach rechts abgeglichen werden
  3. Routenparameter wÀren erforderlich , niemals optional
  4. Routenparameter werden in das Objekt query (Zugriff ĂŒber getInitialProps oder router ĂŒber withRouter ) - diese Parameter können nicht durch einen Abfrageparameter ĂŒberschrieben werden

Um diesen Vorschlag besser zu verstehen, untersuchen wir den folgenden Dateibaum:

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

Next.js wĂŒrde die folgenden Routen erzeugen, die in der folgenden Reihenfolge registriert sind:

;[
  { path: '/', page: '/index.js' },
  { path: '/blog/:id', page: '/blog/[id].js' },
  { path: '/customers', page: '/customers/index.js' },
  { path: '/customers/new', page: '/customers/new.js' },
  { path: '/customers/:customer', page: '/customers/[customer]/index.js' },
  {
    path: '/customers/:customer/profile',
    page: '/customers/[customer]/profile.js',
  },
  { path: '/customers/:customer/:post', page: '/customers/[customer]/[post].js' },
  { path: '/terms', page: '/terms.js' },
  { path: '/:root', page: '/[root].js' },
]

Anwendungsbeispiele

Diese Beispiele setzen alle eine Seite mit dem Dateinamen pages/blog/[id].js voraus:

Navigieren zur Seite mit <Link />

<Link href="/blog/[id]" as="/blog/how-to-use-dynamic-routes">
  <a>
    Next.js: Dynamic Routing{' '}
    <span role="img" aria-label="Party Popper">
      🎉
    </span>
  </a>
</Link>

Das obige Beispiel wechselt zur Seite /blog/[id].js und stellt dem _Router_ das folgende Objekt query zur VerfĂŒgung:

{
  id: 'how-to-use-dynamic-routes'
}

Lesen benannter Parameter aus _Router_

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

export default BlogPost

Hinweis: Sie können auch withRouter .

Lesen benannter Parameter in getInitialProps

function BlogPost({ blogText }) {
  return <main>{blogText}</main>
}

BlogPost.getInitialProps = async function({ query }) {
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = query.id

  const { text } = await fetch(
    '/api/blog/content?id=' + encodeURIComponent(blogId)
  ).then(res => res.json())

  return { blogText: text }
}

export default BlogPost

Vorsichtsmaßnahmen

Optionale Routenparameter können nicht ĂŒber das Dateisystem ausgedrĂŒckt werden.

Sie können einen optionalen Routenparameter emulieren, indem Sie eine Stub-Seite erstellen, die die Parameterversion exportiert (oder umgekehrt). Dies erhöht die Sichtbarkeit der Routen Ihrer Anwendung bei der ÜberprĂŒfung des Dateisystems.

// pages/blog/comments.js
// (the optional version of `pages/blog/[id]/comments.js`)
export { default } from './[id]/comments.js'

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 Seite 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.

Alternativen

Kennzeichnen Sie URL-Slugs mit dem Symbol _insert here_ anstelle von []

Es stehen nur sehr wenige Symbole zur Darstellung eines benannten Parameters im Dateisystem zur VerfĂŒgung. Leider ist die bekannteste Methode zum Definieren eines benannten Parameters ( :name ) kein gĂŒltiger Dateiname .

Bei der Untersuchung des Standes der Technik wurden als hĂ€ufigste Symbole fĂŒr einen Parameter _ , $ und [] .

Wir haben _ da _ normalerweise auf eine interne Route hinweist, die nicht öffentlich routbar ist (z. B. _app , _document , /_src , /_logs ).
Wir haben auch $ weil es ein Siegel in der Bash fĂŒr die Parametererweiterung ist.

Nutzen Sie path-to-regexp fĂŒr umfassenden Support

Die meisten Symbole, die zum AusdrĂŒcken von Regex erforderlich sind, sind keine gĂŒltigen Dateinamen . DarĂŒber hinaus reagieren komplexe regulĂ€re AusdrĂŒcke empfindlich auf die Routenreihenfolge zur Priorisierung. Das Dateisystem kann weder eine Reihenfolge ausdrĂŒcken noch Regex-Symbole enthalten.

In Zukunft können wir möglicherweise path-to-regexp Routen zulassen, die in next.config.js oder Ă€hnlichem definiert sind. Dies ist derzeit fĂŒr diesen Vorschlag nicht möglich.

ZukĂŒnftige Erforschung

Catch-All-Parameter

In Zukunft können wir erwĂ€gen, alle Parameter hinzuzufĂŒgen. Nach dem, was wir bisher wissen, mĂŒssen diese Parameter am Ende der URL stehen und wĂŒrden möglicherweise % , um eine Sammelroute zu bezeichnen (z. B. pages/website-builder/[customerName]/%.tsx ).

Hilfreichster Kommentar

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 ).

Alle 90 Kommentare

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

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 .

compare@[email protected] 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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen