@Knaackee Hast du die Möglichkeit ausprobiert? Ich frage mich auch, ob jemand es geschafft hat, mit irgendeiner Version von RR zu arbeiten?

Next hat seinen eigenen Router, warum RR verwenden?

@sergiodxa Wiegeoptionen , wenn ich meine vorhandene App auf Weiter portiere. Ich habe eine statische, verschachtelte Routenkonfiguration, die funktioniert und sich fragt, was ich weiterhin verwenden kann und was nicht.

@oyeanuj 🤔 Sie können schrittweise zu Next

Aus den Beispielen geht hervor, dass next eine einzelne Routentabelle wie RRv2-3 hat und keine "verschachtelten Routen" wie RRv4 unterstützt. Das sind nett.

Ich würde versuchen, RR zu verwenden, oder gibt es eine große Einschränkung, von der ich nichts weiß?

@igl Hast du eine Lösung dafür gefunden?

Das neue React-Router 4-Paradigma verschachtelter Routen verändert das Spiel und ist in unserem aktuellen Projekt ein Muss. Ich frage mich, ob es jemandem gelungen ist, rr4 dazu zu bringen, mit next.js zu arbeiten.

MemoryRouter funktioniert, wenn nicht wie beabsichtigt ...
Andernfalls können dynamische Komponenten nur clientseitig sein, wobei HashRouter funktioniert ...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

Ich verfolge auch den behandle das clientseitige Routing mit react-router und den gesamten vom Server gerenderten Inhalt mit next Router.

@malixsys @pegiadise Kannst du bitte einige Details darüber geben, wie der nächste Router und der React-Router zusammen verwendet werden?

Sie können ein Flag in componentDidMount und das <Router /> bedingt rendern, wenn das Flag wahr ist. ( componentDidMount läuft nicht auf dem Server 😉)

Tatsächlich integrieren wir React Router bald in Next.js :)
- https://twitter.com/rauchg/status/948318111828099072

Passiert das noch? Ich kann die Versionshinweise für V6 Canary sehen und es wird nicht erwähnt.

Schließlich. Es ist definitiv in unseren Gedanken. Wir haben momentan andere Prioritäten (Layoutkomponente, zuverlässige Entwicklung und einige andere seit langem offene Fragen).

Das ist eine Schande, es mag für das Team eine niedrige Priorität haben, aber es ist im Grunde das einzige, was Leute wie mich davon abhält, es zu benutzen. Ich habe Ihr Tutorial gelesen, bis ich zu dem Punkt gekommen bin, an dem es heißt, dass Routen zweimal eingerichtet und dann aufgegeben werden müssen.

@timneutkens Das Hinzufügen der

Das ist eine Schande, es mag für das Team eine niedrige Priorität haben, aber es ist im Grunde das einzige, was Leute wie mich davon abhält, es zu benutzen.

Gleich.

Können wir dieses Problem zumindest erneut öffnen, damit es nachverfolgt werden kann?

Ich werde dies wieder eröffnen, aber beachten Sie, dass dies ein Open-Source-Projekt ist und wir für zeit.co derzeit kein starkes Argument dafür haben, da wir Next.js für alles verwenden.

Aus diesem Grund habe ich gesagt, dass dies Teil der längerfristigen Ziele ist und nicht sofort umgesetzt werden kann, aber wir arbeiten darauf hin.

Die Funktionen, die ich in Next 6 eingeführt habe, wirken sich tatsächlich auf die Unterstützung von React Router aus.

Wir hatten andere Prioritäten für Next 6, die die Zuverlässigkeit und Skalierbarkeit von Next.js enorm verbessern, z. B. 100-mal schnellere Seitenauflösung, App-Komponente, damit der nächste Export in der Entwicklung funktioniert, Babel 7 usw.

Ich hoffe, dies geht auf meinen früheren Kommentar ein.

Die TLDR lautet also:

• Wir werden es tun, aber nicht sofort
• Next 6 hat viele Verbesserungen an verschiedenen Teilen von Next.js

Um den Kommentar von @timneutkens weiter zu erweitern: Wir wollen definitiv RR, aber wir haben keine dringenden Einschränkungen im aktuellen Router, die es zu einer Priorität machen. Alle denkbaren Routing-Anwendungsfälle wurden mit der aktuellen Next.js-API erfolgreich implementiert

Es gibt zwei Gründe, aus denen wir die Unterstützung von

• Vereinfachen Sie unsere eigene Next.js-Codebasis, müssen Sie keinen eigenen Router warten, machen Sie die Dinge kleiner und modularer
• Vereinfachen Sie den Migrationspfad großer Anwendungen, die bereits RR verwenden

Daher stimme ich zu, dass wir dieses Thema offen halten sollten!

Als Kontrapunkt bedeutet das Fehlen eines React-Routers, dass next gut mit Relay-Modern funktioniert und einer der Gründe war, warum wir von unserer alten React-Router-App auf next umgestiegen sind.

@merry, ob ich letztes Jahr an einer RRv4-App mit Relay-Modern gearbeitet habe. Möchten Sie genauer sein?
Ich erinnere mich auch nicht daran, dass wir ernsthafte Probleme hatten.

@igl Dies entspricht der Dokumentation des Relays: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

Das Problem ist, dass der Komponentenansatz von RRv4 während des Vorkompilierungsschritts keinen Determinismus zulässt, was zu Anforderungswasserfällen im Client führen kann.

@rauchg Aus Interesse verstehe ich den Router von Next so, dass er das Konzept des verschachtelten Routings nicht unterstützt, sodass Sie beim Navigieren innerhalb einer Seite das äußere Markup

@dbbk Überprüfen Sie unsere Nextgram-Beispiel-App (https://github.com/now-examples/nextgram). Genau das macht sie

In den nächsten 5 erreichen wir ein "äußeres Markup", indem wir Layoutkomponenten der obersten Ebene haben, die alle unsere Seiten erweitern: Das Basislayout verfügt über ein Top-Navi, dann einige Unterlayouts, die die Basis für Listen / Details / usw. erweitern, und dann Unsere Seitenkomponenten erweitern diese Unterlayouts um ihren eigenen spezifischen Inhalt. In den nächsten 6 könnten Sie auch ein grundlegendes "äußeres Markup" mit _app.js glaube ich.

Kann die nächste Version konfiguriert werden, um eine Routing-Lösung auszuwählen, die nicht React Router ist?

Hallo, ich brauche nur einen Reaktionsrouter, um Requisiten an Seiten zu übergeben (mit <Route render ={} /> anstelle von <Route component ={} /> ). Kann ich das mit Next machen?

Siehe https://github.com/zachrbrown/next-react-router. Es gibt nur wenige Dokumente, aber einige kurze Erklärungen unter https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.js.

Aus den Beispielen geht hervor, dass next eine einzelne Routentabelle wie RRv2-3 hat und keine "verschachtelten Routen" wie RRv4 unterstützt. Das sind nett.

Hallo,

Bedeutet dies, dass ich eine einzelne Seite für eine einzelne Route erstellen muss?

Angenommen, ich habe 2 Routen sign up , log in . Ich hätte 1 Seite, die das gleiche Layout hat, der einzige Unterschied ist der Bereich der Formulare. Das heißt, ich muss nur 1 Datei im Ordner pages erstellen. Aber bei den nächsten Routen muss ich 2 Dateien im Ordner pages erstellen. Ist es?

Wenn dies der Fall ist, wird das Layout bei jeder Navigation erneut bereitgestellt, nicht nur beim Formularbereich, oder?

https://github.com/zeit/next.js/issues/75

@ 7c78 Eine Sache, die Sie tun können, ist, _app.js für ein dauerhaftes Seitenlayout für alle Seiten zu nutzen. Die andere Aufgabe besteht darin, gemeinsam genutzte Layoutkomponenten zu erstellen, die Sie auf verschiedenen Seiten wiederverwenden können, um das zu erreichen, wonach Sie suchen:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

Darüber hinaus können Sie das tun, was wir kürzlich getan haben, und Basislayoutkomponenten definieren, die alle Ihre Seitenkomponenten erweitern:

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

Und dann erweitern Sie einfach BaseAuth auf Ihren Anmelde- und Anmeldeseiten und definieren jeweils formContent und formSubmit (dies sind Spielzeugbeispiele, da ich Ihre genauen Anforderungen nicht kenne).

@merrywhether
Ich verwende derzeit Ihren Ansatz und die nächsten Beispiele verwenden ihn auch.

Mein Anliegen ist jedoch, dass ich separate Seiten für separate Formulare erstellen muss. Das heißt, das Layout wird wiederverwendet, aber nicht die Seite. Und das Layout wird bei jeder Navigation neu montiert.

Mit RRv4 haben wir eine einzelne Seite und Formulare werden basierend auf Routen gerendert / erneut bereitgestellt (nicht die gesamte Seite). Routen sind nur Komponenten.

Vielen Dank für die schnelle Antwort!

@ 7c78 Das gilt auch für das erneute Bereitstellen, obwohl ich denke, dass die DOM-Knoten wiederverwendet werden, wenn das vDOM in denselben Status aufgelöst wird.

Es ist nicht etwas, mit dem wir uns sehr beschäftigt haben, weil wir auch keinen React-Router mit Relay-Modern verwenden können, also mussten wir dieses Muster trotzdem verwenden.

@merrywhether Ich bin mir bei vDOM nicht sicher, da der Server für jede Route ein neues Dokument / HTML zurückgibt. Entschuldigung, ignorieren Sie diese Annahme, ich bin nur ein Neuling.

Ich bin damit einverstanden, dass wir dieses Muster trotzdem verwenden müssen. Vielen Dank!

Sie können RR mit next.js verwenden, indem Sie Ihre gesamte App in den Seiten / index.js haben, aber Sie verlieren einige der Extras von next wie die sofort einsatzbereite Code-Aufteilung und müssen diese selbst einrichten.

Ich würde es lieben, wenn Reach Router in Betracht gezogen würde. Es ist dem React-Router sehr ähnlich und bringt einige wichtige Vorteile:

• Es löst einige wichtige Probleme im Zusammenhang mit der Linkgenerierung und dem Fokusmanagement (https://reach.tech/router/accessibility).
• Es wiegt weniger (zum Zeitpunkt des Schreibens)
  
  
  
  • @ range / Link )
  
  
  • [email protected] : 44.1Kb / 10.4kB ( Link )
  
  

Reach Router ist auch großartig 🥇

Dynamische Routen im RR-Stil sind eine nette API, aber statisches (und statisch analysierbares) Routing bringt auch viele Vorteile. Keiner der beiden Ansätze ist ein Slam-Dunk-Gewinner.

@sorokinvj Dies wird (derzeit) nur über ein Plugin unterstützt. https://github.com/fridays/next-routes

statische Links sind so einfach, dass sie nicht einmal Parameter in Links unterstützen ...

Ich verwende vorerst ein Drittanbieter-Paket für die nächsten Routen https://github.com/fridays/next-routes , um es zu umgehen

von meinem Iphone gesendet

Am 24. Oktober 2018, um 23:01 Uhr, schrieb Andy Ingram [email protected] :

Dynamische Routen im RR-Stil sind eine nette API, aber statisches (und statisch analysierbares) Routing bringt auch viele Vorteile. Keiner der beiden Ansätze ist ein Slam-Dunk-Gewinner.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Derzeit verwenden wir auch next-routes , aber ich glaube, das nächste Team arbeitet daran, dem Dateisystem-Routing Pfadparameter über Regex-Dateinamen hinzuzufügen (inspiriert von Sapper).

@merrywhether Ich verwende auch next-routes , würde es aber vorziehen, wenn dies Teil des Next.js-Kerns ist.

Du hast erwähnt

Ich glaube, das nächste Team arbeitet daran, Pfadparameter hinzuzufügen ...

Ich bin neugierig, haben Sie eine Referenz dafür? Vielleicht ein offenes Problem für Routenparameter? Ich kann keine finden ... Vielleicht löst das Plugin die Notwendigkeit und das wird die empfohlene Lösung für die Zukunft sein.

@curran Die Quelle war ein Tweet von einem der Entwickler von sapper.js, der besagte, dass next sich von sapper.js inspirieren ließ und das Regex-Dateinamen-Routing in einer zukünftigen Version implementierte. Da Twitter das ist, was es ist, konnte ich den ursprünglichen Tweet für mein ganzes Leben nicht finden.

Dieses Problem wurde am 5. April 2017 angesprochen und ist jetzt der 27. Februar 2019. Fast 2 Jahre und keine Lösung
Vielleicht ist es an der Zeit, den halbherzigen eingebauten Router durch etwas Gutes zu ersetzen?

Autsch. Das ist ziemlich beleidigend für NextJS-Entwickler, die viele Stunden in die Routing-Lösung gesteckt haben.

Ich habe ReactRouter zuerst vermisst. Jetzt erinnere ich mich nicht einmal daran, dass NextJS einen anderen Router hat, bis mich jemand daran erinnert. Eine ausführliche Link API ist beispielsweise trivial, um sie mit Proxys zu versehen (abhängig von Ihrer Daten- / API-Architektur). Teilen dieses streng geheimen: 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}

<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

Ich denke, wir sollten alle weniger Zeit damit verbringen, uns über sekundäre Dinge zu beschweren 😉

@ ivan-kleshnin Schön, dass ich einen ähnlichen Wrapper hinzugefügt habe

Wie im vorherigen Kommentar möchte ich auf https://www.contributor-covenant.org/version/1/4/code-of-conduct verweisen

Ich habe diesen Kommentar versteckt.

Ich habe kein Problem mit next/router für die meisten Anwendungsfälle.
Aber es sollte ein bisschen besser werden als der universal routing Teil.
Im Falle einer Now 2-Bereitstellung würde ich gerne einfach now.json und es zum Weiterleiten in meiner Anwendung verwenden.

Wenn Sie RR4 in nextJs Projekt implementieren möchten, müssen Sie zwei Dinge tun:

1. Verhindern Sie NextJS SSR. Mit next/dynamic Sie dies tun.
2. Wenn Sie HashRouter anstelle von BrowserRouter -> Wenn der Benutzer die Seite neu lädt, kann der Browser die vorherige Seite laden (nicht die Seite 404).

Wenn Sie RR4 in nextJs Projekt implementieren möchten, müssen Sie zwei Dinge tun:

1. Verhindern Sie NextJS SSR. Mit next/dynamic Sie dies tun.
2. Wenn Sie HashRouter anstelle von BrowserRouter -> Wenn der Benutzer die Seite neu lädt, kann der Browser die vorherige Seite laden (nicht die Seite 404).

Danke für diese Antwort, hat mir sehr geholfen.

@ Reach / Router und React-Router 5 verschmelzen: https://reacttraining.com/blog/reach-react-router-future/

Wie wirkt sich das auf next.js aus?

@ alp82 Da Next.js immer noch nicht React Router oder Reach Router verwendet, hat dies keinerlei Auswirkungen auf Next.js.

Ich benötige Switch-Routen-Funktionen in nextjs, um mehrere Seitenkomponenten in Indexseiten zu rendern.
Wie kann ich das in nextjs implementieren?

Wenn Sie RR4 in nextJs Projekt implementieren möchten, müssen Sie zwei Dinge tun:

1. Verhindern Sie NextJS SSR. Mit next/dynamic Sie dies tun.
2. Wenn Sie HashRouter anstelle von BrowserRouter -> Wenn der Benutzer die Seite neu lädt, kann der Browser die vorherige Seite laden (nicht die Seite 404).

Wenn Sie Ihre vorherige Seite erneut rendern möchten, ohne einen 404-Fehler auszulösen, verwenden Sie einfach diese get-Route in Ihrer Express-Server-Datei.

server.get ('Ihre Parameter', (req, res) => {
const actualPage = '/ your_page'
const queryParams = {id: req.params.id}
app.render (req, res, actualPage, queryParams)
})

Ich habe einen Ansatz zur Verwendung von next.js mit react-router dokumentiert, next.js anstelle des nativen dateisystembasierten Routings eine einzelne Einstiegspunktdatei bereitgestellt und native SSR- Funktionen vollständig

Ich freue mich über Feedback und verbessere meine Arbeit.

Die Dokumentation ist verfügbar als:

• GitHub-Repository
• dev.to posten

Prost!

Ich würde dringend davon abraten, auf diese Weise einen React-Router einzuschließen, da Sie am Ende einen einzigen Einstiegspunkt haben. Dies bedeutet (enorm) langsamere Entwicklungs-Builds, eine höhere Wahrscheinlichkeit, zu viel Code an den Client zu senden, und weniger Einblick in Optimierungen wie den automatischen statischen Export.

@ Timneutkens Vielleicht
Der Vorteil von React-Router ist, dass Entwickler die vollständige Kontrolle über den Code haben.

@ Timneutkens , ich werde hier keinen Streit anfangen, aber ich bitte Sie, meinen Kommentar zu verbergen. Ich habe Zeit damit verbracht, meinen Job verfügbar zu machen und ihn der Community zurückzugeben, und ich sehe nicht, wie die Stummschaltung von Menschen zur Open-Source-Entwicklung beitragen kann.

@ Timneutkens Was die Punkte

Zu viel Code auf der Clientseite

Jedes moderne Bundle kann Client-Assets in Blöcke aufteilen, und react-router -Routen sind eigentlich sehr bequeme Aufteilungspunkte.

Höhere Entwicklungszeiten für Entwickler

Es ist ein Preis für ein großes Projekt, aber nichts, was mit einer richtigen Feinabstimmung des Webpacks nicht erreicht werden kann.

Keine statischen Exporte

Ich bin damit einverstanden, dass statische Exporte eine wichtige Optimierungsschicht sind. Die meisten Seiten, die von einer durchschnittlichen Next.js-Anwendung bereitgestellt werden, müssen ohnehin dynamische Daten abrufen und können nicht von statischen Exporten profitieren.

An dieser Lösung mangelt es nicht. Z.B. Möglicherweise kann eine Liste der Routen, die statisch exportiert werden sollen, weiterhin manuell deklariert werden

Der Grund, warum ich den Kommentar versteckt habe, ist, dass dies ein Problem mit hohem Datenverkehr ist und nicht unsere Empfehlung zum Erstellen von Next.js-Apps widerspiegelt. Wenn jemand hier landet und einen React-Router verwenden möchte, wird er blindlings Ihr Beispiel verwenden und nicht untersuchen, wie das Routing mit Next.js richtig eingerichtet werden kann.

Es ist ein Preis für ein großes Projekt, aber nichts, was mit einer richtigen Feinabstimmung des Webpacks nicht erreicht werden kann.

Sie können das Booten während der Entwicklungszeit nicht basierend auf Ihrem Ansatz beschleunigen. Es gibt keine spezifische Feinabstimmung der Webpack-Konfiguration, da Webpack nur jede einzelne Route kompiliert und überwacht, die Sie importieren, was die Bearbeitung allgemeiner Komponenten massiv verlangsamt. Daher hat Next.js On-Demand-Einträge: https://nextjs.org/blog/next-8#improved -on-Demand-Einträge

Darüber hinaus gibt es ein (automatisches) Vorabrufen von Routen usw. Es gibt Unmengen von Details, auf die ich hier eingehen könnte, aber das tldr ist, dass Sie am Ende eine schlechtere Entwicklererfahrung und App haben werden.

Es macht mir nichts aus, den Kommentar auszublenden, wenn er richtig widerspiegelt, dass Sie ihn nur verwenden möchten, indem Sie eine App migrieren, die bereits einen React-Router verwendet, und dann schrittweise zu mehreren Seiten wechseln.

Hey @timneutkens
Würden Sie einige der Profis zählen, die statisch analysierbar sind und mit den dynamischen Routing-Lösungen nicht möglich sind?

So etwas wie das https://github.com/jaredpalmer/after.js ?

Ich habe alle Kommentare gelesen und bin mir immer noch nicht sicher, ob RR4 + in der zukünftigen Iteration von next.js enthalten oder optional sein wird. Ist das eine Router-Roadmap oder ähnliches?

@laurencefass Es scheint, dass es keinen Plan gibt, react-router (ab heute) zu unterstützen.

Für mich wird das Routing-System von Next.js ausgereift genug, so dass wir es wahrscheinlich sowieso nicht mehr brauchen :)

"Für mich wird das Routing-System von Next.js ausgereift genug, so dass wir es wahrscheinlich sowieso (nicht mehr) brauchen :)"

Mit Ausnahme derjenigen, die Next.js schrittweise in eine vorhandene Codebasis übernehmen möchten. Ich denke, die nützlichere Diskussion ist wahrscheinlich nicht "Next.js Routing vs React-Router Routing". Ich denke, die nützlichere Diskussion ist: "Wie kann ich eine riesige App mithilfe des React-Routers schrittweise auf Next.js migrieren?"

Der Router von Next kann Routenansichten jedoch nicht verschachteln, oder? Bei jeder Navigation zu einer Route wird das DOM weggeblasen und aktualisiert. Verschachtelte Ansichten sind eine häufige Anforderung.

@dbbk https://github.com/jaredpalmer/after.js

@dbbk Ich habe gehört, dass das Team von nextjs daran arbeitet.

next js ist ziemlich flexibel mit Routern. https://dev.to/toomuchdesign/next-js-react-router-2kl8

Ich verschiebe eine Website von normalen JS- und jQuery-Codes nach React. Im Gegensatz zu den alten Codes muss ich verhindern, dass die Musik beim Seitenwechsel stoppt, deshalb habe ich dafür React Router verwendet.

Aus SEO-Gründen muss ich das beibehalten, da ich einige gute Zugriffe von der Google-Suche habe. Daher würde ich SSR mit Next.js für eine bessere Leistung bevorzugen.

Ist Next.js in der Lage, eine Seite auf der Serverseite zu rendern, und sobald die Seite auf der Clientseite geladen ist, lässt Next.js die Navigation unter React Router-Steuerung zu, sodass der Next.js-Link gewinnt, wenn der Benutzer Musik hört. Müssen Sie die aktuelle Seite nicht verlassen, um die Musik zu stoppen?

O kann Next.js nur clientseitiges Routing durchführen?

Wenn die Integration von React Router dies beheben kann, bin ich dabei. Da die kontinuierliche Musikwiedergabe für mich ein Muss ist, sobald die App die Client-Seite erreicht.

next js ist ziemlich flexibel mit Routern. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , das ist ein sehr guter Ansatz, ich habe ihn schon

@KeitelDOG Sie benötigen dafür keinen

_edit: Ich füge nur Folgendes hinzu: Vielleicht ist der einzige Vorteil von React-Router die einfach verschachtelten Routen in derselben Ansichtsfunktion. Next.js Router sollte 95% Ihrer Anwendungsfälle lösen_

@martpie Danke für die Antwort, das habe ich gestern Abend mit der Link -Komponente gesehen. Dann ist Next.js der Mix Server-Client, den ich wollte.

Und für eine Komponente, die ihre eigenen verschachtelten Routen dynamisch dynamisch steuert, gefällt mir React Router sehr gut. Aber ich bin mir ziemlich sicher, dass ich Abhilfe schaffen kann, da ich nicht eine React-Website in Next.js ändere, sondern stattdessen plane und teste, eine JS-jQuery-Website in eine mehrseitige React-Anwendung zu ändern, ohne meine SEO-Vorteile zu verlieren auf Google. Also denke ich, ich sollte mit Next.js gehen

@timneutkens Pläne, dies in Next.js 10 zu unterstützen?

@ TrejGun danke, das ist definitiv kein Thema.

Hast du einen Plan?
Das next/router ist großartig, es bietet eine Menge Hilfe. Wir brauchen jedoch einen professionelleren Router, um komplexe Anwendungen zu bewältigen. React-Router ist führend im Router.
Vielleicht kann auf after.js verweisen.

Ja, dieses seitenbasierte System ist einfach nicht hoch genug, um komplexe datengesteuerte Anwendungen zu verarbeiten, die von verschachtelten Routen profitieren könnten.

React-Router ist im Begriff, die Version 6 zu starten, die der bisher beste Router sein wird. Ich freue mich darauf, next.js unterstützen.

Ein besserer Ansatz besteht darin, next.js und router zu trennen, damit die Leute ihre Lieblings router frei wählen können.

+1 für vorherigen Kommentar. next.js ist erstaunlich. Der einzige Grund, warum ich es nicht benutze, ist die mangelnde Flexibilität des Routers. Bitte unterstützen Sie React Router 6 in zukünftigen Versionen oder machen Sie den Router austauschbar.

Leute, die sich wirklich für React Router interessieren, könnten daran interessiert sein, dem neuen Projekt „Remix“ zu folgen. Es ist eine Alternative von Next.js, die React Router von denselben Entwicklern verwendet:

• https://twitter.com/remix_run/status/1253043162714525696
• https://remix.run

Ich denke, das Problem ist, dass das Framework aufgrund von SSR, serverseitigen Requisiten usw. eng mit diesem Router verbunden ist.

Next ist auf Leistung ausgelegt, und der serverseitige React-Router hat erhebliche Auswirkungen auf die Leistung, da Sie den DOM-Baum durchlaufen müssen, bevor Sie wissen, was Sie rendern möchten und welche Daten Sie benötigen. Der gesamte Zweck von getInitialProps besteht darin, dass Sie vor dem Abrufen von Daten kein wegwerfbares Rendern von Reaktionen durchführen müssen. Dies ist eine häufige Gefahr, die viele Frameworks auf dem Server (und auf dem Client, auf dem sie sich manifestieren) aufweisen Wasserfälle anfordern). Next könnte dies möglicherweise umgehen, indem jede Seite der obersten Ebene _all_ der verschiedenen Datenmuster deklariert, die die verschiedenen Unterkomponenten möglicherweise benötigen, und auf dem vollständigen Anforderungspfad verzweigt (oder einen massiven einzelnen Überabruf durchführt). Dies würde jedoch schnell und unhandlich werden wäre eigentlich nicht so anders als jede Seite einzeln zu deklarieren.

Dies ist der gleiche Grund, warum Relay auch nicht mit React-Router kompatibel ist und Sie facebook.com nicht vorwerfen können, keine komplexe Website zu sein.

Die wichtigste erfolgreiche Strategie für die Arbeit mit dem Next-Router ist die Kompositionsfähigkeit (was ohnehin der treibende Trend im modernen React ist), mit der Sie Komponenten ohne größere Doppelarbeit wiederverwenden können und gleichzeitig über eine effiziente SSR verfügen, mit der alle Daten abgerufen werden können (über getInitialProps ), bevor Sie jemals mit dem React-Renderer sprechen.

Ich habe das Gefühl, dass die Leistungseinbußen beim Gehen auf dem Baum überbewertet sind. Viele Produktionsanwendungen machen dies heute mit zB Apollo und es scheint in Ordnung zu sein.

Außerdem können Sie Ihre Antworten auch per CDN zwischenspeichern, wenn Sie den Server wirklich von zu viel Arbeit entlasten möchten.

Klar, ich möchte nur auf die Hauptgründe hinweisen, warum React-Router (AFAICT) in seiner aktuellen Implementierung grundsätzlich nicht mit Next kompatibel ist. Viele Websites brauchen überhaupt keine Perfektion, wie die Leute beweisen, die gerne kostenlose Heroku-Dynos mit langsamen Kaltstartzeiten verwenden (und ich möchte betonen, dass ich dies nicht herablassend sage, da ich dies auch für einige Websites tue kann die perfekte Passform sein). Aber Next wäre bei einigen größeren Unternehmen, die es verwenden, nicht beliebt, wenn es weniger aggressiv in Bezug auf die Leistung wäre, da diese Unternehmen sich darum kümmern würden, dass ihre Serverantwortzeiten messbar langsamer sind. Wenn es für einige Websites kein Problem wäre, würden die Benutzer den Streaming-Renderer von React nicht verwenden (und warten gespannt auf Verbesserungen), um zu reagieren, bevor auch nur ein einziger Render abgeschlossen ist, geschweige denn zwei.

Sie können Ihre Antworten definitiv im CDN zwischenspeichern, dies eliminiert jedoch viele Personalisierungs- / Anmeldeoptionen (da dies einen Kompromiss darstellt, wie niedrig Sie Ihre Trefferquote steigern oder das teilweise Rendern von Seiten auf den Client verschieben möchten). Wenn Sie Ihre gesamte App per CDN zwischenspeichern können, ist es möglicherweise besser, CRA und react-snapshot und Server vollständig zu vermeiden. Es geht nicht unbedingt darum, wie viel Arbeit Ihr Server leistet, sondern wie lange es dauert, auf eine Anfrage zu antworten.

Und Apollo ist ein großartiges Beispiel für ein Framework, bei dem die Benutzerfreundlichkeit gegenüber der Leistung im Vergleich zu einem eher einfühlsamen / perf-orientierten Framework wie Relay im Vordergrund steht. Es ist alles ein Spektrum.

Ja, ich denke das ist fair genug. Aber ich bin gespannt, wie sich remix.run entwickelt. Vielleicht haben sie einen neuen Ansatz entwickelt, damit es mit react-router funktioniert. Ja, es ist wahr, dass verschachtelte Routen nicht obligatorisch sind, aber Sie müssen sicherlich zustimmen, dass es intuitiver ist, Teile der inneren Benutzeroberfläche mit der Route zu ändern, als unterschiedliche Seiten zu haben und jede dieser Seiten mit unterschiedlichen Layouts zu versehen.

Ab nächsten 9.3, es ist getStaticPaths zusätzlich zu getServerSideProps , um die Rahmen Pfade zu entdecken vorrendern , wenn der Pfad Route Parameter. Möglicherweise könnte ein ähnlicher Ansatz mit dem React-Router verfolgt werden.

@merryweather : "Next wurde unter Berücksichtigung der Leistung entwickelt, und der serverseitige durchlaufen müssen, bevor Sie wissen, was Sie rendern möchten."

Naive Frage: Können Sie einfach Links der obersten Ebene rendern und Code abrufen / vorabholen / zwischenspeichern, sobald er auf dem Client ausgeführt wird? Wenn Sie nicht wissen, wohin der Client navigieren wird, ist es sinnvoll, den DOM-Baum auf dem Server zu durchlaufen?

Naives Arbeitsszenario: Wenn der Client eine URL anfordert, werden nur Links der obersten Ebene und standardmäßig aktive Linkinhalte gerendert und auf Anfrage alles andere per Ajax / Fetch abgerufen (oder nach dem Laden der Seite im Hintergrund vorab abgerufen) ... alles andere umfasst alle unteren Ebenen Routen ... spülen und wiederholen ...?

@laurencefass aber auch die Top Level Links sind im Code und müssen doch entdeckt werden oder? Oder möchten Sie neben dem React-Router auch das Dateisystem-Routing verwenden, damit die Links der obersten Ebene erkennbar sind?

@ avin-kavish Ich bin nicht die beste Person, um Details zur Implementierung zu beantworten, aber auf dem Client muss nur der ursprüngliche Bildschirminhalt gerendert werden: Links der obersten Ebene + Standardinhalt. Alles andere ist beim ersten Laden überflüssig, denke ich. Warum also das DOM auf dem Server laufen lassen?

Das Hauptproblem bei Next.js ist nicht der Router, sondern das Datenabrufmuster mit getInitialProps , getServerProps oder getStaticProps . Warum ? Weil es die Datenisolation für die Komponente unterbricht, die es benötigt. Sie möchten beispielsweise Daten für das Menü abrufen. Woher holen Sie sie? Ich weiß es nicht. Top-Komponenten wie pages sollten nichts darüber wissen, oder?

Das Hauptproblem bei Next.js ist nicht der Router, sondern das Datenabrufmuster mit getInitialProps , getServerProps oder getStaticProps . Warum ? Weil es die Datenisolation für die Komponente unterbricht, die es benötigt. Sie möchten beispielsweise Daten für das Menü abrufen. Woher holen Sie sie? Ich weiß es nicht. Top-Komponenten wie pages sollten nichts darüber wissen, oder?

Würden Sie bitte näher darauf eingehen? Und was ist die alternative Lösung?

@lishine Es tut mir leid, abweiche , aber in den meisten Fällen sehe ich nicht, dass Router hier das Hauptproblem ist. Der Router von Next.js ist gut, deklarativ, die Konvention über die Konfiguration ist gut. Das einzige, was ich in Next.js nicht verwenden kann, sind die Datenabrufmethoden wie getInitialProps , ...
In meinen Apps muss jede Komponente ihre eigenen Daten direkt am selben Ort und in derselben Datei deklarieren, unabhängig davon, ob es sich um eine Grafikdatei oder eine Restdatei handelt.
Die Top-Pages-Komponente dient nur zum Erstellen untergeordneter Komponenten, und das Abrufen von Daten ist nicht ihre Aufgabe. Die untergeordnete Komponente muss Daten von sich selbst erhalten, nicht von ihren Eltern.

Hier ist mein Codebeispiel, das ich aus Gründen der Übersichtlichkeit für meine App verwende:

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

Wie Sie sehen, haben Sie eine Komponente mit eigenen Daten. Sie können es überall platzieren, wo Sie wollen.

Natürlich können Sie das Next.js-Muster problemlos verwenden, aber in meinem Fall bevorzuge ich die Isolierung von Daten und Komponenten so weit wie möglich, um die Wartung und das Refactoring später zu vereinfachen.

In meinen Apps muss jede Komponente ihre eigenen Daten direkt am selben Ort und in derselben Datei deklarieren, unabhängig davon, ob es sich um eine Grafikdatei oder eine Restdatei handelt.
Die Top-Pages-Komponente dient nur zum Erstellen untergeordneter Komponenten, und das Abrufen von Daten ist nicht ihre Aufgabe. Die untergeordnete Komponente muss Daten von sich selbst erhalten, nicht von ihren Eltern.

Ich benutze es genauso.
Sie verwenden also kein SSR-Abrufen ...
Wie machen die Leute dann tatsächlich das SSR-Abrufen mit Next.js ?!

@linshine wir müssen alles, was wir brauchen, auf der obersten

@lishine Es tut mir leid, abweiche , aber in den meisten Fällen sehe ich nicht, dass Router hier das Hauptproblem ist. Der Router von Next.js ist gut, deklarativ, die Konvention über die Konfiguration ist gut. Das einzige, was ich in Next.js nicht verwenden kann, sind die Datenabrufmethoden wie getInitialProps , ...
In meinen Apps muss jede Komponente ihre eigenen Daten direkt am selben Ort und in derselben Datei deklarieren, unabhängig davon, ob es sich um eine Grafikdatei oder eine Restdatei handelt.
Die Top-Pages-Komponente dient nur zum Erstellen untergeordneter Komponenten, und das Abrufen von Daten ist nicht ihre Aufgabe. Die untergeordnete Komponente muss Daten von sich selbst erhalten, nicht von ihren Eltern.

Hier ist mein Codebeispiel, das ich aus Gründen der Übersichtlichkeit für meine App verwende:

...

Wie Sie sehen, haben Sie eine Komponente mit eigenen Daten. Sie können es überall platzieren, wo Sie wollen.

Natürlich können Sie das Next.js-Muster problemlos verwenden, aber in meinem Fall bevorzuge ich die Isolierung von Daten und Komponenten so weit wie möglich, um die Wartung und das Refactoring später zu vereinfachen.

@ revskill10 Warum kann das Kind sein

Wir haben eine Relay-Next-App und dieses Muster funktioniert perfekt, mit Datenkapselung und wiederverwendbarer Komposition, und wir nutzen getInitialProps mit Leichtigkeit.

@merrywhether Ganz zu schweigen von much harder in REST , Ihr Ansatz hat ein Problem, bei dem Sie nicht entscheiden können, welches fragments SSG / SSR oder CSR sein wird.
In meinem Ansatz ist es genauso einfach wie das Importieren dieser Komponente mit { noSSR: true/false} .

Ich finde die Bindung an eine herstellerspezifische Routing-Bibliothek, die keine zugrunde liegende Implementierung mit einer größeren Routing-Bibliothek teilt, äußerst besorgniserregend.

Ich habe kürzlich Next.js überprüft, um zu bewerten, ob es als Basis für den gemeinsamen Kern verwendet werden soll, der von einer Reihe von Frontend-Anwendungen gemeinsam genutzt wird, die für unseren aktuellen Client erstellt werden. Während Next.js Potenzial hat; Dieser Router ist einer der Hauptgründe, warum ich Next.js abgelehnt und stattdessen CRA als Basis für diese Anwendungen beibehalten habe.

Ich verstehe die Schwierigkeit, die komponentenbasierte Top-Level-API von react-router / @reach/router als Basis für SSR zu verwenden. Dies ist jedoch kein guter Grund dafür, dass die zugrunde liegende Implementierung vollständig benutzerdefiniert ist. Gatsbys SSG hat die gleichen Bedenken wie Next.js und eine halbähnliche dateibasierte Routing-Struktur. Nach meinem Verständnis verwendet Gatsby jedoch @reach/router unter der Haube, um die Routing-Implementierung voranzutreiben, anstatt das Rad neu zu erfinden oder eine Link-API verfügbar zu machen, die nicht mit der von anderen Bibliotheken verwendeten Link-API übereinstimmt.

@dantman darf ich fragen, was hast du für Next.js Alternative gewählt. Angenommen, Sie benötigen serverseitiges Rendering ... Ich habe After.js ausprobiert. Vielleicht kann es einige Anregungen / Ideen für die Implementierung in Next.js liefern, wenn es nicht von zeit unterstützt wird.

@dantman darf ich fragen, was hast du für Next.js Alternative gewählt. Angenommen, Sie benötigen serverseitiges Rendering ... Ich habe After.js ausprobiert. Vielleicht kann es einige Anregungen / Ideen für die Implementierung in Next.js liefern, wenn es nicht von zeit unterstützt wird.

Entschuldigung, ich habe keine hilfreiche Antwort für Sie. SSR war keine schwierige Anforderung, daher verwendeten wir weiterhin CRA, mit dem der Prototyp gebaut wurde.

Ich dachte, Next.js wäre als universelles Framework vielversprechend, da es kürzlich die Möglichkeit erhielt, eine Mischung aus SSR / SSG / Nur-Client-Seiten zu erstellen und als isomorphe App oder als statische / PWA-App ausgeführt werden kann. Die WebPack-Anpassung war verlockend, da CRA die Verwendung des Globalize-Compilers erschwert hat. Der Next.js-Server war neutral / positiv, da wir sowieso einen API-Server für eine GraphQL / REST-Bridge benötigten. Und die Option von SSR / SSG war positiv, da ich den Kern aufbaue, auf dem ein halbes Dutzend Anwendungen basieren werden, und es ist nicht unmöglich, dass es in Zukunft nützlich sein könnte. Ich hatte jedoch auch einige Probleme mit der Funktionsweise der SSR von Next.js, und diese positiven Ergebnisse waren die vom Router verursachten Probleme nicht wert.

@ Dantman

Ich finde die Bindung an eine herstellerspezifische Routing-Bibliothek, die keine zugrunde liegende Implementierung mit einer größeren Routing-Bibliothek teilt, äußerst besorgniserregend.

Es ist ziemlich seltsam, eine Open-Source-Komponente mit einer API zu qualifizieren, die sich seit 3 ​​Jahren aufgrund ihrer hohen Stabilität und „Produkt- / Marktanpassung“ nicht als „Lock-In“ geändert hat.

Next.js ist erfolgreich und zeigt weiterhin das Wachstum, das es aufgrund seines Routers und nicht trotz

Wie viele gesehen haben, die ich auf Twitter kommentiert habe, haben wir uns einmal ernsthaft mit dem Zusammenführen in einem Router beschäftigt (obwohl ich mir nicht sicher bin, welcher der Standard in Ihrem Kopf ist, Reach oder React Router und in welcher Hauptversion). Aber die Welt hat uns in andere interessante Richtungen gezogen. In Wirklichkeit wussten wir nicht einmal, worum es ging, es hinzuzufügen, weil alle mit Next.js erfolgreich waren und wundervolle Produkte bauten.

Wenn ich mich tatsächlich bei den Leuten erkundigte, warum sie eine andere Router-API wollten, war der Grund, der am häufigsten auftauchte, der, dass die Leute mit einheimischen Framework-Lösungen, die auf einem Router basieren, festgefahren und frustriert waren und es kaum erwarten konnten, zu Next zu migrieren . Es war kein Grund, der im Produktdesign verwurzelt war.

Wenn ich sage, dass Next aufgrund seines Routers erfolgreich war, dann deshalb, weil zwei Probleme beseitigt wurden:
1️⃣ Die Idee, einen Router auswählen zu müssen . Das Entfernen ist im Nachhinein eine ausgezeichnete Entscheidung. In all der Zeit, in der Next.js mit seinem stabilen Router existiert hat, hat sich die Router-Welt aufgeteilt und alle Arten von API-Änderungen gestartet

2️⃣ Die Lernkurve eines Routers . Es wurden viele Workshops und Tutorials zum Thema Routing gegeben, aber das erste Routing des Dateisystems von Next.j dauert 2 Sekunden und bietet Ihnen die Plattform, um unglaubliche Dinge zu erstellen, und Sie können direkt mit der Produktentwicklung beginnen

Ich möchte diesen letzten Punkt hervorheben. Betrachten Sie eine der neuesten und am schnellsten wachsenden Websites der Welt, TikTok.com, die auf Next.js basiert. Die gesamte Routing-Topologie dieser Website kann mit dieser zwei Sekunden langen Lernkurve erklärt werden. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 ist pages/[user]/video/[id].js und https://www.tiktok.com/trending ist pages/trending.js

Viele der jüngsten Next.js-Innovationen, die Sie gerne mögen, wie z. B. Hybrid Static / SSG / SSR, werden auch durch unser Router-Design ermöglicht. Tatsächlich wird der Router auch viele andere ähnliche Optimierungen ermöglichen, die in Zukunft weniger JS für Clients bereitstellen werden.

Ich hatte jedoch auch einige Probleme mit der Funktionsweise der SSR von Next.js, und diese positiven Ergebnisse waren die vom Router verursachten Probleme nicht wert.

Würde gerne davon hören. Das obige Beispiel wird von Next.js Hybrid Static / SSR unterstützt und wir sehen auf der ganzen Linie viel Erfolg damit!

Das ist so ein lustiger Thread. Next hat konkrete Gründe für die Vermeidung von Wasserfall-Routing (auch bekannt als React-Router und Freunde), da getInitialProps viele Leistungsoptimierungen ermöglicht und der Ansatz von Next sich als sehr beliebt herausstellt, insbesondere da einige Leute diese Optimierungen speziell wünschen. Leistung ist mit Design-Kompromissen verbunden, und manchmal ziehen Sie es vor, Design der Leistung vorzuziehen, aber das macht das Tool nicht falsch, sondern nur für Sie für ein bestimmtes Projekt falsch.

Letztendlich ist React-Router nicht das A und O von Routing-Lösungen. Es hat seine Vor- und Nachteile, ebenso wie Next. FWIW, Facebook verwendet keinen React-Router und sie wissen wahrscheinlich ein oder zwei Dinge über die Verwendung von React. Es ist also in Ordnung, Alternativen zu haben, und tatsächlich eines der großartigen Dinge am JS-Ökosystem: Lassen Sie verschiedene Dinge in der Arena der Ideen miteinander konkurrieren, und letztendlich bewegen wir uns alle vorwärts.

Da ich das Problem schließe, möchte ich klarstellen, dass wir immer offen für Kommentare, Funktionsanfragen und Fehlerberichte zu den Routing-Funktionen sind.

Im Idealfall sind diese produktgetrieben („Ich muss X machen, aber es ist nicht möglich“ oder „Y ist möglich, aber nicht ergonomisch“). Wir sind immer auf der Suche nach Verbesserungen, mit denen Sie schlanke Websites und Anwendungen mit hervorragender Benutzererfahrung erstellen können

@rauchg Kannst du erklären, warum zwei Requisiten, href und as zu einem Link gehören? Warum kann die beabsichtigte Seite nicht basierend auf dem Wert der as Requisite abgeleitet werden?

Zum Beispiel in Express, wenn ich eine Route als /blog/:slug , kann ich einfach eine http-Anfrage an /blog/hello-world senden und erwarten, dass der Router zu dieser Route weiterleitet. Ich muss nicht sowohl /blog/:slug als auch blog/hello-world an den Server senden.

@ avin-kavish das ist eine tolle frage. Es ist wichtig zu unterscheiden, was in der URL angezeigt wird und welche Seite geladen werden soll. Tatsächlich verwendet TikTok dies, um bestimmte Dinge in Modalen zu rendern, sodass beim Aktualisieren der Seite andere Seiten entstehen. Ein großer Verbesserungsbereich besteht jedoch darin, dass wir möglicherweise statisch durchsetzen sollten, dass Sie auf eine gültige Seite verweisen, die im Dateisystem vorhanden ist. Wir werden im Anschluss eine Diskussion darüber erstellen und Sie markieren!

Ich denke, für dieses https://github.com/zeit/next.js/issues/8207 besteht bereits ein Problem

Falls sich jemand dieses Problem für einen React-Router wie die Funktion "Verschachtelte Routen" angesehen hat, mit der Sie zu neuen Seiten navigieren können, ohne alles wie ich neu zu rendern, gibt es tatsächlich ein spezielles Problem, das Sie ansehen und abstimmen können. Ich habe gerade davon erfahren :

@rauchg

Um dies klar zu machen, ist mein Hauptproblem nicht das Fehlen einer Komponenten-API im RR / Reach-Stil. Ich bin mit einer SSR-fähigen datei- / konfigurationsbasierten API einverstanden. Obwohl ich ein bisschen optimistisch bin, dass Suspense in Zukunft alternative SSR / Routing-APIs nutzbar machen könnte. Mein Hauptproblem ist, dass der Router vollständig benutzerdefiniert ist und alle allgemeinen Probleme bei der Implementierung erneut implementiert werden, anstatt mit einem Teil der breiteren React-Community geteilt zu werden.

Ich finde Gatsbys Ansatz akzeptabel. Sie verfügen über eine SSG-fähige datei- und konfigurationsbasierte Routing-API und exportieren ihre eigene erweiterte Link-Komponente. Sie verwenden jedoch @reach/router , um die zugrunde liegende Implementierung mit Strom zu versorgen.

Ich finde die Bindung an eine herstellerspezifische Routing-Bibliothek, die keine zugrunde liegende Implementierung mit einer größeren Routing-Bibliothek teilt, äußerst besorgniserregend.

Es ist ziemlich seltsam, eine Open-Source-Komponente mit einer API zu qualifizieren, die sich seit 3 ​​Jahren aufgrund ihrer hohen Stabilität und „Produkt- / Marktanpassung“ nicht als „Lock-In“ geändert hat.

Der Router ist eng mit Next.js verbunden. Die Übernahme von Next.js aus einem Grund bedeutet, an den Router gebunden zu sein. Wenn wir Next.js übernehmen und später feststellen, dass next / router eine Einschränkung aufweist, die sich als lähmend für etwas herausstellt, das wir versuchen, gibt es absolut keine vernünftige Notluke. "Lock-in" ist dafür ein perfekter Deskriptor.

Lock-In allein wäre kein großes Problem. Gatsbys Verwendung von @reach/router wäre ebenfalls ein Lock-In. Aber @reach/router wird nur außerhalb von Gatsby verwendet. Ich muss der Gatsby-Community nicht allein vertrauen, um den gesamten Router-Stack zu verwalten. Ich kann darauf vertrauen, dass eine größere Community darauf angewiesen ist und mehr Stakeholder (spezifisch für den Routing-Stack) beteiligt sind, um sicherzustellen, dass dieser beibehalten wird, mit schwierigen Routing-Problemen (z. B. Zugänglichkeit) Schritt hält und von einer breiteren, vielfältigeren Community abhängig ist wird wahrscheinlich alle potenziell lähmenden Probleme teilen, auf die wir in Zukunft stoßen könnten.

obwohl ich verwirrt bin, welcher der Standard in Ihrem Kopf ist, Reach oder React Router und bei welcher Hauptversion

In Bezug auf den De-facto-Standard, wie <Link> aussehen sollte. Sowohl Reach als auch React Router (RR) verwenden sehr ähnliche APIs. zB <Link to='/about'>About</Link> ist sowohl in RR als auch in Reach gültig (und natürlich in Erweiterung Gatsby). Das macht Next.js 'eigenwilliges <Link href='/about'><a>About</a></Link> so viel nerviger.

In Bezug auf das, was Next.js meiner Meinung nach verwenden sollte. Ich bin nicht an eine bestimmte Bibliothek gebunden. Wenn Next.js bereits eine verwendet, würde ich nicht empfehlen, zu einer anderen zu wechseln. Mein Hauptanliegen ist, dass die Routing-Implementierung mit einer Bibliothek mit einer breiteren Community außerhalb von Next.js geteilt wird.

In der Praxis ist das jedoch relativ umstritten. Bisher habe ich außer RR und Reach keinen React-Router mit einer großen Benutzerbasis gesehen. Und RR und Reach werden zu einer Bibliothek, sodass alles, was Sie mit dem Endergebnis beginnen, gleich ist.

Ich habe vor einiger Zeit Next ausprobiert, aber mangelnde Flexibilität auf dem Router führte dazu, dass ich eine Razzle-Implementierung namens After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com entdeckte.

Da React Router nur ein Paket ist, können wir es nicht importieren und das Rendern nur auf die Clientseite beschränken, damit es wie ein SPA funktioniert, in dem es benötigt wird, und uns verschachtelte Komponentenrouten gibt? Ist der React-Router nicht nur eine Reihe von Komponenten, die (möglicherweise) in Seiten eingebettet und wie alle anderen Komponenten mit dem Next.js-Seitenrouter geladen werden sollen?

Ich habe in früheren Threads gelesen, dass zeit plant, RR zu integrieren. Stimmt das heute noch?

Warum erlauben wir nicht als letzten Ausweg verschachtelte Routen im Router von next.j und machen deutlich, dass diese Bereiche nicht vorgerendert werden. Zumindest erspart es uns die Mühe, das Schreiben der if-Bedingungen zu vermeiden, die wir zwangsläufig schreiben müssen, wenn sich eine Unterressource auf der Seite basierend auf der Route ändern soll.

Ich füge meine Stimme zu diesem Thema hinzu.

Ein weiterer Vorteil, der nicht erwähnt wird, ist, dass RR besser testbar ist (AFAIK gibt es keine offizielle nextjs-API für Routertests) und MemoryRouter für das Umschließen von Tests und Storys hat.

Next.js bietet viele gute Funktionen (automatisches WebPack, statische Dateien und TypeScript wie CRA, jedoch nicht nur für PWAs, API-Routen, serverlose Unterstützung, schnelle Aktualisierung und sogar experimentelle Expo-Unterstützung für web + native Apps) und einen Kern für SSR und SSG, auch wenn die API dafür nicht großartig ist. Aber während das eingebaute Routing-System und SSR / SSG für einige funktionieren; für andere humpeln sie die Entwicklung, weil die Grenzen beider APIs die falschen Kompromisse für dieses Projekt bieten.

Wie wäre es mit einem Kompromiss. Next.js hat bereits Plugins. Anstatt den Router intern zu ersetzen, was wäre, wenn wir den Router und die SSR-API (dh die getStaticProps / getServerSideProps in Routendateien) vom Kern von Next.js trennen würden. Beispiel: Wir könnten die sehr grundlegenden Kernteile in @next/core einfügen und den aktuellen Meinungs-Router und die get*Props APIs auf @next/router . Der Einfachheit und Abwärtskompatibilität halber könnte next ein Framework sein, das @next/core erneut exportiert und mit dem von Vercel bevorzugten Router vorkonfiguriert ist. Aber dann wäre es für die Community möglich, Router und SSR / SSG-APIs mit unterschiedlichen Kompromissen zu entwickeln, die besser für Projekte geeignet sind, bei denen sonst die guten Teile von Next.js mit dem Badewasser weggeworfen würden.

Einige Gedanken darüber, was der Next.js-Kern vom Router-Plugin verlangen würde:

• Bei einer Anfrage {url, body, etc} würde der Core erwarten, dass das Router-Plugin diese Anfrage in ein Dokument (String oder Streaming) rendert oder eine Antwort auslöst (dh 404 oder Weiterleitung).
• Beim Export erwartet der Core, dass das Router-Plugin eine Liste der Seiten bereitstellt, die gerendert werden müssen.

@next/router würde wahrscheinlich die gleichen Muster über die API implementieren, indem er Dinge wie:

• Geben Sie bei einer Anfrage die verantwortliche Routendatei an und rendern Sie wie gewohnt
• Auf dem Client wird etwas Ähnliches getan, um zu wissen, wann die SSR-API aufgerufen und die benötigte Route gerendert werden muss (möglicherweise wird die API-basierte SSR-API auf eine normal aussehende API-Route verschoben).
• Beim Export mit dem Seitendateibaum und getStaticPaths , um die Liste der statischen Seiten bereitzustellen

Ich könnte mir wahrscheinlich vorstellen, mit einem Router-Plugin zu experimentieren, indem ich React Router v6 mit @apollo/react-ssr und Suspense mit react-ssr-prepass oder react@experimental . Was auf reine SSR-Routen für isomorphe SSR-Routen verzichtet und SSR / SSG implementiert, ohne eine API im Stil von get*Props einzuschränken.

Mir wurde klar, dass verschachteltes Routing + SSG erreichbar ist, ohne die aktuelle API zu beschädigen. Wir haben also momentan getStaticPaths Damit können wir auf verschachtelte Routen für das Pre-Rendering hinweisen. Zum Beispiel,

Bei einer Route /foo/[...slug] ,

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

kann vorgerendert werden mit,

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

So wie es im Moment ist, ist next.js wie ein serverseitiges Framework mit dem Komfort, Seiten in Reaktion zu erstellen. Es fühlt sich nicht so mächtig an wie react-router . Verzeichnisbasiertes Routing hat möglicherweise seinen Platz beim Erstellen von Websites mit Kundenkontakt wie tiktok, wie bereits erwähnt, aber für komplexe datengesteuerte Anwendungsportale ist verschachteltes Routing immer noch das A und O. Aus diesem Grund wurden in erster Linie Anwendungen für einzelne Seiten erstellt. Sie ermöglichen das Ändern von Teilen der Benutzeroberfläche, ohne dass die gesamte Seite ersetzt werden muss. Dies kann genutzt werden, um Ressourcen-Subressourcen-Beziehungen ganz bequem zu modellieren. So wie es aussieht, kann ich next.js wenn ich die öffentlichen Seiten einer Consumer-Site wie eine E-Commerce-Site erstellen würde, aber wenn ich die privaten Bereiche wie Admin-, Käufer- und Verkäuferportale erstellen müsste, würde ich dies tun Wechseln Sie zu CRA.

@ avin-kavish Das Hauptproblem besteht nicht darin, es zum Laufen zu bringen, sondern es zu optimieren: Jede Seite in Next.js Standard hat ein eigenes Bundle und ist auf Geschwindigkeit optimiert.

Wenn Sie anfangen, eine Menge Inhalt / Unterinhalt auf einer einzelnen Seite hinzuzufügen, wie Sie es getan haben, könnten Sie am Ende ein ziemlich großes Bündel erhalten (was an sich nicht "schrecklich" ist, aber Sie sollten sich nur dessen bewusst sein Kompromisse). Möglicherweise können Sie eine manuelle Optimierung mit next/dynamic nachdenken :)

@rauchg die einzige Dimension ist nicht, ob der nächste Router gut oder schlecht ist. Eine weitere sehr wichtige Sache ist die Migration zu und von next.js und Unterstützung der Gemeinschaft, und https://github.com/vercel/next.js/issues/1632#issuecomment -633.310.614 es gut setzen. Next.js ist eine gute Lösung, um einen Großteil des Boilerplates zu abstrahieren, das eine hochwertige SSR-App benötigt, und als solches ein sehr einladendes Migrationsziel für viele Web-Apps. Das Problem im Moment ist, dass ein vollständiges Routing-Rewrite sowohl für die Migration in next.js als auch bei Bedarf erforderlich ist.

Das von @dantman zuvor vorgeschlagene

Das Problem mit dem React-Router (und jeder verschachtelten Routing-Lösung) besteht darin, dass die statische Analyse erheblich erschwert wird, da die relevanten Codepfade für eine bestimmte URL nicht verfügbar sind, ohne den Code selbst auszuführen (oder zu simulieren). Als nächstes folgt mehr als nur ein Framework "Benutzeroberfläche auf eine Webseite setzen". Deshalb haben sie beispielsweise mit dem Chrome-Team zusammengearbeitet, um besser optimierte Bündelungsstrategien zu entwickeln.

React-Router-Benutzer sind es gewohnt, React-Loadable direkt zu verwenden, da diese Verantwortung vollständig an Endbenutzer delegiert wird. Next versucht jedoch, dies zu abstrahieren und zu automatisieren, was nicht einfach ist. Der vorgeschlagene Ansatz für steckbare Router müsste wahrscheinlich Router-Plugins beinhalten, die dem Framework umfangreiche Informationen zur Erstellungszeit bereitstellen, um dieselbe Art von Ausgabe zu erzielen, da jeder Router wissen müsste, wie solche Informationen basierend auf seinen eigenen Mustern generiert werden.

Rein spekulieren, aber ich stelle mir vor, dass viele Dinge in der Schwebe sind, während React Suspense beendet, da ein erstklassiges Muster in der Bibliothek alle Router-Bibliotheken stark beeinflusst und auch eine konkrete Grundlage bietet, auf der asynchron / ladbar aufgebaut werden kann Bündelmuster.

Lange Rede, kurzer Sinn / eine gute Zusammenfassung von unten: Es gibt keine "Einheitslösung". Alles hat Kompromisse. Jeder "Vorteil" der Art und Weise, wie Next.js derzeit Dinge tut, hat einen Nachteil. Welche Vor- / Nachteile am wichtigsten sind, ist für jedes Projekt unterschiedlich. Daher die Empfehlung für eine steckbare Router / ssg / ssr-Architektur. Unterschiedliche Projekte benötigen unterschiedliche Dinge und im Moment funktioniert Next.js nur für Projekte, deren Priorität bei Kompromissen mit der Art und Weise übereinstimmt, wie die Dinge in Next.js fest codiert sind.

Das Problem mit dem React-Router (und jeder verschachtelten Routing-Lösung) besteht darin, dass die statische Analyse erheblich erschwert wird, da die relevanten Codepfade für eine bestimmte URL nicht verfügbar sind, ohne den Code selbst auszuführen (oder zu simulieren).

Ehrlich gesagt ist das nur wichtig, wenn Sie SSG verwenden und eine Reihe nicht dynamischer Routen haben. Wenn alle Ihre Routen nur SSG oder Client sind, ist dies nicht sinnvoll. Und wenn die meisten Ihrer Routen dynamisch sind, müssen Sie sie sowieso explizit mit getStaticPaths deklarieren. Dies wäre der gleiche Arbeitsaufwand wie das explizite Definieren der Routen in einem hypothetischen Next.js-Plugin, das nur den rohen React-Router ohne Änderung verwendet und Sie auffordert, statische Routen explizit zu definieren.

Das ist sicher ein Vorteil, und einige Teams werden das wollen. Dies ist jedoch nur eine Untergruppe potenzieller Next.js-Benutzer. Es gibt andere Gruppen, die möglicherweise einige der Vorteile wünschen, die RR oder eine andere Routing-Bibliothek bietet, und die Notwendigkeit, statische Routen explizit zu deklarieren, ist ein akzeptabler Kompromiss oder kein Problem. Zum Beispiel waren meine letzten Projekte B2B / B2C-Apps, bei denen sich 100% der Dinge hinter einer Anmeldeseite befinden und es keinen Sinn macht, irgendetwas davon statisch zu rendern. Next.js hat einige Vorteile gegenüber CRA, die Next.js vorzuziehen gemacht hätten. Aber Dinge wie der Router waren große rote Fahnen und wir haben einfach weiter CRA verwendet. Diese Projekte wären sehr gut für eine Next.js mit rohem React-Router geeignet gewesen.

Dies setzt auch voraus, dass jeder, der nicht next/router möchte, die JSX-Form des React-Routers verwenden möchte. Dies ist nicht die einzige Art von next/router Alternative.

Ein anderer Routertyp wäre der Gatsby.js-Stil. Wenn ein Projekt immer noch eine dateisystembasierte Seitenstruktur verwendet, die Interna jedoch mit einer anderen Routing-Bibliothek wie React-Router implementiert sind (Gatsby verwendet intern @reach/router ). Diese Art von Router-Plugin bietet Ihnen die gleichen Vorteile für die statische Analyse. Es würde Ihnen aber auch alle Vorteile bieten, die der alternative Router nicht mit dem verschachtelten Routing verbunden hat. z. B. Berücksichtigung potenzieller Präferenzen für die Routen-API, bessere Handhabung der Barrierefreiheit, bessere Integration in das Ökosystem um diesen Router.

Und natürlich ist das JSX-Formular auch innerhalb des React-Router-Ökosystems nicht die einzige Möglichkeit, React-Router zu verwenden. Es gibt auch React-Router-Konfiguration . Dies ist eine einfache statische Analyse und unterstützt auch verschachteltes Routing.

React-Router-Benutzer sind es gewohnt, React-Loadable direkt zu verwenden, da diese Verantwortung vollständig an Endbenutzer delegiert wird. Next versucht jedoch, dies zu abstrahieren und zu automatisieren, was nicht einfach ist.

Und einige von uns können gut mit der Code-Aufteilung umgehen. Verschachteltes Routing kann für ein Projekt wichtiger sein als die automatische Code-Aufteilung. Es geht darum, welche Kompromisse für ein Projekt am besten geeignet sind.

Dies ist eher eine Randnotiz, aber ich bin tatsächlich neugierig auf das Potenzial für ein Babel / Webpack-Plugin, das dies automatisch für Routen tun würde.

Ebenfalls reaktionsladbar ist eine effektiv nicht mehr funktionierende Bibliothek (2 Jahre seit Veröffentlichung, keine Annahme von Fehlerberichten). Persönlich würde ich lieber manuell Code aufteilen mit @loadable/components als etwas zu verwenden, das automatisch in Next.js integriert ist, basierend auf einer internen Abzweigung von reaktionsladbarem.

Der vorgeschlagene Ansatz für steckbare Router müsste wahrscheinlich Router-Plugins beinhalten, die dem Framework umfangreiche Informationen zur Erstellungszeit bereitstellen, um dieselbe Art von Ausgabe zu erzielen, da jeder Router wissen müsste, wie solche Informationen basierend auf seinen eigenen Mustern generiert werden.

Jep. So würde ein Plugin-System im Allgemeinen funktionieren. Ehrlich gesagt ist die Tatsache, dass diese Art von Informationen vom Plugin bereitgestellt werden kann, ein Vorteil, kein Problem. Wenn dies in einem Plugin enthalten ist, kann die Art und Weise, wie Next.js diese Informationen sammelt, nicht für die Anforderungen einiger Projekttypen geeignet sein, durch eine ersetzt werden, die den Anforderungen dieser Projekte entspricht. Aber ohne alle Next.js zu teilen und neu zu schreiben, um dies zu tun.

Rein spekulieren, aber ich stelle mir vor, dass viele Dinge in der Schwebe sind, während React Suspense beendet, da ein erstklassiges Muster in der Bibliothek alle Router-Bibliotheken stark beeinflusst und auch eine konkrete Grundlage bietet, auf der asynchron / ladbar aufgebaut werden kann Bündelmuster.

Dies selbst könnte eigentlich ein ziemlich gutes Argument sein, um auf einem steckbaren Routersystem zu arbeiten. Gerade jetzt , da alle Routing und SSR Sachen in Next.js fest einprogrammiert ist , ist es nicht möglich, das Experimentieren in jede Art von Zukunft zu tun Routing - System innerhalb Next.js. Wie wirkt sich Suspense auf das Routing von Next.js und andere Routing-Bibliotheken aus? Nicht etwas, mit dem Sie experimentieren können (zumindest in Bezug auf die SSR und die Bündelung von Next.js), ohne Teile von Next.js zu forken und neu zu schreiben.

Router-Plugins wären ein großartiger Ort, um diese Art von Experimenten durchzuführen. Solange die Plugin-API niedrig genug ist, kann nur das Plugin next/router gegabelt und versucht werden, eine auf React @ Experimental + Suspense basierende Version dieses Routers zu schreiben. Und da dies ein Plugin ist (nicht eine Abzweigung aller Next.js), ist es einfach, sich für das Experiment anzumelden und den neuen Suspense-basierten Router zu testen. Dies ist jetzt und nicht später wichtig, da diese Art des Experimentierens der Grund ist, react @ experimental existiert, um Feedback von realen Projekten zu erhalten.

@ Dantman Ich bin mit nichts einverstanden, was Sie gesagt haben. Es geht nur um Kompromisse. Der größte Kompromiss ist, wofür das Next-Team seine Zeit verbringt. Bisher scheint das Hochleistungs-SSR mit niedriger Konfiguration ihr Hauptaugenmerk gewesen zu sein. Ich verstehe, dass dies nicht unbedingt für alle Benutzer relevant ist, aber es ist der Winkel, den Next ursprünglich verwendet hat, um hervorzuheben (weshalb wir sie bei der Arbeit auswählen). Sie haben sich in letzter Zeit mehr mit SSG beschäftigt, anscheinend aufgrund der Popularität von Gatsby und Jamstack, aber sie sind immer noch am besten für SSR imo.

Ehrlich gesagt ist das nur wichtig, wenn Sie SSG verwenden und eine Reihe nicht dynamischer Routen haben

Ich bin mir nicht sicher, was Sie damit meinen, da SSG gegen SSR nicht wirklich wichtig ist, um die kleinstmögliche JS-Nutzlast für die erste Seite ("kritischer Pfad" JS) bereitzustellen, und auch keine dynamischen Routen. Das Minimieren kritischer Pfadressourcen ist im Allgemeinen für SSR-Apps ziemlich wichtig (daher der ganze Aufwand), daher wird dies geschätzt. Und ehrlich gesagt, wenn Sie nur CSR-Apps mit Login-Walling erstellen, hat Next im Vergleich zu CRA viele Nachteile (SSR wird niemals so praktisch sein wie CSR). Es hört sich so an, als würden Sie die Apps, die tatsächlich Laufzeit-SSR (mit serverseitiger Abwicklung von Login / Personalisierung) durchführen, speziell für Perf-Gewinne rabattieren. Nicht alles passt in die Dichotomie zwischen SSG und CSR.

Einige von uns können gut mit der Code-Aufteilung umgehen

Einige von uns sind auch in der Lage, Webpack, React-Dom / Server usw. selbst zu handhaben. Das Ziel von Next schien bisher darin zu bestehen, einen solchen Auswurf immer seltener zu machen, genau wie bei CRA. Und Sie haben Recht, ich hätte gleichermaßen reaktionsladbar sagen sollen, denn es gibt viele Lösungen in diesem Bereich, und sie werden nur mit den aufkommenden Daten-plus-Code-Mustern aus Bibliotheken wie Relay exotischer.

Letztendlich bin ich nicht anderer Meinung, dass ein steckbares Routersystem nett sein könnte. Ich habe nur darauf hingewiesen, dass es für das Next-Team eine Menge Arbeit bedeuten würde, Dinge zu entfernen, die zentrale Grundsätze des Frameworks sind (wie die Bündelaufteilungslogik), und sie in eine steckbare Architektur zu extrahieren. Und meine Spekulationen hoben die Tatsache hervor, dass ich nicht damit beginnen möchte, eine grundlegende Änderung an meiner Bibliothek zu entwerfen, die leicht durch bevorstehende Änderungen an meiner Kernabhängigkeit geändert werden könnte. Ich stimme sicherlich zu, dass einige Aspekte des Designs von Next begrenzt sind, aber zum größten Teil sind diese Grenzen angesichts ihrer bisherigen Designbeschränkungen sinnvoll.

Ehrlich gesagt ist das nur wichtig, wenn Sie SSG verwenden und eine Reihe nicht dynamischer Routen haben

Ich bin mir nicht sicher, was Sie damit meinen, da SSG gegen SSR nicht wirklich wichtig ist, um die kleinstmögliche JS-Nutzlast für die erste Seite ("kritischer Pfad" JS) bereitzustellen, und auch keine dynamischen Routen.

Wir denken wahrscheinlich an verschiedene Gründe, warum die Fähigkeit, statisch zu analysieren, welche Routen existieren, notwendig ist. Angenommen, wir sprechen beide von "statischer Analyse" als "der Fähigkeit, die Liste der Routen (z. B. ['/about', '/', '/profile'] ) zur Erstellungszeit einfach durch Lesen des Codes zu identifizieren".

Es hört sich so an, als würden Sie über eine Art JS-Bundle-Optimierung sprechen. Zu denen ich in der Dokumentation keine Informationen gefunden habe, ist mir nicht genau bekannt, um welche Art von Optimierung es sich bei der statischen Routenanalyse handelt.

Meiner Meinung nach war diese statische Analyse von Routen in erster Linie für SSG nützlich. Das heißt, weil die pages/about.js -Datei beim Erstellen Ihrer Site vorhanden ist. Next.js weiß, dass eine /about -Route vorhanden ist, und muss das HTML für diese Route vorab rendern, obwohl Sie es nie explizit angegeben haben Es gibt eine /about Route zum Vorrendern.

SSR benötigt kein vorgefertigtes HTML, da dies nur dann der Fall ist, wenn eine Anforderung eingeht (an diesem Punkt wird der Code ausgeführt und es muss ein Pfad gerendert werden). Vom Client gerenderte Seiten haben überhaupt kein vorgerendertes HTML. Und wenn Ihre SSG-Seite dynamisch ist, müssen Sie trotzdem alle Pfade deklarieren. Daher meine Gedanken.

Und ehrlich gesagt, wenn Sie nur CSR-Apps mit Login-Walling erstellen, hat Next im Vergleich zu CRA viele Nachteile (SSR wird niemals so praktisch sein wie CSR).

Welche Nachteile haben Sie in Next.js in Bezug auf CSR-Apps? Abgesehen von den oben genannten Routerproblemen.

Nach meinem Verständnis unterstützt Next.js die gesamte Bandbreite der SSR / SSG / CSR-Routen. Es ist also angeblich immer noch zum Schreiben von CSR-Apps mit Login-Walling geeignet.

Persönlich ist meine Perspektive definitiv von jemandem, der viele weitgehend CSR-Apps mit gelegentlichen SSR- und SSG-Anforderungen schreibt und ein einziges robustes Toolkit für alle meine Projekte haben möchte, unabhängig davon, welche Mischung aus SSR / SSG / CSR sie benötigen.

Nach meiner Erfahrung hat CRA selbst innerhalb von CSR-Apps eine Reihe von Nachteilen, die die CSR-Seiten von Next.js vorteilhaft machen könnten. Die Anpassung der WebPack-Konfiguration ohne Auswerfen ist sehr wichtig. Dies verursachte mir große Schmerzen, als ich das WebPack-Plugin des Globalize-Compilers nicht einfach verwenden konnte, als ich einer App i18n hinzufügte. Die Möglichkeit, sich für bestimmte Seiten bei SSR / SSG anzumelden, auch wenn die meisten Seiten CSR sind, ist ebenfalls von Vorteil (z. B. 99,9% Ihrer Seiten sind CSR und befinden sich hinter einer Anmeldeseite; Sie haben jedoch eine Zielseite und möglicherweise Begriffe / Kontakt Seiten, auf denen Sie SSG oder SSR möchten). Ich kann nichts davon mit Sachen wie CRA vernünftig machen.

Einige von uns können gut mit der Code-Aufteilung umgehen

Einige von uns sind auch in der Lage, Webpack, React-Dom / Server usw. selbst zu handhaben. Das Ziel von Next schien bisher darin zu bestehen, einen solchen Auswurf immer seltener zu machen, genau wie bei CRA

Ehrlich gesagt ist die manuelle Routen-basierte Code-Aufteilung (stellen Sie sicher, dass Sie eine ändern, um Ihre Routen-Komponenten über React.lazy oder eine alternative Bibliothek anstelle eines direkten Imports zu verwenden) weit davon entfernt, eine benutzerdefinierte WebPack-Konfiguration manuell zu verwalten oder zu schreiben Ihre eigenen SSR-Handler mit react-dom/server .

Es ist völlig vernünftig, nicht manuell eine ganze WebPack-Konfiguration oder einen benutzerdefinierten SSR-Server schreiben zu wollen (dh ein weit verbreitetes Framework wie Next.js zu verwenden), aber dennoch in Ordnung zu sein, den React-Router zu verwenden und den routenbasierten Code manuell auszuführen. spalten. Insbesondere wenn Sie sich für die automatische Aufteilung des Routen-Basiscodes entscheiden, müssen Sie die häufig verwendete Router-Bibliothek, die Sie verwenden, verlieren und einen Router verwenden, dem eine Reihe von Funktionen fehlen, die Sie möglicherweise mit einer API benötigen, die sich stark von den Routern unterscheidet, die allgemein verwendet werden.

Ich lande immer in dieser Ausgabe, wenn ich nach einer Möglichkeit suche, react-router in NextJS zu integrieren, für die kein benutzerdefinierter Server erstellt werden muss. Deshalb habe ich beschlossen, es selbst auszuprobieren.

Erstellen Sie mit react-router v6 (Beta) ein benutzerdefiniertes _app :

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

Warum

Es ist nicht einfach, _optional alle Routen_ in NextJS zu erfassen (z. B. /foo/[[...bar]].js ), daher suche ich nach einer Möglichkeit, react-router für diese Art von Seiten verwenden zu können. Vielleicht haben andere andere Gründe, aber das ist mein Hauptanliegen und react-router bietet eine nette API, speziell in Version

Wie es funktioniert

Es wird lediglich ein benutzerdefiniertes MemoryRouter anstelle eines BrowserRouter damit der Browserverlauf nicht durch NextJS-Router und NextJS-Router durcheinander gebracht wird. Es lauscht den Änderungen des Speicherverlaufs für PUSH und REPLACE sodass Sie react-router Hooks oder Link zum Navigieren verwenden können, aber unter der Haube wäre es das Aufrufen der NextJS-Routermethoden .push und .replace .

Das Aufrufen von NextJS-Routermethoden ist erforderlich, da sonst Routenänderungen die NextJS get*Props -Methoden nicht auslösen. Mit anderen Worten, es würde ähnlich wie die Option shallow mit NextJS Link funktionieren. Der Nachteil der Verwendung von react-router 's Link ist, dass es keine prefetch . Sie können jedoch weiterhin NextJS Link verwenden und react-router kann weiterhin auf Routenänderungen reagieren.

Das Coole daran ist, dass Sie jetzt NextJS dynamic und react-router Routen nutzen und Dinge tun können wie:

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

Wie auch immer, ich hoffe das hilft jemandem. Ich habe dies nicht in der Produktion verwendet und dieser Code stammt von einem lokalen Spielplatz, den ich habe. Es gibt also wahrscheinlich Dinge, die verbessert werden könnten, aber es ist ein Anfang.

Verwenden von React Router mit Next.js 9.5+

Wenn Sie Next.js 9.5 oder höher verwenden, können Sie dies mit Rewrites tun . Verwenden Sie keinen benutzerdefinierten Server! Ein ausführliches Tutorial dazu finden Sie hier: https://colinhacks.com/essays/building-a-spa-with-nextjs

Die Grundidee:

1. Erstellen Sie eine benutzerdefinierte App ( /pages/_app.tsx )

2. Geben Sie null wenn typeof window === "undefined" . Dies ist erforderlich, um zu verhindern, dass der React-Router während des SSR-Schritts Fehler auslöst!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

Das Attribut suppressHydrationWarning soll Warnungen verhindern, die React auslöst, wenn der vom Server gerenderte Inhalt nicht mit dem vom Client gerenderten Inhalt übereinstimmt.

1. Schreiben Sie alle Routen zur Homepage neu

// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

Dann können Sie React Router wie gewohnt verwenden! Das verknüpfte Tutorial enthält viel mehr Kontext / Erklärungen, aber damit können Sie loslegen. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks Schöne Lösung kann bestätigen, dass es funktioniert. Vielleicht sollten Sie darüber nachdenken, die App auf eine eigene Seite wie app.js oder route.js oder so zu verschieben. Dann muss das umschreiben

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

Ihre Lösung ist die beste, die ich gefunden habe.