Next.js: Sollte /page/ genauso funktionieren wie /page ?

Für mich macht das Sinn.

Ich persönlich halte diesen Workflow für sinnvoll.

1. page.js existiert -> /page & /page/ funktioniert und geht an denselben Ort
2. page/index.js existiert, page.js nicht -> /page würde 404, /page/ würde zu index.js werden
3. page.js existiert ebenso wie page/index.js -> /page würde zu page.js gehen, /page/ würde zu page/index.js gehen

Mit anderen Worten, /page/ würde zuerst den Index im Ordner versuchen und dann auf die Erweiterung /page.js zurückgreifen

irgendwie verwandt #619

Ich stimme Ihrer Argumentation @ krhome83 größtenteils zu, aber Ihre Aussage in Punkt 2 (_/Seite würde 404_) ist nicht logisch konsistent

1. In Punkt 1) schlagen Sie vor, dass ein abschließender Schrägstrich in der URL ( /page/ ), der normalerweise ein _Verzeichnis_ anzeigt, aufgelöst werden sollte, wenn die zugrunde liegende Darstellung eine Datei ist ( ./pages/page.js ).
2. In Punkt 2) suggerieren Sie das Gegenteil. Dass /page als URL, die normalerweise eine Datei_ angibt, sollte 404 anzeigen, wenn die zugrunde liegende Darstellung ein Ordner ./pages/page/ ist.

Lassen Sie mich wissen, wenn ich nicht auf der Basis bin, aber ansonsten würde ich gerne eine „intelligente Standardeinstellung“ für dieses Szenario hinzufügen (da wir auch eine benutzerdefinierte Serverüberschreibung für https://zeit.co haben), vorausgesetzt, dass wir können es in der Konfiguration ausschalten ( smartSlashes: false ?)

Außerdem frage ich mich, ob dies eine Warnung oder ein Fehler sein sollte, da es irgendwie nicht offensichtlich ist

1. page.js existiert ebenso wie page/index.js -> /page würde zu page.js gehen, /page/ würde zu page/index.js gehen

IMHO sollten wir in diesem Fall wahrscheinlich einen Fehler machen, _es sei denn_ Sie schalten smartSlashes aus, und die meisten Leute würden wahrscheinlich ./pages/index für das verwenden, was sie sonst in ./page handhaben wollten

Ich denke, die beste Option ist eine Umleitung von $ 301 zu /page/ zu /page

301 würde _permanent_ bedeuten, also vielleicht keine gute Idee

Yep 301 Ich meine es ernst.
Brauchen wir /page/ , um in Zukunft auf andere Weise zu dienen?

Ich denke, wir nicht.

Stimmen Sie der 301-Weiterleitung zu. Schön und einfach.
Sie möchten aus SEO-Gründen 301 statt 302 verwenden. Stellt sicher, dass Google zwei Links nicht als gleichwertig ansieht.

https://moz.com/learn/seo/redirection

Diesen Link Juice müssen wir pflegen!

Viele Leute verwenden nachgestellte Schrägstriche und viele nicht, aber es ist besser, nur eine Version davon laut SEO beizubehalten, sonst wird es laut Google zu ernsthaften Problemen führen.

Wir behalten einen abschließenden Schrägstrich bei und ich bin mir nicht sicher, wie ich das in next js machen kann.

Irgendwelche Ideen?

@harshmaur Sie können einen benutzerdefinierten Server erstellen, um URLs mit einem abschließenden Schrägstrich zu verarbeiten, oder Sie können pages/my-page/index.js erstellen, sodass Ihre URL (mit dem Standardrouter) /my-page/

@sergiodxa Vielen Dank, ich habe darüber nachgedacht, server.js zu verwenden, um benutzerdefinierte Routen für alle meine Seiten zu erstellen, anstatt den Standardrouter zu verwenden. Aber ich bin mir nicht sicher, wie das auf der Client-Seite funktionieren würde. Ich muss das überprüfen.

@harshmaur Überprüfen Sie das benutzerdefinierte Serverbeispiel , insbesondere , wie Sie next/link verwenden

Ich glaube, ich laufe gerade in so etwas hinein.

Bei Verwendung einer next/link -Instanz zeigt das gerenderte Ankerelement auf /foo und das statische Element auf /foo , aber der Prefetcher bringt mich zu /foo/ , was Mein Analyseteam sagt, dass dies ein No-Go ist. Mein Server ist so konfiguriert, dass er die Seite /foo perfekt anbietet. (Ich verwende auch die Funktion next export ).

Ich glaube, das ist die relevante Zeile in _rewriteUrlForNextExport() https://github.com/zeit/next.js/blob/cc9b1d6ce071bc40b52326f7bb01ecb8ff0657be/lib/router/index.js#L101

@rauchg wäre das das Ziel deiner vorgeschlagenen smartSlashes Flagge?

SEO-weise 301-Weiterleitung wird definitiv bevorzugt, aber ob der abschließende Schrägstrich am Ende entfernt oder stattdessen erzwungen wird, ist eine Frage.

Beachten Sie, dass neben den bereits oben erwähnten Unterschieden diese Pfade mit relativen URLs anders funktionieren:

/foo/ with href=`test` will be `/foo/test`
/foo with href=`test` will be `/test`

Das liegt daran, dass für Browser, egal was Sie denken und wie Server Ressourcen auflösen, jede URL mit abschließendem Schrägstrich ein Verzeichnis ist, während ohne einen ein Dokument ist. Daher wird die Auflösung für relative Ressourcen unterschiedlich sein. Dies bedeutet, dass Sie durch das Erzwingen eines bestimmten Verhaltens (nachstehender Schrägstrich oder Fehlen eines Schrägstrichs) effektiv eine Möglichkeit entfernen, relative URLs auf unterschiedliche Weise zu behandeln.

Dies sollte kein wirkliches Problem sein, da, soweit ich mich erinnere, in React-Router nicht einmal relative Pfade unterstützt werden. Aber trotzdem erwähnenswert.

Außerdem ist die SEO-technische 301-Weiterleitung leider eine sehr empfehlenswerte Sache für endende Schrägstriche. Andernfalls müssen zumindest kanonische URLs angegeben werden.

Ich habe mich auch mit diesem Thema beschäftigt. Erwähnenswert ist, dass beim Exportieren einer Seite als HTML-Endpunkt wie dem folgenden ein zusätzlicher Backslash verursacht wird:

{
  exportPathMap: () => ({
          "/about.html": { page: "/about" }
  })
}

Dadurch funktionieren einfache Dinge wie ein Anker nicht mehr richtig

http://localhost:8080/about.html#contact

ist nicht dasselbe wie

http://localhost:8080/about.html/#contact

@arunoda @sergiodxa Würdet ihr einen PR in Betracht ziehen, um den zusätzlichen Backslash in _rewriteUrlForNextExport zu vermeiden, wenn der Pfad mit .html endet?

Ich habe das gleiche Problem. Ich wende das offizielle Beispiel "with-apollo-and-redux" an. https://github.com/zeit/next.js/tree/master/examples/with-apollo-and-redux

Ich habe eine Seite/einen Test erstellt. Wenn ich localhost:3000/test all durchsuche, ist es okey. Aber wenn ich localhost durchsuche: 3000/test/

GET http://localhost:3000/test/ 404 (Not Found)
client.js?ecc360b:67 [HMR] connected
warning.js?1713c82:35 Warning: Failed prop type: The prop `serverState` is marked as required in `WithData(Test)`, but its value is `undefined`.
    in WithData(Test) (created by Container)
    in Container (created by App)
    in div (created by App)
    in App

Aber die Seite lädt (mit allen Nachrichten in der Konsole)

Vielleicht ein Temp-Fix.

server.js

const { createServer } = require('http')
const { parse } = require('url')
const next = require('next')

const port = parseInt(process.env.PORT, 10) || 3000
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare()
.then(() => {
  createServer((req, res) => {
    const parsedUrl = parse(req.url, true)
    const { pathname, query } = parsedUrl

    if (pathname.length > 1 && pathname.slice(-1) === '/') {
      app.render(req, res, pathname.slice(0, -1), query)
    }
    else {
      handle(req, res, parsedUrl)
    }

  })
  .listen(port, (err) => {
    if (err) throw err
    console.log(`> Ready on http://localhost:${port}`)
  })
})

Paket.json

...
"scripts": {
    "dev": "node server.js",
    ...
  },
....

Jetzt funktioniert das gut, bis auf einen Fehler beim ersten Rendern.

process-update.js?0be4961:122 [HMR] Update check failed: Error: Manifest request to /_next/webpack/53918e2236aadcc582cd.hot-update.json timed out.
    at XMLHttpRequest.request.onreadystatechange (http://localhost:3000/_next/1504017609143/manifest.js:68:22)

@hmontes Aber das wird keine Lösung für statische Exporte sein.

Ich würde eine interne Lösung dafür lieben, die mit Next-Routes funktioniert.

Behoben in next 5 / canary

URL mit abschließendem Schrägstrich führt zu einem 404-Fehler mit [email protected] , sollte das in dieser Version behoben werden?

@timneutkens Sollte dies wiedereröffnet werden?

Ein weiteres ähnliches Problem ist die Unterstützung mehrerer Schrägstriche, da Benutzer leicht zwei davon übersehen können. Beispiel: https://github.com/zeit/next.js////////////issues/1189

Bitte sehen Sie sich https://github.com/zeit/next.js/issues/3876#issuecomment -384709274 an, wo ich ein minimales Beispiel geteilt habe, bei dem nachgestellte Schrägstriche nicht zu funktionieren scheinen.

Als Referenz:
https://zeit.co/blog/new-static-deployments

Ist das nicht nur für den statischen / nächsten Export?

Ich habe ein neues Problem mit einem minimal reproduzierbaren Repository in #5214 eingereicht

Wie ist der Stand zu diesem Thema? Es ist schon seit geraumer Zeit geöffnet. Mir ist gerade aufgefallen, dass /page/ immer noch zu einem 404 führt. Ich verwende v7.0.1 .

Mit v7.02 habe ich ein page.js , also funktioniert /page , aber /page/ führt zu einem 404.

Was ist die Problemumgehung?

Für das, was es wert ist, habe ich ein Force-Trailing-Slash- Dienstprogramm bei next-i18next implementiert , um dieses Problem zu umgehen. In der Zwischenzeit würde ich den Leuten vorschlagen, ihre eigenen Middlewares zu implementieren.

@timneutkens Hallo, sollte dieses Problem erneut geöffnet werden? Mit der aktuellen Version funktioniert es immer noch nicht

Das ist ein Desaster! Es tut der SEO sehr weh. Die Seite wird in der Google-Suche als „/contact/“ angezeigt und gibt 404 zurück. Was ist die Lösung?

ping @timneutkens , es scheint, dass viele Leute für die Wiedereröffnung stimmen. Gibt es Pläne, es wieder zu öffnen?

@rap2hpoutre Wie ist der Status dieses Problems?

@dryleaf Immer noch keine Antwort. Vielleicht sollten wir ein neues Thema eröffnen.

@rap2hpoutre es ist bereits #5214 geöffnet

Nähte fixiert.

Die Seite ist mit oder ohne abschließendem Schrägstrich zugänglich. Beide geben HTTP 200 zurück.

Ich verwende Next.js v9.3.0

Nähte fixiert.

Die Seite ist mit oder ohne abschließendem Schrägstrich zugänglich. Beide geben HTTP 200 zurück.

Ich verwende Next.js v9.3.0

Ich verwende Next.js v9.3.0 und funktioniert nicht

@javiercno siehe #5214

Können wir das wieder öffnen?
Ich kann die Route immer noch nicht mit dem abschließenden Schrägstrich abgleichen.
Verwendung von 9.3.1 mit benutzerdefiniertem Server.

@timneutkens gibt es eine Hoffnung, dass dies bald behoben werden könnte?

@untitledlt siehe #5214

Nähte fixiert.

Die Seite ist mit oder ohne abschließendem Schrägstrich zugänglich. Beide geben HTTP 200 zurück.

Ich verwende Next.js v9.3.0

Ich verwende Next.js v9.3.0 und funktioniert nicht. Können wir diesen Fehler erneut öffnen?

@iamstarkov Ich habe dein Problem gesehen. Es gibt sogar meinen Kommentar vor 3 Tagen.

Wie gesagt ist dies bereits in #5214 offen

Ich werde dieses Problem sperren, da es hier keine umsetzbaren Kommentare gibt.