Next.js: Funktionsanforderung: Basepath-Unterst├╝tzung

Erstellt am 21. Aug. 2018  ┬Ě  73Kommentare  ┬Ě  Quelle: vercel/next.js

Featureanfrage

Bezieht sich Ihre Funktionsanforderung auf ein Problem? Bitte beschreiben.

Multi Zones ist eine gro├čartige Funktion, mit der mehrere next.js-Apps in derselben Domain ausgef├╝hrt werden k├Ânnen. Es ist jedoch nicht m├Âglich, einen Basispfad zu definieren, der von allen Teilen von next.js akzeptiert wird. Da wir derzeit keine Namespace-Apps verwenden k├Ânnen, ist es nicht m├Âglich, f├╝r Seiten in verschiedenen Apps dieselben Namen zu verwenden.

Beschreiben Sie die gew├╝nschte L├Âsung

Ich m├Âchte in der Lage sein, ein basepath in der Datei next.config.js zu konfigurieren. Dank dieser Konfiguration kennen alle Teile von next.js (Router, Link, statische Assets usw.) den Basispfad und generieren automatisch die richtigen Pfade und stimmen diese ab.

Beschreiben Sie Alternativen, die Sie in Betracht gezogen haben

Eine Alternative besteht darin, alle gew├╝nschten Seiten in einem Ordner zu verschachteln, der dem Basispfad entspricht. Dies l├Âst nur ein kleines Problem mit dem Routing und ist ziemlich h├Ąsslich, da die meisten meiner Basispfade keine einstufigen Pfade sind.
Die zweite Alternative besteht darin, einen Proxy so zu konfigurieren, dass der Basispfad automatisch entfernt wird, bevor die Anforderung in einer next.js-App eingeht, und eine benutzerdefinierte Link-Komponente zu implementieren, die allen Links automatisch den Basispfad hinzuf├╝gt. Ich m├Âchte nur keine benutzerdefinierte Gabel von next.js beibehalten. Das macht meiner Meinung nach keinen Sinn.

Zus├Ątzlicher Kontext

Mit der assetPrefix -L├Âsung k├Ânnen wir f├╝r jede App ein anderes Pr├Ąfix definieren. Aber so fair wie ich wei├č, funktioniert es nur mit verschiedenen Hosts.

Beispiel f├╝r With-Zones

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}` : 'http://localhost:4000'
}

Wenn ich einen Basispfad hinzuf├╝ge, schl├Ągt alles fehl

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}/account` : 'http://localhost:4000/account'
}

screen shot 2018-08-21 at 10 47 08

Meiner Meinung nach sollten wir es in 2 Variablen aufteilen:

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}` : 'http://localhost:4000',
  basepath: '/account'
}

Verwandte Themen

story needs investigation

Hilfreichster Kommentar

Jedes Update dazu ... letztes Jahr um diese Zeit bin ich auf dieses Problem gesto├čen. Jetzt, ein Jahr sp├Ąter, arbeite ich an einer neuen App und muss die gleichen Problemumgehungen wie im letzten Jahr durchf├╝hren ... irgendwie alarmierend f├╝r eine "produktionsbereite" Reaktion fw. Basispfade sollten ein Vanille-Merkmal sein.

Ich bin mir nicht sicher, was Sie erwarten, wenn Sie dies ver├Âffentlichen.

Next.js wird von meinem Team (5 Personen) in Vollzeit bearbeitet, und wir arbeiten gleichzeitig an vielen Funktionen. Im vergangenen Jahr haben wir daran gearbeitet:

Effektiv machen Next.js-Anwendungen (neu und vorhanden) erheblich kleiner, schneller und skalierbarer.

Wenn Sie Ihre "Gegenstimme" f├╝r eine Funktion ├Ąu├čern m├Âchten, k├Ânnen Sie. Verwenden Sie die Funktion ­čĹŹ f├╝r den ersten Thread.

Ich bin definitiv der Meinung, dass basePath eine integrierte Funktion sein sollte. Es ist bereits auf der Roadmap und ich habe sogar eine erste PR geschrieben, die Sie durch Zur├╝cklesen des Threads h├Ątten sehen k├Ânnen.

Hier ist die PR: https://github.com/zeit/next.js/pull/9872

Wenden Sie sich an [email protected], wenn Sie einen finanziellen Beitrag zur Umsetzung dieser Funktion leisten m├Âchten.

Alle 73 Kommentare

cc @jxnblk

cc @alexindigo @DullReferenceException

W├╝rde mich ├╝ber Ihr Feedback freuen ­čĹŹ

Nachdem ich mit dem Code gespielt hatte, wurde mir klar, dass es viel einfacher sein w├╝rde, assetPrefix in mehrere Teile aufzuteilen:

module.exports = {
  host: NOW_URL ? `https://${alias}` : 'http://localhost:3000',
  basePath: '/account',
}

Wir k├Ânnen die Variable assetPrefix intern weiterhin beibehalten, aber der Benutzer sollte genauer definieren, was er ben├Âtigt.

F├╝r den Asset-Teil ist es wirklich in Ordnung, diese beiden Variablen zusammen bereitzustellen.
F├╝r das Routing usw. ben├Âtigen wir sie separat.
Oder vielleicht k├Ânnen wir es sogar zusammen in einer Konfigurationsdatei bereitstellen und es dann in die Codebasis next.js aufteilen. In diesem Fall ist AssetPrefix leider nicht der richtige Name.

Als Nebeneffekt f├╝hrt dies auch zu weniger Code├Ąnderungen.
Es ist ziemlich offensichtlich, wenn Sie diese beiden PRs vergleichen:
https://github.com/panter/next.js/pull/2 (aufgeteilt)
https://github.com/panter/next.js/pull/1 (beide bestehen)

Meiner Meinung nach sollten sie getrennt sein. Der Grund daf├╝r ist, dass es nicht kaputt und flexibler ist, assetPrefix zu behalten und basePath separat zu haben.

Ist assetPrefix der richtige Name? Beide Variablen sind eigentlich ein Pr├Ąfix, oder?

assetPrefix gilt f├╝r Assets, z. B. die Seitenpakete. basePath ist f├╝r den Router.

Die Art und Weise, wie es funktionieren sollte, ist:

  • Wenn assetPrefix definiert ist, verwenden Sie assetPrefix , um Bundles zu laden. Ber├╝hren Sie nicht den Router (aktuelles Verhalten).
  • Wenn assetPrefix und basePath bereitgestellt werden, verwenden Sie assetPrefix , um Bundles zu laden, und f├╝gen Sie basePath zum Router hinzu
  • Wenn assetPrefix nicht definiert ist und basePath ist, verwenden Sie basePath , um Bundles zu laden, und f├╝gen Sie basePath zum Router hinzu
  • Wenn weder assetPrefix noch basePath definiert sind, machen wir nichts anderes (aktuelles Verhalten, wenn assetPrefix nicht angegeben ist)

cc @alexindigo @DullReferenceException @ 3rd-Eden

K├Ânnten Sie Feedback zu dem oben genannten Vorschlag geben: https://github.com/zeit/next.js/issues/4998#issuecomment -414978297

@tomaswitek Ich assetPrefix f├╝r Sie nicht funktioniert hat. Dies ist das Asset-Pr├Ąfix, das wir in der Produktion verwenden: "assetPrefix":"https://static.trulia-cdn.com/javascript" und es funktioniert wie erwartet.

Und im Allgemeinen verwenden wir mehrere Zonen (wir nennen sie Inseln) in derselben Dom├Ąne, und "basePathing" f├╝r jede Insel ist uns nie in den Sinn gekommen, da dies die Interoperabilit├Ąt zwischen den Inseln erschweren w├╝rde. Lassen Sie mich noch etwas n├Ąher darauf eingehen:

Wir haben also zwei Inseln A und B , und die Hauptidee dabei ist Transparenz f├╝r die Benutzer, die im Rahmen ihrer Erfahrung mit einer Website von Insel zu Insel navigieren. Es sollte also Verbindungen zwischen den Inseln geben. Dann gibt es Bedenken hinsichtlich der Bereitstellung und der Anwendung.

  1. Bedenken hinsichtlich der Bereitstellung und der Anwendung - Die Anwendung hat keine Ahnung, wo sie bereitgestellt werden k├Ânnte. Sie wei├č nur, wie eingehende http-Anforderungen behandelt werden. Sie hat Routen festgelegt, auf die sie reagieren kann.
    Wenn es irgendwo bereitgestellt wird - es k├Ânnen verschiedene Dom├Ąnen, verschiedene Ports und theoretisch verschiedene basePath sein, die f├╝r die App ├╝ber einen Proxy oder andere Mittel transparent gemacht werden.

  2. Querverbindungen zwischen den Inseln - um den Geist der Inseln als separate einsetzbare Einheiten zu bewahren, sollten keine internen Implementierungswissenslecks zwischen verschiedenen Inseln auftreten.
    Der beste Weg f├╝r Inseln, Seiten voneinander zu referenzieren, besteht darin, verf├╝gbare Routen f├╝r andere Inseln zu exportieren, um sie zu konsumieren (_und in der n├Ąchsten Welt sieht es so aus, als w├Ąren benutzerdefinierte <IslandALink> -Komponenten bevorzugt Weg_).
    Bisher ist alles unkompliziert - alle Inseln gehen davon aus, dass sie dieselbe Domain teilen und ihre absoluten Pfade haben ( /path1 , path2 usw.). Auf diese Weise importiert die zweite Insel diese Liste von Pfaden und verl├Ąsst sich darauf, dass sie stabil ist. Gleichzeitig ist es ziemlich minimal, dass jede Insel ihre Pfade abw├Ąrtskompatibel h├Ąlt (was im Web sowieso gut ist) :)

Wenn wir einen implementierungsspezifischen basePath hinzuf├╝gen, erh├Âhen wir automatisch die Komplexit├Ąt des gesamten Systems. Sollte jede Insel ihren eigenen basePath f├╝r die Bereitstellung kennen (und m├Âglicherweise diktieren)? Wie unterscheidet es sich dann von der aktuellen Arbeitsweise? Oder sollte Insel A unabh├Ąngig von ihrem Einsatzpfad sein? Wie wird dann Insel B die eingesetzte Insel A finden, da sie nur wei├č, was Insel A ├╝ber sich selbst wei├č? Oder m├╝ssten Sie basePath f├╝r alle bereitgestellten Inseln an alle anderen Inseln liefern? Und mit der modernen Art der Bereitstellung bedeutet dies, dass alle Inseln erneut bereitgestellt werden, wenn Sie eine neue hinzuf├╝gen m├╝ssen.

Oder wie haben Sie sich diesen Teil der Geschichte vorgestellt?

Vielen Dank.

^ Es wurde vor dem Morgenkaffee geschrieben. Bitte lassen Sie mich wissen, wenn Sie eine koh├Ąrentere Erkl├Ąrung f├╝r Teile davon ben├Âtigen. :) :)

Zun├Ąchst einmal vielen Dank, dass Sie sich die Zeit genommen haben, mein Problem zu ├╝berpr├╝fen.

@timneutkens Ja assetPrefix hat Vorrang vor basePath , genau das haben wir zu Beginn besprochen. Nachdem ich gesehen hatte, wie viele Dateien ich ├Ąndern musste, dachte ich, der zweite Weg w├Ąre sauberer. Aber ich werde zur ersten L├Âsung zur├╝ckkehren. Lassen Sie es uns v├Âllig getrennt halten, ├╝berhaupt kein Problem. Ich habe nur laut nachgedacht.

@alexindigo Danke f├╝r deine ausf├╝hrliche Antwort. Lassen Sie mich versuchen, Ihre Fragen zu beantworten ­čśĆ

Ich bin mir nicht sicher, was genau mit dem aktuellen AssetPrefix f├╝r Sie nicht funktioniert hat

Ich habe hier zwei Probleme:

  1. Ich kann im aktuellen Projekt nicht mit mehreren Dom├Ąnen oder Subdom├Ąnen arbeiten. (Domain-Einschr├Ąnkungen und kein Wildcard-SSL-Zertifikat)
  2. Die aktuelle Implementierung von assetPrefix in einer einzelnen Domain erfordert weitere Anpassungen beim Proxy-Routing, bei statischen Dateien usw. Wir k├Ânnten diese Anpassungen durch die Einf├╝hrung von basePath reduzieren. Es wird nichts bremsen und die Komplexit├Ąt nicht erh├Âhen, da Sie nicht die basePath angeben m├╝ssen, wie

Die Anwendung hat keine Ahnung, wo sie bereitgestellt werden k├Ânnte

Wir haben hier nat├╝rlich das gleiche Ziel! Wir definieren AssetPrefixes dynamisch in der aktuellen L├Âsung, die wir haben. Es wird ├╝ber Anforderungsheader vom Proxy bereitgestellt.

Wie unterscheidet es sich dann von der aktuellen Arbeitsweise?

Der Router kennt contextPath und reduziert die Menge an benutzerdefiniertem Code.

Sollte jede Insel ihren eigenen Deployment BasePath kennen (und vielleicht diktieren)? Oder sollte Insel A unabh├Ąngig von ihrem Einsatzpfad sein?

Das muss nicht sein. Der Entwickler sollte hier Freiheit haben. Es sollte m├Âglich sein, basePath dynamisch auf dieselbe Weise wie assetPrefix bereitzustellen.

Wie wird dann Insel B die eingesetzte Insel A finden, da sie nur wei├č, was Insel A ├╝ber sich selbst wei├č? Oder m├╝ssten Sie basePath f├╝r alle bereitgestellten Inseln an alle anderen Inseln liefern? Und mit der modernen Art der Bereitstellung bedeutet dies, dass alle Inseln erneut bereitgestellt werden, wenn Sie eine neue hinzuf├╝gen m├╝ssen.

Vielleicht k├Ânnen Sie den basePath auch zum Routenexport hinzuf├╝gen. Ich wei├č es nicht. Ich sage nicht, dass die Variable basePath f├╝r jeden Anwendungsfall wichtig ist. Es sieht so aus, als w├Ąre es nicht die beste L├Âsung f├╝r Sie. Aber das ist v├Âllig in Ordnung. Die Sache ist, dass Sie immer noch nur assetPrefix und sich f├╝r Ihre Inseln nichts ├Ąndern wird. Es sieht so aus, als h├Ątten Sie sowieso Ihr eigenes Routing. Querverbindungen zwischen Zonen sind f├╝r unser Projekt nicht einmal wichtig, unsere Zonen sind wirklich unabh├Ąngig und voneinander isoliert.

Und mit der modernen Art der Bereitstellung bedeutet dies, dass alle Inseln erneut bereitgestellt werden, wenn Sie eine neue hinzuf├╝gen m├╝ssen.

Ich sehe keinen Grund warum. Ich kann mir sogar vorstellen, dass einige Zonen basePaths haben und andere nicht. Und vielleicht verwenden einige Apps die basePath-Konfiguration auch ohne Einrichtung mehrerer Zonen.

@alexindigo K├Ânnten Sie uns bitte zwei echte Insel-URLs zur Verf├╝gung stellen, die von next.js gerendert werden, damit ich sie in Aktion sehen kann? Ich habe versucht, eine zu finden, konnte jedoch keine Seite in Ihrer Domain mit _next -Anfragen ­čśä finden
Haben alle Ihre Inseln die gleiche Konfiguration?
"assetPrefix":"https://static.trulia-cdn.com/javascript"

@tomaswitek

Ich kann im aktuellen Projekt nicht mit mehreren Dom├Ąnen oder Subdom├Ąnen arbeiten. (Domain-Einschr├Ąnkungen und kein Wildcard-SSL-Zertifikat)

Oh, Sie verwenden CDN also nicht im klassischen Sinne, sondern verlassen sich darauf, dass Assets direkt von jeder App abgerufen werden? Aha.

Die aktuelle Implementierung von AssetPrefix in einer einzelnen Dom├Ąne erfordert weitere Anpassungen beim Proxy-Routing, bei statischen Dateien usw. Wir k├Ânnten diese Anpassungen durch die Einf├╝hrung von basePath reduzieren. Es wird nichts bremsen und die Komplexit├Ąt nicht erh├Âhen, da Sie den basePath nicht wie bereits erw├Ąhnt als @timneutkens angeben

├ťbrigens war es nicht "Nein, f├╝ge diese Funktion nicht hinzu" :) Es war eher wie - "Wahrscheinlich k├Ânnen wir diesen Ansatz ganzheitlicher betrachten" :)

Das muss nicht sein. Der Entwickler sollte hier Freiheit haben. Es sollte m├Âglich sein, basePath dynamisch auf dieselbe Weise wie assetPrefix bereitzustellen.

Ja. Es funktioniert jedoch nur, wenn keine Verbindung zwischen den Inseln besteht. Und das klingt so, als w├Ąre dies Ihr Anwendungsfall. Gleichzeitig f├Ąllt es mir schwer zu verstehen, was sie zu Inseln macht, anstatt nur eine Reihe von eigenst├Ąndigen Anwendungen zu sein, wenn sie zu 100% unabh├Ąngig sind. :) :)

Vielleicht k├Ânnen Sie den basePath auch zum Routenexport hinzuf├╝gen.

Ich sehe nicht, wie es (einfach) gemacht werden k├Ânnte, da der Routenexport zur Erstellungszeit erfolgt und basePath zur Bereitstellungszeit definiert wird und es mehr als eine Bereitstellung desselben Code-Artefakts geben k├Ânnte (Stage, Preprod, Prod, Testen von env usw.).


Haben alle Ihre Inseln die gleiche Konfiguration?
"assetPrefix": " https://static.trulia-cdn.com/javascript "

Ja, alle Inseln teilen ihr Verm├Âgen, da als n├Ąchstes Content-Hashing durchgef├╝hrt wird, ist dies nicht nur kein Problem, sondern auch sehr vorteilhaft. (Wir extrahieren erstellte Assets aus jedem Artefakt und ver├Âffentlichen sie zur Bereitstellungszeit auf CDN.)

Auf diese Weise haben wir nur "regul├Ąre HTML" -Anfragen an unsere App-Server. Deshalb werden auf trulia.com keine "_next" -Pfade angezeigt

Beispiele f├╝r die Inseln:

Unsere frische brandneue Insel - Nachbarschaftsseite - https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 (mehr davon finden Sie hier: http: //www.trulia. com / Nachbarschaften)
Diese Insel ist f├╝r alle /n/* Pfade verantwortlich.

Und eine andere Insel ist unsere Anmeldeseite - https://login.trulia.com/login - es sieht aus wie eine andere Domain, aber es ist wirklich nicht so, es sieht aus verschiedenen Gr├╝nden so aus, aber technisch gesehen ist es die gleiche Bereitstellung. :) :)
Und diese Insel verarbeitet URLs wie /login , /signup .

Lassen Sie mich wissen, wenn Sie weitere Fragen haben.

@alexindigo vielen Dank f├╝r Ihre Beispiele.
Ich habe ein paar Fragen, nachdem ich die Beispiele analysiert habe ­čśä

Sie rendern immer noch Server f├╝r jede Insel, aber Sie versuchen, so viele m├Âgliche Assets wie m├Âglich in ein gemeinsames CDN zu extrahieren, oder?

K├Ânnen Sie bitte etwas genauer beschreiben, was genau passiert, wenn https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 aufgerufen wird? Wei├č Ihr Proxy, dass /n f├╝r Nachbarschafts├╝bersicht steht und leitet sie an die richtige Insel weiter? Beeinflusst es irgendwie die Anfrage, bevor sie auf der Insel ankommt?

Verwenden Sie das integrierte Routing von next innerhalb einer Insel oder haben Sie eine benutzerdefinierte L├Âsung?
Ich wollte das Routing auf Ihrer Insel ├╝berpr├╝fen. Leider hat Neighborhood overview mehr oder weniger nur eine modale Navigation, ohne die URL zu ├Ąndern. In Login scheint es eine vollst├Ąndig benutzerdefinierte L├Âsung zu geben.

Ich hoffe, ich beantworte alle Ihre Fragen in diesem Kommentar ­čśĆ

├ťbrigens war es nicht "Nein, f├╝ge diese Funktion nicht hinzu" :) Es war eher wie - "Wahrscheinlich k├Ânnen wir diesen Ansatz ganzheitlicher betrachten" :)

Sicher, es w├Ąre gro├čartig, eine L├Âsung zu finden, bei der ich next.js ­čśĆ nicht ber├╝hren muss

Ja. Es funktioniert jedoch nur, wenn keine Verbindung zwischen den Inseln besteht. Und das klingt so, als w├Ąre dies Ihr Anwendungsfall. Gleichzeitig f├Ąllt es mir schwer zu verstehen, was sie zu Inseln macht, anstatt nur eine Reihe von eigenst├Ąndigen Anwendungen zu sein, wenn sie zu 100% unabh├Ąngig sind. :) :)

Ich habe nie geschrieben oder gesagt, dass ich nach einer "Insel" -L├Âsung suche. Ich habe mich gerade mit @timneutkens unterhalten, wo ich mein Problem beschrieben habe und Tims Antwort war im Grunde next.js unterst├╝tzt keine Basispfade. Und nachdem ich ein bisschen gegoogelt hatte, wurde mir klar, dass ich nicht der einzige bin, der danach sucht. Also dachte ich, ich k├Ânnte ein bisschen dazu beitragen. Danach hat Tim Sie angerufen, um mir ein Feedback zu geben, und ich bin sehr dankbar f├╝r Ihr Feedback.

Ich sehe nicht, wie es (einfach) gemacht werden k├Ânnte, da der Routenexport zur Erstellungszeit erfolgt und basePath zur Bereitstellungszeit definiert wird und es mehr als eine Bereitstellung desselben Code-Artefakts geben k├Ânnte (Stage, Preprod, Prod, Testen von env usw.).

Wenn Sie Routen zur Erstellungszeit exportieren und f├╝r andere Inseln verf├╝gbar machen m├Âchten, besteht der einzige einfache Weg wahrscheinlich darin, den basePath in der Konfiguration fest zu codieren. Ich verstehe was sie meinen. Auf der anderen Seite, ist das wirklich so ein Problem? Sie k├Ânnen die App weiterhin f├╝r verschiedene Dom├Ąnen und Ports bereitstellen und f├╝r jede Umgebung denselben basePath verwenden.

Guten Morgen @tomaswitek :)

Meine Erfahrung mit der "basePath" -Funktionalit├Ąt, die in ihrer Komplexit├Ąt sehr t├Ąuscht, und es ist normalerweise besser, solche Dinge zu implementieren, ohne sich mit einem bestimmten Problem darauf einzulassen.
aber aus mehreren Blickwinkeln betrachten. ├ähnlich wie Sie sich dem Deep Merging n├Ąhern w├╝rden - skizzieren Sie mehrere Anwendungsf├Ąlle und sehen Sie, wie (und ob) sie alle unter einen Dach fallen. Da es sehr ├Ąrgerlich ist, inkompatible Funktionen zwischen (sogar Haupt-) Versionen des Frameworks zu haben :)

Sie k├Ânnen die App weiterhin f├╝r verschiedene Dom├Ąnen und Ports bereitstellen und f├╝r jede Umgebung denselben basePath verwenden.

Klingt so, als w├Ąren Sie mit der L├Âsung einverstanden, bei der dieser "basePath" Teil Ihres Routing-Codes ist, was Sie am Anfang erw├Ąhnt haben - wie ein Unterordner im Verzeichnis pages (├╝brigens w├╝rde dieser Ansatz den ausgew├Ąhlten Entwicklern signalisieren basePath ziemlich gut). Das einzige, was Sie daran gehindert hat, ist, dass der interne nextjs-Pfad f├╝r Assets _next nicht konfigurierbar ist.

Und das klingt nach einem engeren Problem, das wir mit weniger langfristigen Nebenwirkungen l├Âsen k├Ânnen.

Und es k├Ânnte uns noch weiter bringen, beispielsweise wenn wir AssetPath pro Asset konfigurieren k├Ânnen (z. B. mit einer Map next.config). Dadurch k├Ânnen wir Assets zwischen den Apps gemeinsam nutzen, wodurch die Leistung verbessert wird, und andere Dinge.

Und f├╝r diese Funktion gibt es offene PR. ;) / cc @timneutkens klingt wie es Zeit ist, zu diesem Welpen zur├╝ckzukehren. :) :)

Wenn Sie dies nicht in K├╝rze hinzuf├╝gen, k├Ânnen wir dann ein Beispiel f├╝r eine expressbasierte server.js-Datei in die Readme-Datei aufnehmen, die dies tut und funktioniert? Ich habe einige ausprobiert, die in diesen Problemen herumschwirrten, sie aber nicht zum Laufen bringen konnten. Vielen Dank.

Hallo @ccarse, ich habe eine funktionierende Gabel, die wir bereits in der Produktion verwenden: https://github.com/panter/next.js/pull/2
Ich bin auch bereit, Zeit zu investieren, um eine PR f├╝r diese Funktion zu er├Âffnen.
@timneutkens @alexindigo Gibt es eine andere M├Âglichkeit, dieses Problem zu l├Âsen?
Wenn wir keine basePath -Konfiguration ben├Âtigen, k├Ânnen Sie uns bitte ein minimales Beispiel mit assetPath ?

Auch meine Firma st├Â├čt darauf.

Wir ├╝bernehmen langsam eine Legacy-App, Abschnitt f├╝r Abschnitt, und ersetzen sie durch Next.js.

Als vereinfachtes Beispiel:

| URL | App |
| --- | --- |
| example.com | Verm├Ąchtnis |
| example.com/shop | weiter |
| example.com/search | Verm├Ąchtnis |
| example.com/members | weiter |

Das hei├čt, wir m├Âchten, dass in jeder Next.js-App alles vorangestellt wird ... Seiten, Routen, Assets usw.

Es ist auch erw├Ąhnenswert, dass wir Now nicht verwenden, sodass wir das Routing von now.json nicht nutzen k├Ânnen. Wir haben unseren eigenen Load Balancer, der vor der gesamten Dom├Ąne sitzt und dann den Datenverkehr basierend auf dem Unterpfad weiterleitet.

Wir verwenden auch einen benutzerdefinierten Server (Hapi). Es w├Ąre also sch├Ân, wenn wir das, was hier erstellt wird, auch auf einem benutzerdefinierten Server nutzen k├Ânnten.

Vielleicht gibt es eine Kombination aus now.config.json -Einstellungen oder eine Verwendung von Mikro-Proxy, mit der wir dasselbe erreichen k├Ânnen, aber wir haben noch nicht die richtige Kombination gefunden.

Ich denke, wir haben das gleiche Problem mit mehreren statisch exportierten Next.js-Apps, die auf Now v2 gehostet werden.

| URL | App |
| - | - |
| example.com | weiter |
| example.com/dashboard | weiter |

Wie erwartet funktioniert die Root-App einwandfrei. Im zweiten geht es allerdings schief. Wir verpacken derzeit next/link was zusammen mit assetPrefix gr├Â├čten Teil des Problems l├Âst:

export default ({ children, href, ...rest }) => (
      <Link href={process.env.NODE_ENV === "production" ? `/dashboard${href}` : href} {...rest}>
        {children}
      </Link>
);

Dies bricht jedoch prefetch da dann versucht wird, unter der falschen URL nach .js -Dateien zu suchen:

Unsere derzeitige Problemumgehung besteht darin, prefetch zu deaktivieren, was nicht ideal ist.

Wie ist der Status dazu?

Bitte suchen Sie auch nach einem Update dazu.

@timneutkens Ich bin bereit, Zeit zu investieren, um eine PR daf├╝r zu er├Âffnen, wenn die Community interessiert ist. Wir verwenden bereits eine L├Âsung (https://github.com/panter/next.js/pull/1) in der Produktion und sind sehr zufrieden damit.

Auch daf├╝r brauchen wir eine L├Âsung

Wir werden in K├╝rze eine neue API einf├╝hren, die diesen Vorschlag ├╝berfl├╝ssig macht.

Auch davon betroffen. Das n├Ąchste Projekt muss unter einem Unterverzeichnispfad ausgef├╝hrt werden. Ich freue mich auf das offizielle Feature. Gibt es eine ETA?

API

Wie geht's? : D.

Bitte spammen Sie den Thread nicht und verwenden Sie die H-Funktion von GitHub f├╝r das Problem.

@timneutkens K├Ânnen Sie weitere Informationen bereitstellen? Welche API macht dies ├╝berfl├╝ssig? Was denkst du "bald"? Vielen Dank.

Dies h├Ąngt m├Âglicherweise nicht genau mit mehreren Zonen zusammen, kann aber helfen ...

Ich habe etwas ├ähnliches gel├Âst, indem ich einen benutzerdefinierten Server erstellt und Proxy-Middleware verwendet habe

Zum Beispiel: @Zertz
Bitte beachten Sie: Sie m├╝ssen das Link-Problem noch l├Âsen. Wiederum habe ich dieses Problem gel├Âst, indem ich eine Link-Komponente erstellt und das Pr├Ąfix ├╝ber die Konfiguration an die App weitergegeben habe. Wenn ein Pr├Ąfix vorhanden ist, verwenden Sie dieses oder nichts, ebenso f├╝r statische Bilder.

const proxy = require('http-proxy-middleware');

app.setAssetPrefix('/dashboard');

  // Express custom server
  // Proxy so it works with prefix and without...
  // So if asset prefix is set then it still works
  const server = express();
  server.use(
    proxy('/dashboard', {
      target: 'http://localhost:3000', 
      changeOrigin: true,
      pathRewrite: {
        [`^/dashboard`]: '',
      },
    }),
  );

Der Vorschlag, den ich erw├Ąhnte, ist # 7329

Der Vorschlag, den ich erw├Ąhnte, ist # 7329

@ Timneutkens
K├Ânnen Sie uns bitte n├Ąher erl├Ąutern, wie der vorgeschlagene Haken unsere Basispfadprobleme l├Âsen wird?
Und was ist mit Router-Weiterleitungen wie Router.push('/about') ? Wird dies auch durch einen Hook ersetzt?

Vielen Dank f├╝r Ihre Zeit ­čśĆ

Die Router-API w├╝rde sich ebenfalls ├Ąndern, da eine Komponente zum Verkn├╝pfen erforderlich w├Ąre. Zu diesem Zeitpunkt k├Ânnen Sie relative Pfade f├╝r die URL selbst verwenden.

Gibt es ein Update, wann wir eine L├Âsung oder zumindest eine Problemumgehung daf├╝r finden k├Ânnen?

Verwenden Sie ­čĹŹ bei der ersten Ausgabe, anstatt ein Update zu ver├Âffentlichen.

@ MMT-LD Ihre L├Âsung funktioniert f├╝r mich, aber jetzt wird die Seite bei jedem Link-Klick oder Router-Push-Ereignis neu geladen Ôś╣´ŞĆ

Ich habe die L├Âsung von
Au├čerdem konnte ich das Problem prefetch beheben, indem ich Ausgabedateien in die vorabgerufenen Pfade kopierte.
https://github.com/fand/MDMT/blob/master/scripts/copy-preload.js

... es ist ein schmutziger Trick, aber er funktioniert trotzdem

@icholasbraun

Jetzt wird die Seite bei jedem Link-Klick oder Router-Push-Ereignis neu geladen Ôś╣´ŞĆ

Ich hatte dieses Problem, wurde aber mit dem Parameter 'as' f├╝r den Link behoben, sodass der Link auf die interne Datei verweist, das 'as' jedoch relativ zum Pfad ist
z.B:
<Link href={"/${item.link}"} as={"./${item.link}"}>

@icholasbraun

Ihre L├Âsung funktioniert f├╝r mich, aber jetzt wird die Seite bei jedem Link-Klick oder Router-Push-Ereignis neu geladen Ôś╣´ŞĆ

Das habe ich gemeint. Dies ist aus dem Ged├Ąchtnis ... aber ich bin sicher, Sie k├Ânnen nicht zu dem gelangen, was Sie von unten ben├Âtigen.

// WithConfig component
import getConfig from 'next/config';

const { publicRuntimeConfig } = getConfig();

const WithConfig = ({ children }) =>
  children && children({ config: publicRuntimeConfig });

export default WithConfig;
// Extended Link component

 import React from 'react';
import PropTypes from 'prop-types';
import Link from 'next/link';
import { WithConfig } from '../WithConfig';
/* 
    <Link> component has two main props:
    href: the path inside pages directory + query string. e.g. /page/querystring?id=1
    as: the path that will be rendered in the browser URL bar. e.g. /page/querystring/1

*/

const NextLink = ({
  browserHref,
  pagesHref,
  whatever,
}) => {
  return (
    <WithConfig>
      {({ config: { pathPrefix } = {} }) => (
        <Link
          as={pathPrefix ? `${pathPrefix}${browserHref}` : browserHref}
          href={pagesHref}
          passHref
        >
          <a>{whatever}</a> // this bit is up to you - children or whatever
        </Link>
      )}
    </WithConfig>
  );
};

NextLink.propTypes = {
  browserHref: PropTypes.string.isRequired,
  pagesHref: PropTypes.string,
};

NextLink.defaultProps = {
  pagesHref: undefined,
};

export default NextLink;

Verwendung:

import NextLink from '../NextLink'

<NextLink browserHref={`/page/1`} pagesHref={`/page?querystring=1`} whatever='I'm the link' />

Viel Gl├╝ck: Smiley:

Da der useLink RFC jetzt abgelehnt wird (# 7329) und die Unterst├╝tzung von basePath uns sehr helfen w├╝rde, ist das Next.js-Projekt gl├╝cklich, PRs zu akzeptieren, die ihn implementieren? Ich bin bereit es zu tun.

Wenn man sich diese Implementierung von @tomaswitek ansieht , scheint sie in die richtige Richtung zu gehen, was den Router vor allem auf basePath . Gibt es andere nicht offensichtliche Dinge, die die Unterst├╝tzung von basePath schwierig machen w├╝rden?

Insgesamt denke ich, dass das Design klar ist, nur eine einzige Konfigurationsvariable:

module.exports = {
  basePath: '/demo'
}

Interaktionen mit assetPrefix sind hier genau definiert: https://github.com/zeit/next.js/issues/4998#issuecomment -414978297.


UPDATE : Ich habe auch dar├╝ber nachgedacht, ob es m├Âglich ist, dies zu implementieren, indem ein benutzerdefinierter Router erstellt und der Standardrouter irgendwie ausgetauscht wird, aber es scheint nicht m├Âglich zu sein, Next.js codiert seinen Router fest, siehe z. B. hier . Ich bin auch skeptisch, dass "nur" das Ersetzen des Routers ausreichen w├╝rde; Die Funktion muss wahrscheinlich von Next.js als Ganzes unterst├╝tzt werden.

Dieses Problem besteht seit 2017, gibt es eine Problemumgehung? Oder eine offizielle Antwort auf unsere basePath-Anfrage?

Nachdem Sie versucht haben, dies mit der Kombination aus assetPrefix und einer benutzerdefinierten <Link> -Komponente zum Laufen zu bringen, wie in z. B. https://github.com/zeit/next.js/issues/4998#issuecomment vorgeschlagen -464345554 oder https://github.com/zeit/next.js/issues/4998#issuecomment -521189412, ich glaube leider nicht, dass dies m├Âglich ist.

Das Definieren von assetPrefix war relativ einfach, so etwas in next.config.js :

const assetPrefix = process.env.DEPLOYMENT_BUILD ? '/subdir' : '';

module.exports = {
  assetPrefix,
  env: {
    ASSET_PREFIX: assetPrefix,
  },
}

Der n├Ąchste Schritt ist eine benutzerdefinierte Link -Komponente. Die erste Idee, die z. B. in https://github.com/zeit/next.js/issues/4998#issuecomment -464345554 gegeben wird, besteht darin, href wie folgt vorangestellt zu haben (vereinfacht):

export default ({ children, href, ...rest }) => (
  <Link href={`${process.env.ASSET_PREFIX}${href}`} {...rest}>
    {children}
  </Link>
);

Wie von anderen in diesem Thread berichtet, wird das Vorabrufen unterbrochen, da die Anforderungen pl├Âtzlich an / subdir /example.js gesendet werden - das andere "Unterverzeichnis" sollte nicht vorhanden sein. Mit unserer benutzerdefinierten Komponente Link wir href auf /subdir/example . Kein Wunder, dass Next.js ein Bundle der Seite pages/subdir/example.js anfordert.

OK, problematisches Prefetching klingt nicht nach dem Ende der Welt (obwohl die UX ziemlich h├Ąsslich ist), aber in unserer App wird es schlimmer, wenn wir das dynamische Routing von Next.js 9 verwenden. Dazu m├╝ssen wir as richtig einstellen, damit die Entwicklung der benutzerdefinierten Link -Komponente folgenderma├čen aussieht:

export default ({ children, href, as, ...rest }) => (
  <Link 
    href={`${process.env.ASSET_PREFIX}${href}`}
    as={`${process.env.ASSET_PREFIX}${as}`}
    {...rest}
  >
    {children}
  </Link>
);

Verwendung ist:

<CustomLink href='/post/[id]' as='/post/1'>...</CustomLink>

welches konvertiert wird zu:

<Link href='/subdir/post/[id]' as='/subdir/post/1'>...</Link>

und das hat bei der Bereitstellung auf Now ├╝berhaupt nicht funktioniert - der Versuch, zu https://deployment-id.now.sh/subdir/post/1 zu navigieren, f├╝hrte zu 404. Ich bin mir nicht ganz sicher, warum, vielleicht ist es auch ein Problem mit @now/next builder ( UPDATE : Es liegt an https://github.com/zeit/next.js/pull/8426#issuecomment-522801831), aber letztendlich verwirren wir den Router von Next.js, wenn wir nach /subdir/post/[id] fragen.

In diesem Thread gibt es ein weiteres Beispiel, https://github.com/zeit/next.js/issues/4998#issuecomment -521189412, das nur wie folgt vorstellt, nicht href (vereinfacht):

export default ({ children, href, as, ...rest }) => (
  <Link href={href} as={`${process.env.ASSET_PREFIX}${as}`} {...rest}>
    {children}
  </Link>
);

aber das wird diesen Fehler im Browser ausl├Âsen:

Der <Link> as ist nicht mit dem Wert von href kompatibel. Dies ist ung├╝ltig.

Dieses Problem wurde unter https://github.com/zeit/next.js/issues/7488 gemeldet

Nach all dem glaube ich nicht, dass es eine L├Âsung gibt, bis so etwas wie basePath unterst├╝tzt wird, bei dem ich gerne helfen w├╝rde.

@borekb Ich bin auch bereit zu helfen, wie ich schon ein paar Mal erw├Ąhnt habe. Alle Problemumgehungen, die ich bisher gesehen habe, l├Âsen nur einen Teil des Problems. Im Moment verwenden wir eine Abzweigung von next.js in der Produktion, die basePath implementiert.

Wir werden in K├╝rze eine neue API einf├╝hren, die diesen Vorschlag ├╝berfl├╝ssig macht.

@tim Ist es immer noch so oder wurde der neue Vorschlag f├╝r API geschlossen? https://github.com/zeit/next.js/issues/7329

├ťbrigens. morgen wird es genau ein Jahr dauern, bis ich diese Ausgabe er├Âffnet habe ­čÄë

Eine relativ wilde Idee ist es, Seiten in so etwas wie src/pages und sie dann mit dem richtigen Speicherort zu verkn├╝pfen. Zum Beispiel:

  • F├╝r die Bereitstellung auf myapp.example.com w├╝rde ich src/pages mit pages
  • F├╝r die Bereitstellung auf example.com/myapp w├╝rde ich src/pages mit pages/myapp

In Kombination mit der benutzerdefinierten Komponente <Link> und assetPrefix es funktionieren, aber ich bin nicht mutig genug, es zu versuchen ­čśä.

Irgendein Update damit?

Irgendwelche Fortschritte basePath Unterst├╝tzung von

@icholasbraun

Jetzt l├Ądt die Seite bei jedem Link-Klick oder Router-Push-Ereignis frowning_face neu

Ich hatte dieses Problem, wurde aber mit dem Parameter 'as' f├╝r den Link behoben, sodass der Link auf die interne Datei verweist, das 'as' jedoch relativ zum Pfad ist
z.B:
<Link href={"/${item.link}"} as={"./${item.link}"}>

Du hast meinen Tag gerettet! :)))

Ich mache das gleiche mit Router.push(`/route`, `${process.env.BASE_PATH}route`);

@icholasbraun

Jetzt wird die Seite bei jedem Link-Klick oder Router-Push-Ereignis neu geladen Ôś╣´ŞĆ

Ich hatte dieses Problem, wurde aber mit dem Parameter 'as' f├╝r den Link behoben, sodass der Link auf die interne Datei verweist, das 'as' jedoch relativ zum Pfad ist
z.B:
<Link href={"/${item.link}"} as={"./${item.link}"}>

Diese L├Âsung funktioniert nicht mit dem n├Ąchsten 9 dateibasierten Routing. /route/[id] , ${process.env.BASE_PATH}/route${id} l├Âst diesen Fehler aus

Dieser Kommentar erkl├Ąrt das Problem sehr gut.

Obwohl ich einige Leute gesehen habe, die dar├╝ber diskutieren, wie die L├Âsungen hier das Vorabrufen unterbrechen. F├╝r uns gibt es ein weiteres wichtigeres Thema.

Mit next9 f├╝hrt die Verwendung eines AssetPrefix in Ihrem href dass next _ immer eine Serverroute ausf├╝hrt. Ich habe in dieser Ausgabe ein Reproduktions-Repo erstellt, das die Ereignisse demonstriert.

Dies unterbricht im Wesentlichen unseren Apollo Client-Cache, da er auf jeder Route neu erstellt wird.

Ich denke, die Implementierung vergleicht die zugrunde liegende Seite href ohne ein AssetPrefix mit den n├Ąchsten Routen href (einschlie├člich eines AssetPrefix) - was zu einer tiefen Route f├╝hrt.

Beispiel: Wenn Sie sich auf href /prefix/page (die zugrunde liegende Seite ist nur /page ) und Ihre n├Ąchste Route href /prefix/page/[id] (denn ohne das Pr├Ąfix wird es 404) Dies ist eine v├Âllig andere Route und eine flache Route ist nicht m├Âglich.

Aktuelle Problemumgehungen mit Express-Routen untersuchen

Bei Verwendung Komponente mit den href Requisiten, die basePath ist, funktioniert der Prefetch nicht.
PLZ unterst├╝tzt basePath und Prefetch, es wird gro├čartig

Ich k├Ânnte das wirklich gebrauchen. Ich f├╝hre mehrere Apps von einer einzigen Serverquelle aus und habe jede in ihre eigenen web/appX/{next project files} . Es w├Ąre gro├čartig, mehr Kontrolle ├╝ber den basePath zu haben. Ich habe vorerst eine Problemumgehung gefunden, aber sie ist nicht sehr h├╝bsch.

F├╝r den statischen Export ist au├čerdem basePath ­čśŐ erforderlich

scheint Arbeitserfolg ­čĹĆ

{
  experimental:{
    basePath: '/some/dir',
  }
}

Dies ist leider eine ziemlich schlechte Einschr├Ąnkung f├╝r uns :(

Wir haben alle Apps hinter einem Reverse-Proxy, daher m├╝ssen Pfade vorangestellt werden (im folgenden Beispiel ist dies das Pr├Ąfix /auction-results ).

Wir verwenden bereits das Pr├Ąfix assetPrefix - und dies erm├Âglicht es Apps, f├╝r serverseitige Anforderungen in Ordnung zu sein.
Beispiel: mydomain.com/auction-results/ funktioniert gut, wenn Sie ein Express-Routing wie das folgende verwenden:

router.get(`/${appPrefix}/`, (req, res) => {
  nextApp.render(req, res, '/national', req.params);
});

Aber wenn wir versuchen, eine clientseitige Navigation ├╝ber next/link durchzuf├╝hren, z.

Dabei ist /auction-results das Anwendungspr├Ąfix und /national die Seite in ~pages/national

<Link href="/national" as="/auction-results/">
  <a>Goto National Page</a>
</Link>

Dies macht nichts (Geisterklick)

Es ist nicht ideal, Links zum Aktualisieren ganzer Seiten zu haben.

Wenn es eine M├Âglichkeit gibt, wie ich dabei helfen kann, w├╝rde ich gerne

Jedes Update dazu ... letztes Jahr um diese Zeit bin ich auf dieses Problem gesto├čen. Jetzt, ein Jahr sp├Ąter, arbeite ich an einer neuen App und muss die gleichen Problemumgehungen wie im letzten Jahr durchf├╝hren ... irgendwie alarmierend f├╝r eine "produktionsbereite" Reaktion fw. Basispfade sollten ein Vanille-Merkmal sein.

Jedes Update dazu ... letztes Jahr um diese Zeit bin ich auf dieses Problem gesto├čen. Jetzt, ein Jahr sp├Ąter, arbeite ich an einer neuen App und muss die gleichen Problemumgehungen wie im letzten Jahr durchf├╝hren ... irgendwie alarmierend f├╝r eine "produktionsbereite" Reaktion fw. Basispfade sollten ein Vanille-Merkmal sein.

Ich bin mir nicht sicher, was Sie erwarten, wenn Sie dies ver├Âffentlichen.

Next.js wird von meinem Team (5 Personen) in Vollzeit bearbeitet, und wir arbeiten gleichzeitig an vielen Funktionen. Im vergangenen Jahr haben wir daran gearbeitet:

Effektiv machen Next.js-Anwendungen (neu und vorhanden) erheblich kleiner, schneller und skalierbarer.

Wenn Sie Ihre "Gegenstimme" f├╝r eine Funktion ├Ąu├čern m├Âchten, k├Ânnen Sie. Verwenden Sie die Funktion ­čĹŹ f├╝r den ersten Thread.

Ich bin definitiv der Meinung, dass basePath eine integrierte Funktion sein sollte. Es ist bereits auf der Roadmap und ich habe sogar eine erste PR geschrieben, die Sie durch Zur├╝cklesen des Threads h├Ątten sehen k├Ânnen.

Hier ist die PR: https://github.com/zeit/next.js/pull/9872

Wenden Sie sich an [email protected], wenn Sie einen finanziellen Beitrag zur Umsetzung dieser Funktion leisten m├Âchten.

Wie ist der Status dazu? wir sind wirklich darauf angewiesen: /

Die Unterst├╝tzung von

vgl. https://github.com/zeit/next.js/pull/9872

Die Unterst├╝tzung von

vgl. # 9872

@martpie habe ich schon gesehen, aber f├╝r. Mein Fall basePath ist nicht nur einer, es kann sich um mehrere basePath handeln, da wir unsere App ├╝ber verschiedene "URLs" bereitstellen und das Einrichten von basePath w├Ąhrend der Erstellungszeit keine Option ist (obwohl dies der Fall ist) ein Array von Pfaden anstelle einer einzelnen Zeichenfolge zu unterst├╝tzen)

@ Timneutkens Danke f├╝r das Update. W├╝rdest du so nett sein, ein weiteres Update zu geben? Dies ist f├╝r uns ein Schl├╝sselmerkmal und wir m├╝ssen wissen ...

  1. Wird dies nur f├╝r Unternehmen gelten (Ihr Hinweis auf den Kontakt mit Unternehmensverk├Ąufen hat einige Irritationen verursacht)?

  2. Es scheint auf der Roadmap zu stehen, laut PR wird es nicht wieder entfernt; K├Ânnen Sie einen Hinweis geben, ob es sicher ist, diese Funktion jetzt zu nutzen, ohne in den n├Ąchsten Monaten ├ťberraschungen zu erleben, wie eine verkr├╝ppelte Open-Source-Version und eine andere mit voller Unterst├╝tzung, nachdem wir Wochen mit einigen zuf├Ąlligen Verk├Ąufern ├╝ber willk├╝rliche Preise verhandelt haben?

Ich verstehe, dass ihr an vielen Funktionen arbeitet und jeder seine Priorit├Ąten hat, aber auch kleinere Setups m├╝ssen als N├Ąchstes einen Proxy erstellen, mehrere Instanzen ausf├╝hren und ihm einen dedizierten basePath pro Service geben. Bevor wir nun beginnen, mehrere Dienste auf Next aufzubauen, m├╝ssen wir wissen, wie wahrscheinlich und bald diese Funktion als vollst├Ąndige Open Source verf├╝gbar ist. Andernfalls w├Ąre es einfach zu riskant, weitere Zeit in Next zu investieren.

Vielen Dank f├╝r Ihr Verst├Ąndnis und freuen uns auf Ihr Feedback.

FWIW, ich habe es jetzt zum Laufen gebracht und f├╝r andere, die vorbeifahren:

Tragen Sie dies in Ihr next.config.js :

module.exports = {
  experimental: {
    basePath: '/custom',
  },
}

Dann musste ich den Server neu starten und meine Webserver-Middleware richtig einrichten:

Ich fange alle Anfragen ├╝ber einen benutzerdefinierten Pfad ab, z. app.use('/custom', (req, res...) => { ... und dann (was wichtig war) muss ich einen Proxy f├╝r die URL des Systems erstellen, auf dem Next ausgef├╝hrt wird (also die interne Adresse Ihrer Container-Orchestrierung und erneut den entsprechenden Pfad, wenn Sie http-proxy => zB ... target: 'http://next:3000/custom ), also nicht nur der Host ohne den benutzerdefinierten Pfad. Wenn Sie http-proxy-middleware verwenden, ben├Âtigen Sie dies nicht.

Es f├╝hlt sich ganz ok an, ich hoffe, dass diese Funktion keine EE-Lizenz ben├Âtigt. Wenn Ihr Team Hilfe ben├Âtigt, um diese Funktion ausgereift zu machen, lassen Sie es uns bitte wissen, vielleicht k├Ânnen wir Ihnen helfen!

Bearbeiten: Habe es gerade auch im Next-Produktionsmodus versucht und es scheint auch zu funktionieren.

@ Timneutkens Danke f├╝r das Update. W├╝rdest du so nett sein, ein weiteres Update zu geben? Dies ist f├╝r uns ein Schl├╝sselmerkmal und wir m├╝ssen wissen ...

  1. Wird dies nur f├╝r Unternehmen gelten (Ihr Hinweis auf den Kontakt mit Unternehmensverk├Ąufen hat einige Irritationen verursacht)?
  2. Es scheint auf der Roadmap zu stehen, laut PR wird es nicht wieder entfernt; K├Ânnen Sie einen Hinweis geben, ob es sicher ist, diese Funktion jetzt zu nutzen, ohne in den n├Ąchsten Monaten ├ťberraschungen zu erleben, wie eine verkr├╝ppelte Open-Source-Version und eine andere mit voller Unterst├╝tzung, nachdem wir Wochen mit einigen zuf├Ąlligen Verk├Ąufern ├╝ber willk├╝rliche Preise verhandelt haben?

Ich verstehe, dass ihr an vielen Funktionen arbeitet und jeder seine Priorit├Ąten hat, aber auch kleinere Setups m├╝ssen als N├Ąchstes einen Proxy erstellen, mehrere Instanzen ausf├╝hren und ihm einen dedizierten basePath pro Service geben. Bevor wir nun beginnen, mehrere Dienste auf Next aufzubauen, m├╝ssen wir wissen, wie wahrscheinlich und bald diese Funktion als vollst├Ąndige Open Source verf├╝gbar ist. Andernfalls w├Ąre es einfach zu riskant, weitere Zeit in Next zu investieren.

Vielen Dank f├╝r Ihr Verst├Ąndnis und freuen uns auf Ihr Feedback.

@ pe-s Ich denke du verstehst meinen Beitrag falsch.

Derzeit gibt es keine "Enterprise Next.js-Version". Ich bezog mich auf die zahlreichen Gelegenheiten, in denen externe Unternehmen f├╝r die Beratung aufbrachten, um Funktionen wie diese in k├╝rzerer Zeit zu entwickeln. ZB wurde die Zonenunterst├╝tzung in Zusammenarbeit mit Trulia aufgebaut.

Diese Funktion wird noch bearbeitet und steht auf der Roadmap. Alle Funktionen, an denen gearbeitet wird, sind Open Source, wie gesagt, es gibt keine Unternehmensversion von Next.js. Wir haben mehrere Priorit├Ąten von High-Impact - Arbeit auf der Roadmap allerdings damit , warum ich zu kontaktieren bezeichnen [email protected] wenn Sie diese Funktion so schnell wie m├Âglich ben├Âtigen / Enterprise - Support zu diskutieren f├╝r Next.js.

@ Timneutkens TX f├╝r Ihre schnelle Antwort und gro├čartig! Dann k├Ânnen wir alles rein :)
Mach weiter so!

Die Basepath-Unterst├╝tzung ist derzeit auf [email protected] verf├╝gbar, sie ist nicht mehr experimentell. Es wird bald auf dem stabilen Kanal sein.

Ich bin ziemlich sp├Ąt dran, aber haben Sie dar├╝ber nachgedacht, tats├Ąchlich HTML <base> anstatt dies manuell zu handhaben?

Die Basepath-Unterst├╝tzung ist derzeit auf [email protected] verf├╝gbar, sie ist nicht mehr experimentell. Es wird bald auf dem stabilen Kanal sein.

@ Timneutkens , danke f├╝r diesen Zusatz. Wissen Sie, wann der nicht experimentelle basePath-Support offiziell ver├Âffentlicht wird?

Wenn ich den basePath einstelle, werden die Assets (im ├Âffentlichen Ordner) erwartungsgem├Ą├č an die entsprechende URL geliefert. Wenn ich sie jedoch in meinem Code referenziere, muss ich den Basispfad manuell zum src hinzuf├╝gen, da sie sonst weiterhin vom normalen Pfad referenziert werden. Ist dies die erwartete Verwendung von basePath? Ich habe auch versucht, AssetPrefix zu verwenden, aber es hatte keine Auswirkungen auf meinen Code, die ich erkennen konnte.

Beispiel :

  1. mit next v9.4.5-canary.24
  2. basePath /alerts in next.config.js auf
const basePath = '/alerts';
module.exports = {
  basePath: basePath,
  env: {
    BASE_PATH: basePath,
  },
};
  1. Verm├Âgenswert befindet sich in public/images/example.png
  2. Beispiel f├╝r die Verwendung eines Assets in einer Reaktionskomponente:
const ExampleImage = () => (
  <img src={`${process.env.BASE_PATH}/images/example.png`} />
);

In meinen Tests werden die URLs der Assets nicht aktualisiert.

Ich habe den neuesten Kanarienvogel installiert:
npm install [email protected]

next.config.js

const isProd = process.env.NODE_ENV === 'production';

module.exports = {
  basePath: isProd ? '/example' : ''
}

Alle Seiten und Links werden korrekt geladen:
http: // localhost : 3000 / example / posts / Pre-Rendering
http: // localhost : 3000 / example / posts / ssg-ssr
http: // localhost : 3000 / example / posts / Pre-Rendering

Bilder, Favoriten usw. werden jedoch nicht zugeordnet:
http: // localhost : 3000 / favicon.ico 404
http: // localhost : 3000 / images / profile.jpg 404

Hat jemand das getestet? Ich habe auch versucht, AssetPrefix zu verwenden, aber das hat auch nicht funktioniert.

Au├čerdem bin ich verwirrt, warum nicht die eingebaute Browser-Funktionalit├Ąt daf├╝r verwenden?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

Vielen Dank, dass Sie sich auch mit @kmturley befasst haben . Ich bin froh zu wissen, dass es nicht nur ich bin.
@ Timneutkens , sollten wir dieses Problem erneut ├Âffnen / ein neues Problem f├╝r diesen Fehler erstellen?

Sie m├╝ssen Bilder manuell voranstellen. Sie k├Ânnen den basePath mit abrufen

const {basePath} = useRouter()

https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

Next.js verwendet Ihr Pr├Ąfix automatisch in den geladenen Skripten, dies hat jedoch keinerlei Auswirkungen auf den ├Âffentlichen Ordner.

Jetzt stelle ich fest, dass es mehrere M├Âglichkeiten gibt, auf Dateien in / public zu verlinken. zB <img/> <link/> ...
M├╝ssen wir deshalb den basePath f├╝r jeden manuell angeben?

Wenn eine Komponente wie die folgende verf├╝gbar w├Ąre, w├╝rde dies meiner Meinung nach Zeit sparen und die Verwirrung vieler Menschen verringern.

<WithinBasePath>
  {/* automatically fixes the path with basePath */}
  <img src="/logo.png" />
</WithinBasePath>

Ich denke wirklich nicht, dass dies angemessen ist, aber das habe ich gemeint.

// src/components/WithinBasePath/index.tsx

import React from "react"
import path from "path"
import { useRouter } from "next/router"
interface Props {}

const WithinBasePath: React.FC<Props> = (props) => {
  const { basePath } = useRouter()
  const children = [props.children].flatMap((c) => c) as React.ReactElement[]
  return (
    <>
      {children.map((child, key) => {
        let newChild = null

        switch (child.type) {
          case "img":
            newChild = React.createElement(child.type, {
              ...child.props,
              src: path.join(basePath, child.props.src),
              key,
            })
            break
          case "link":
            newChild = React.createElement(child.type, {
              ...child.props,
              href: path.join(basePath, child.props.href),
              key,
            })
            break
          default:
            newChild = React.createElement(child.type, {
              ...child.props,
              key,
            })
        }
        return newChild
      })}
    </>
  )
}
export default WithinBasePath

// pages/test.tsx

import React from "react"
import WithinBasePath from "@src/components/WithinBasePath"
interface Props {}

const test: React.FC<Props> = (props) => {
  return (
    <WithinBasePath>
      <img src="/123.jpg" />
      <link href="/abc.jpg" />
      <div>other element</div>
    </WithinBasePath>
  )
}
export default test

Verwenden Sie f├╝r diejenigen, die versuchen, const {basePath} = useRouter() , einen Hook, um mit Klassen und Komponenten zu arbeiten und den folgenden Fehler zu erhalten:

Ung├╝ltige Hook-Call-Warnung

https://reactjs.org/warnings/invalid-hook-call-warning.html

Sie k├Ânnen es zum Laufen bringen mit:

import { withRouter, Router } from 'next/router'

class Example extends Component<{router: Router}, {router: Router}> {
  constructor(props) {
    super(props)
    this.state = {
      router: props.router
    }
  }
  render() {
    return (
      <Layout home>
        <Head><title>Example title</title></Head>
        <img src={`${this.state.router.basePath}/images/creators.jpg`} />
      </Layout>
    )
  }
}
export default withRouter(Example)

Wenn Sie basePath mit Markdown verwenden m├Âchten, m├╝ssen Sie anscheinend in der Zeichenfolge suchen und ersetzen:

const content = this.state.doc.content.replace('/docs', `${this.state.router.basePath}/docs`);
return (
<Layout>
  <Container docs={this.state.allDocs}>
    <h1>{this.state.doc.title}</h1>
    <div
      className={markdownStyles['markdown']}
      dangerouslySetInnerHTML={{ __html: content }}
    />
  </Container>
</Layout>
)

Sie m├╝ssen Bilder manuell voranstellen. Sie k├Ânnen den basePath mit abrufen

const {basePath} = useRouter()

Diese L├Âsung ber├╝cksichtigt jedoch keine in eine CSS- oder SCSS-Datei importierten Bilder. Haben Sie eine L├Âsung zum Festlegen des Basispfads beim Importieren eines Assets aus einer CSS- oder SCSS-Datei?
Bei dieser L├Âsung m├╝ssen wir sicherstellen, dass alle Bilder entweder ├╝ber ein IMG-Tag, ein Inline-Styling oder ├╝ber das Style-Tag importiert werden. Es ist nicht ideal, da es Ihre Stile aufteilt, um sie an mehreren Stellen zu implementieren.

@peetjvv Hier ist eine suboptimale L├Âsung f├╝r die Verwendung von Assets mit vorangestellten basePaths in CSS. Erstellen, importieren und f├╝gen Sie eine <CSSVariables> -Komponente in _app.tsx , die ein globales inline <style> -Element mit CSS-Variablen einf├╝gt, das Sie dann in allen Ihren Stylesheets verwenden k├Ânnen.

ZB bei der Er├Âffnung von <body> Variablen erstellen und injizieren:

<style>
:root {
      --asset-url: url("${basePath}/img/asset.png");
}
</style>

Um diesen basePath zu erhalten, verwende ich den @ kmturley -Ansatz mit withRouter .
So k├Ânnte diese Komponente aussehen:

import { withRouter, Router } from "next/router";
import { Component } from "react";

export interface IProps {
  router: Router;
}

class CSSVariables extends Component<IProps> {
  render() {
    const basePath = this.props.router.basePath;
    const prefixedPath = (path) => `${basePath}${path}`;
    const cssString = (value) => `\"${value}\"`;
    const cssURL = (value) => `url(${value})`;
    const cssVariable = (key, value) => `--${key}: ${value};`;
    const cssVariables = (variables) => Object.entries(variables)
      .map((entry) => cssVariable(entry[0], entry[1]))
      .join("\n");
    const cssRootVariables = (variables) => `:root {
      ${cssVariables(variables)}
    }`;

    const variables = {
      "asset-url": cssURL(
        cssString(prefixedPath("/img/asset.png"))
      ),
    };

    return (
      <style
        dangerouslySetInnerHTML={{
          __html: cssRootVariables(variables),
        }}
      />
    );
  }
}

export default withRouter(CSSVariables);
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

formula349 picture formula349  ┬Ě  3Kommentare

havefive picture havefive  ┬Ě  3Kommentare

renatorib picture renatorib  ┬Ě  3Kommentare

sospedra picture sospedra  ┬Ě  3Kommentare

DvirSh picture DvirSh  ┬Ě  3Kommentare