Next.js: Verwendung mit React Router 4

Erstellt am 5. Apr. 2017  ¬∑  122Kommentare  ¬∑  Quelle: vercel/next.js

Ist es möglich, next.js mit dem neuen React Router v4 zu verwenden?

Hilfreichster Kommentar

@timneutkens Das Hinzuf√ľgen der

Alle 122 Kommentare

@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?

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?

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

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:

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?

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

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

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen