Next.js: Utilisation avec React Router 4

Créé le 5 avr. 2017  ·  122Commentaires  ·  Source: vercel/next.js

Est-il possible d'utiliser next.js avec le nouveau react router v4?

Commentaire le plus utile

@timneutkens l' ajout de l'intégration de routeurs de réaction aiderait à augmenter l'adoption de nextjs et à améliorer le développement. Les développeurs comme moi aimeraient voir cela se produire, veuillez envisager d'augmenter la priorité.

Tous les 122 commentaires

@Knaackee Avez-vous essayé cette possibilité? Je me demande également si quelqu'un l'a fait fonctionner avec n'importe quelle version de RR?

Next a son propre routeur, pourquoi utiliser RR?

@sergiodxa Options de pesage lorsque je porte mon application existante sur Next. J'ai une configuration de route statique et imbriquée qui fonctionne et je me demande ce que je peux continuer à utiliser et quoi pas ..

@oyeanuj 🤔 vous pouvez migrer progressivement vers Next, il suffit de configurer Next.js pour gérer 1 route et d'utiliser un proxy pour avoir à la fois votre application actuelle et celle de Next.js, puis déplacer une deuxième route de RR vers Next.js, et que façon dont vous pouvez conserver votre application actuelle pendant la migration, vous aurez finalement tout dans Next.js

En regardant les exemples, il semble que next ait une table de routage unique comme RRv2-3 et ne supporte pas les "routes imbriquées" comme RRv4. Ce sont bien.

J'essaierais d'utiliser RR ou y a-t-il une grosse mise en garde que je ne connais pas?

@igl Avez-vous trouvé une solution à cela?

Le nouveau paradigme de routes imbriquées react-router 4 change la donne et est un incontournable de notre projet actuel. Je me demande si quelqu'un a réussi à faire fonctionner rr4 avec next.js?

MemoryRouter fonctionne, sinon comme prévu ...
Sinon, les composants dynamiques peuvent être uniquement côté client, où HashRouter fonctionne bien ...

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

Je suis également l ' approche je gère le routage côté client avec react-router et tout le contenu rendu par le serveur avec le routeur next .

@malixsys @pegiadise pouvez-vous donner plus de détails sur la façon d'utiliser le prochain routeur et le prochain routeur de réaction ensemble?

Vous pouvez définir un indicateur dans componentDidMount et restituer conditionnellement le <Router /> lorsque l'indicateur est véridique. ( componentDidMount ne fonctionne pas sur le serveur 😉)

En fait, nous intégrons bientôt React Router dans Next.js :)
- https://twitter.com/rauchg/status/948318111828099072

Est-ce toujours le cas? Je peux voir les notes de version pour V6 Canary et il n'y en a aucune mention.

Finalement. C'est définitivement dans notre esprit. Nous avons actuellement d'autres priorités (composant de mise en page, développement fiable et quelques autres problèmes ouverts de longue date).

C'est dommage, c'est peut-être une faible priorité pour l'équipe, mais c'est essentiellement la seule chose qui empêche des gens comme moi de commencer à l'utiliser. J'ai lu votre tutoriel jusqu'à ce que j'arrive au point où il est dit que les routes doivent être configurées deux fois, puis abandonnées.

@timneutkens l' ajout de l'intégration de routeurs de réaction aiderait à augmenter l'adoption de nextjs et à améliorer le développement. Les développeurs comme moi aimeraient voir cela se produire, veuillez envisager d'augmenter la priorité.

C'est dommage, c'est peut-être une faible priorité pour l'équipe, mais c'est essentiellement la seule chose qui empêche des gens comme moi de commencer à l'utiliser.

Même.

Pouvons-nous au moins rouvrir ce problème afin qu'il puisse être suivi?

Je vais rouvrir ceci, mais notez qu'il s'agit d'un projet open source et que nous n'avons pas de très bons arguments pour le moment pour zeit.co, puisque nous utilisons Next.js pour tout.

C'est pourquoi je disais que cela fait partie des objectifs à plus long terme et ne peut pas être mis en œuvre immédiatement, mais nous y travaillons.

Les fonctionnalités que j'ai introduites dans Next 6 travaillent en fait vers la prise en charge de React Router.

Nous avions d'autres priorités pour Next 6, qui améliorent considérablement la fiabilité et l'évolutivité de Next.js, par exemple la résolution de page 100 fois plus rapide, App Component, faire fonctionner la prochaine exportation en développement, babel 7, etc.

J'espère que cela va dans le sens de mon commentaire précédent.

Le TLDR est donc:

  • Nous allons le faire, mais pas immédiatement
  • Next 6 a de nombreuses améliorations dans différentes parties de Next.js

Pour étendre davantage le commentaire de

Il y a deux raisons pour lesquelles nous voulons vraiment la prise en charge de React Router :

  • Simplifier notre propre base de code Next.js, ne pas avoir à maintenir notre propre routeur, rendre les choses plus petites et modulaires
  • Simplifiez le chemin de migration des grandes applications utilisant déjà RR

En tant que tel, je suis d'accord que nous devrions garder cette question ouverte!

En contrepoint, ne pas avoir de react-router signifie que next fonctionne bien avec relay-modern et c'est l'une des raisons pour lesquelles nous sommes passés à next à partir de notre ancienne application react-router.

@merry si j'ai travaillé sur une application RRv4 avec relay-modern l'année dernière. Voulez-vous être plus précis?
Je ne me souviens pas que nous ayons eu de graves problèmes à cause de l'un ou l'autre.

@igl Ceci est conforme à la documentation de relay: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

Le problème est que l'approche des composants de RRv4 ne permet pas le déterminisme lors de l'étape de pré-compilation, ce qui peut entraîner des chutes d'eau dans le client.

@rauchg Par intérêt, ma compréhension du routeur Next est qu'il ne prend pas en charge le concept de routage imbriqué, vous pouvez donc conserver le balisage externe tout en naviguant dans une page. Savez-vous s'il existe un moyen de rendre cela possible avec le routeur actuel?

@dbbk consultez notre exemple d'application nextgram (https://github.com/now-examples/nextgram), il fait exactement cela

Dans la prochaine 5, nous accomplissons le "balisage externe" en ayant des composants de mise en page de haut niveau que toutes nos pages étendent: la mise en page de base a la navigation en haut, puis quelques sous-mises en page qui étendent la base pour les listes / détails / etc. Les composants de nos pages étendent ces sous-mises en page avec leur propre contenu spécifique. Dans les 6 prochains, vous pourriez également accomplir un "balisage externe" de base en utilisant _app.js je crois.

La prochaine version sera-t-elle configurable pour choisir une solution de routage autre que React Router?

Bonjour, je n'ai besoin que d'un routeur de réaction pour transmettre des accessoires aux pages (en utilisant <Route render ={} /> au lieu de <Route component ={} /> ), puis-je le faire avec Next?

En regardant les exemples, il semble que next ait une table de routage unique comme RRv2-3 et ne supporte pas les "routes imbriquées" comme RRv4. Ce sont bien.

Salut,

Cela signifie-t-il que je dois créer une seule page pour un seul itinéraire?

Disons que si j'ai 2 routes sign up , log in . J'aurais 1 page qui partage la même mise en page, la seule différence est la zone des formulaires. C'est que j'ai juste besoin de créer 1 fichier dans le dossier pages . Mais avec les routes suivantes, je dois créer 2 fichiers dans le dossier pages . C'est ça?

Si c'est le cas, la mise en page est remontée à chaque navigation, pas seulement dans la zone des formulaires, non?

@ 7c78 Une chose que vous pouvez faire est de tirer parti de _app.js pour une mise en page persistante pour toutes les pages. L'autre chose à faire est de créer des composants de mise en page partagés que vous pouvez réutiliser sur différentes pages afin d'obtenir ce que vous recherchez:

// pages/login.js

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

De plus, vous pouvez faire ce que nous avons fait récemment et définir les composants de mise en page de base que vos composants de page étendent tous:

//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>
    );
  }
}

Et puis vous étendez simplement BaseAuth dans vos pages de connexion et d'inscription et définissez formContent et formSubmit dans chacun d'eux (ce sont des exemples de jouets, car je ne connais pas vos exigences exactes).

@merrywhether
J'utilise actuellement votre approche, et les exemples suivants l'utilisent également.

Mais ma préoccupation est que je dois créer des pages séparées pour des formulaires séparés. C'est la mise en page est réutilisée mais pas la page. Et la mise en page est remontée à chaque navigation.

Avec RRv4, nous avons une seule page et les formulaires sont rendus / remontés en fonction des itinéraires (pas de la page entière). Les itinéraires ne sont que des composants.

Merci pour une réponse rapide!

@ 7c78 C'est vrai pour le remontage, même si je pense que les nœuds DOM sont réutilisés lorsque le vDOM se résout dans le même état.

Ce n'est pas quelque chose qui nous préoccupe beaucoup car nous ne pouvons pas non plus utiliser react-router avec relay-modern, nous avons donc dû utiliser ce modèle de toute façon.

@merrywhether je ne suis pas sûr de vDOM car le serveur renvoie un nouveau document / html pour chaque route. Désolé, ignorez cette hypothèse, je ne suis qu'un débutant.

Je reconnais que nous devons de toute façon utiliser ce modèle. Merci!

Vous pouvez utiliser RR avec next.js en plaçant toute votre application dans les pages / index.js, mais vous perdez certains des avantages de la division de code prête à l'emploi et vous devez le configurer vous-même.

J'adorerais si Reach Router était envisagé. Il est très similaire à react-router et apporte des avantages importants:

  • Il résout certains problèmes importants liés à la génération de liens et à la gestion des focus (https://reach.tech/router/accessibility).
  • Il pèse moins (au moment de la rédaction)

Reach Router est également génial 🥇

Les routes dynamiques de style RR sont une API intéressante, mais le routage statique (et analysable statiquement) apporte également de nombreux avantages. Aucune des deux approches n'est gagnante du slam-dunk.

@sorokinvj C'est uniquement pris en charge via un plugin (actuellement) .. https://github.com/fridays/next-routes

Les liens statiques sont si basiques qu'ils ne prennent même pas en charge les paramètres dans les liens ...

J'utilise un package tiers next-routes pour l'instant https://github.com/fridays/next-routes pour le contourner

Envoyé de mon iPhone

Le 24 octobre 2018, à 23 h 01, Andy Ingram [email protected] a écrit:

Les routes dynamiques de style RR sont une API intéressante, mais le routage statique (et analysable statiquement) apporte également de nombreux avantages. Aucune des deux approches n'est gagnante du slam-dunk.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Nous utilisons également next-routes pour le moment, mais je pense que la prochaine équipe travaille sur l'ajout de paramètres de chemin à leur routage de système de fichiers via des noms de fichiers regex (inspirés de Sapper).

@merry si j'utilise également next-routes , mais je préférerais que cela fasse partie du noyau de Next.js.

Vous avez mentionné

Je crois que la prochaine équipe travaille sur l'ajout de paramètres de chemin ...

Je suis curieux de savoir si vous avez des références à ce sujet? Peut-être un problème ouvert pour les paramètres d'itinéraire? Je ne parviens pas à en trouver un ... Peut-être que le plugin résout le besoin et ce sera la solution recommandée à l'avenir.

@curran La source était un tweet de l'un des développeurs de sapper.js, disant que le suivant était de s'inspirer de sapper.js et d'implémenter le routage par nom de fichier regex dans une version future. Bien sûr, Twitter étant ce qu'il est, je n'ai pas pu pour la vie de moi trouver le tweet original.

Ce problème a été soulevé le 5 avril 2017 et est maintenant le 27 février 2019. Presque 2 ans et aucune solution
Peut-être est-il temps de remplacer le routeur intégré à moitié par quelque chose de bien?

Aie. C'est assez insultant pour les développeurs de NextJS qui ont consacré de nombreuses heures à la solution de routage.

J'ai manqué ReactRouter au début. Maintenant, je ne me souviens même plus que NextJS a un routeur différent jusqu'à ce que quelqu'un me le rappelle. Verbose Link API est simple à encapsuler avec des proxies (selon votre architecture de données / API), par exemple. Partage de ce top secret: 😆

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

Je pense que nous devrions tous passer moins de temps à nous plaindre de choses secondaires 😉

@ ivan-kleshnin Nice j'ai ajouté un wrapper similaire

Selon le commentaire précédent, je voudrais pointer vers https://www.contributor-covenant.org/version/1/4/code-of-conduct

J'ai caché ce commentaire.

Je n'ai aucun problème avec next/router pour la plupart des cas d'utilisation.
Mais cela devrait s'améliorer un peu sur la partie universal routing .
En cas de déploiement de Now 2, j'aimerais simplement prendre now.json et l'utiliser pour router dans mon application.

Si vous souhaitez implémenter RR4 dans le projet nextJs, vous devez faire 2 choses:

  1. Empêcher NextJS SSR, en utilisant next/dynamic vous pouvez le faire.
  2. En utilisant HashRouter au lieu de BrowserRouter -> si l'utilisateur recharge la page, le navigateur peut charger la page précédente (pas la page 404)

Si vous souhaitez implémenter RR4 dans le projet nextJs, vous devez faire 2 choses:

  1. Empêcher NextJS SSR, en utilisant next/dynamic vous pouvez le faire.
  2. En utilisant HashRouter au lieu de BrowserRouter -> si l'utilisateur recharge la page, le navigateur peut charger la page précédente (pas la page 404)

Merci pour cette réponse, m'a beaucoup aidé.

@ reach / router et react-router 5 fusionnent: https://reacttraining.com/blog/reach-react-router-future/

Comment cela affecte-t-il next.js?

@ alp82 Puisque Next.js n'utilise toujours pas React Router ou Reach Router, cela n'affectera pas du tout Next.js.

J'ai besoin de la fonctionnalité de commutation de routes dans nextjs pour rendre plusieurs composants de pages dans les pages d'index.
alors comment puis-je implémenter cela dans nextjs ....... ???

Si vous souhaitez implémenter RR4 dans le projet nextJs, vous devez faire 2 choses:

  1. Empêcher NextJS SSR, en utilisant next/dynamic vous pouvez le faire.
  2. En utilisant HashRouter au lieu de BrowserRouter -> si l'utilisateur recharge la page, le navigateur peut charger la page précédente (pas la page 404)

si vous voulez rendre à nouveau votre page précédente sans lancer l'erreur 404, utilisez simplement cette route get dans votre fichier de serveur express.

server.get ('vos paramètres', (req, res) => {
const actualPage = '/ votre_page'
const queryParams = {id: req.params.id}
app.render (req, res, actualPage, queryParams)
})

J'ai documenté une approche pour utiliser next.js avec react-router , en fournissant un fichier de point d'entrée unique au lieu d'un routage basé sur le système de fichiers natif et en préservant entièrement SSR natives .

Je serai heureux de recevoir des commentaires et d'améliorer ce que j'ai fait.

La documentation est disponible en:

À votre santé!

Je déconseillerais fortement d'inclure le React-Router de cette façon car vous vous retrouvez avec un seul point d'entrée, ce qui signifie des builds de développement (extrêmement) plus lents, plus de chances d'envoyer trop de code côté client et moins de visibilité sur les optimisations comme l'exportation statique automatique.

@timneutkens Peut-être que je me trompe. Mais avec le chargement paresseux, la configuration de routage n'est qu'un fichier de configuration. Je ne vois pas que cela affectera l'évolutivité ou les performances ici. J'aimerais en savoir plus à ce sujet.
L'avantage de react-router est que les développeurs ont un contrôle total sur le code.

@timneutkens , je ne commencerai pas une discussion ici mais je vous demanderais de ne pas cacher mon commentaire. J'ai passé du temps à rendre mon travail disponible et à le rendre à la communauté et je ne vois pas comment faire taire les gens pourrait aider au développement open source.

@timneutkens quant aux points que vous mentionnez, c'est une question de compromis. La mienne est une expérience visant à déterminer comment Next.js pourrait être utilisé avec une configuration différente.

Trop de code côté client

Tout bundle moderne peut diviser les actifs du client en morceaux et les routes react-router sont en fait des points de fractionnement très pratiques.

Temps de construction des développeurs plus élevés

C'est un prix à payer pour un gros projet, mais rien ne peut être adressé avec un réglage précis du Webpack.

Pas d'exportations statiques

Je conviens que les exportations statiques sont une couche d'optimisation importante. La plupart des pages servies par une application Next.js moyenne doivent de toute façon récupérer des données dynamiques et ne peuvent pas bénéficier d'exportations statiques.

Les solutions à ce problème ne manquent pas. Par exemple. il peut encore être possible de déclarer manuellement une liste d'itinéraires à exporter statiquement

La raison pour laquelle j'ai caché le commentaire est qu'il s'agit d'un problème de trafic élevé et qu'il ne reflète pas notre recommandation de créer des applications Next.js. Si quelqu'un finit par chercher ici à utiliser react-router, il finira par utiliser aveuglément votre exemple et ne pas étudier comment configurer correctement le routage à l'aide de Next.js.

C'est un prix à payer pour un gros projet, mais rien ne peut être adressé avec un réglage précis du Webpack.

Vous ne pouvez pas accélérer le démarrage au moment du développement en fonction de votre approche, il n'y a pas de réglage précis de la configuration du webpack car webpack se contentera de compiler et de surveiller chaque route que vous importez, ce qui ralentit massivement les modifications apportées aux composants communs. D'où pourquoi Next.js a des entrées à la demande: https://nextjs.org/blog/next-8#improved -on-demand-entries

De plus, il y a une prélecture (automatique) des routes, etc. Il y a des tonnes de détails que je pourrais entrer ici, mais le tldr est que vous vous retrouverez avec une expérience de développeur et une application pires.

Cela ne me dérange pas de masquer le commentaire s'il reflète correctement que la seule fois que vous souhaitez l'utiliser est de migrer une application qui utilise déjà react-router, puis de passer progressivement à plusieurs pages.

Salut @timneutkens
Compteriez-vous certains des avantages que l'analyse statique apporte à la table et qui ne sont pas possibles avec les solutions de routage dynamique?

Quelque chose comme ça https://github.com/jaredpalmer/after.js ?

J'ai lu tous les commentaires et je ne sais toujours pas si RR4 + sera inclus ou facultatif dans la prochaine itération de next.js. La feuille de route d'un routeur ou quelque chose de similaire?

@laurencefass il semble qu'il n'y ait pas de plan pour supporter react-router (à partir d'aujourd'hui).

Pour moi, le système de routage de Next.js est en train de devenir suffisamment mature donc nous n'en avons probablement plus (plus) besoin de toute façon :)

"Pour moi, le système de routage de Next.js est en train de devenir assez mature, donc nous n'en avons probablement plus (plus) besoin de toute façon :)"

Sauf pour ceux qui cherchent à adopter progressivement Next.js dans une base de code existante. Je pense que la discussion la plus utile n'est probablement pas "Routage Next.js vs routage react-router". Je pense que la discussion la plus utile est "Comment puis-je migrer une application énorme en utilisant react-router vers Next.js, de manière incrémentielle?"

Le routeur de Next n'a cependant pas la capacité d'imbriquer des vues d'itinéraire, n'est-ce pas? Chaque navigation vers un itinéraire souffle le DOM et le rafraîchit. Les vues imbriquées sont une exigence assez courante.

@dbbk J'ai entendu dire que l'équipe nextjs y travaillait.

next js est assez flexible avec les routeurs. https://dev.to/toomuchdesign/next-js-react-router-2kl8

Je déplace un site Web des codes JS et jQuery normaux vers React. Contrairement aux anciens codes, je dois empêcher la musique de s'arrêter lors du changement de page, j'ai donc utilisé React Router pour cela.

Maintenant, à des fins de référencement, car j'ai un bon trafic de la recherche Google, je dois le maintenir. Je préférerais donc SSR avec Next.js pour de meilleures performances.

Est-ce que Next.js est capable de rendre une page côté serveur, puis une fois la page chargée côté client, Next.js laisserait la navigation sous le contrôle de React Router, de sorte que si l'utilisateur écoute de la musique, le lien Next.js gagne ' Avez-vous besoin de quitter la page actuelle pour arrêter la musique?

O Next.js peut-il effectuer uniquement le routage côté client?

Si l'intégration de React Router est capable de résoudre ce problème, alors j'y suis. Parce que la lecture de musique continue est un must pour moi une fois que l'application atteint le côté client.

next js est assez flexible avec les routeurs. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , c'est une très bonne approche, je l'ai déjà lu. Et l'article dit que l'équipe Next.js ne le recommande pas, je ne sais pas pourquoi. Mais ça me semble bon

@KeitelDOG vous n'avez pas besoin de

_edit: Je vais juste ajouter ceci: peut-être que le seul avantage de react-router est les routes imbriquées faciles dans la même fonction de vue, le routeur Next.js devrait résoudre 95% de vos cas d'utilisation_

@martpie Merci pour la réponse, c'est ce que j'ai vu hier soir avec le composant Link . Ensuite, Next.js est le mix serveur-client que je voulais.

Et pour un composant contrôlant de manière granulaire ses propres routes imbriquées dynamiquement, je l'aime beaucoup avec React Router. Mais je suis à peu près sûr de pouvoir trouver une solution, car je ne change pas un site Web React en Next.js, mais je prévois et teste plutôt de changer un site Web JS - jQuery en une application React multi pages sans perdre mes avantages SEO sur Google. Donc je pense que je devrais aller avec Next.js

@timneutkens envisage-t-il de supporter cela dans Next.js 10?

@TrejGun merci, ce n'est certainement pas hors sujet.

Avez-vous un plan?
Le next/router est génial, il fournit beaucoup d'aide. Mais nous avons besoin d'un routeur plus professionnel pour faire face aux applications complexes. React-router est un leader dans le domaine des routeurs.
Peut-être peut-il faire référence à after.js .

Oui, ce système basé sur des pages n'est tout simplement pas assez sophistiqué pour gérer des applications complexes basées sur des données qui pourraient bénéficier d'itinéraires imbriqués.

React-router est sur le point de lancer la version v6 , qui sera le meilleur routeur à ce jour. J'ai hâte de le soutenir next.js .

Une meilleure approche consiste à séparer next.js et router , permettant aux gens de choisir librement leur router préféré.

+1 pour le commentaire précédent. next.js est incroyable, la seule raison pour laquelle je ne l'utilise pas est le manque de flexibilité sur le routeur. Veuillez prendre en charge React Router 6 dans les versions futures ou rendre le routeur permutable.

Les gens vraiment passionnés par React Router pourraient être intéressés à suivre le nouveau projet «Remix», c'est une alternative Next.js qui utilise React Router, par les mêmes créateurs:

Je pense que le problème est que le cadre est profondément lié à ce routeur à cause du SSR, des accessoires côté serveur, etc.

Next est construit avec les performances à l'esprit, et le react-router côté serveur a une implication majeure sur les performances en ce sens que vous devez parcourir l'arborescence DOM avant de savoir ce que vous allez essayer de rendre, et donc de quelles données vous aurez besoin. Le but de getInitialProps est de ne pas avoir à faire un rendu jetable de react avant de récupérer des données, un piège courant que beaucoup de frameworks rencontrent sur le serveur (et dans le client, où il se manifeste comme demande des cascades). Next pourrait potentiellement contourner ce problème en demandant à chaque page de niveau supérieur de déclarer _tous_ les différents modèles de données dont les différents sous-composants pourraient avoir besoin et de créer une branche sur le chemin complet de la requête (ou de faire une surexploration unique massive), mais cela deviendrait rapidement difficile à manier et ne serait pas vraiment si différent de déclarer chaque page individuellement.

C'est la même raison pour laquelle Relay n'est pas non plus compatible avec react-router, et vous ne pouvez pas accuser facebook.com de ne pas être un site Web complexe.

La principale stratégie réussie pour travailler avec le routeur Next est de s'appuyer sur la composabilité (qui est de toute façon la tendance dominante dans React moderne), vous permettant de réutiliser des composants sans duplication majeure tout en ayant un SSR efficace capable de récupérer toutes ses données. (via getInitialProps ) avant de parler au moteur de rendu React.

J'ai l'impression que la pénalité de performance de marcher dans l'arbre est exagérée. De nombreuses applications de production font aujourd'hui cela avec par exemple Apollo et cela semble être très bien.

De plus, vous pouvez également mettre en cache CDN vos réponses si vous voulez vraiment éviter que le serveur fasse trop de travail.

Bien sûr, je souligne simplement le raisonnement principal qui explique pourquoi react-router est (AFAICT) fondamentalement incompatible avec Next dans son implémentation actuelle. De nombreux sites n'ont pas vraiment besoin de performances, comme en témoignent les gens qui utilisent joyeusement des dynos Heroku gratuits avec des temps de démarrage à froid lents (et je tiens à souligner que je ne dis pas cela avec condescendance car je le fais aussi pour certains sites et cela peut être la solution idéale). Mais Next ne serait pas populaire auprès de certaines des plus grandes entreprises qui l'utilisent s'il était moins agressif en termes de performances, car ces entreprises se soucieraient que les temps de réponse de leurs serveurs soient sensiblement plus lents. Si ce n'était pas un problème pour certains sites, les gens n'utiliseraient pas (et attendaient avec impatience des améliorations) le moteur de rendu en continu de React pour commencer à répondre avant même qu'un seul rendu ne soit terminé, encore moins deux.

Vous pouvez certainement mettre en cache CDN vos réponses, mais cela élimine de nombreuses options de personnalisation / connexion (car il s'agit d'un compromis avec le niveau auquel vous souhaitez réduire votre taux de réussite ou reporter le rendu partiel de la page au client). Si vous pouvez mettre en cache CDN toute votre application, vous feriez peut-être mieux d'utiliser CRA et react-snapshot et d'éviter complètement les serveurs. Ce n'est pas nécessairement une question de la quantité de travail de votre serveur, mais plutôt du temps qu'il faut pour répondre à une demande.

Et Apollo est un excellent exemple de cadre qui met l'accent sur la facilité d'utilisation plutôt que sur les performances, par rapport à un cadre plus avisé / axé sur les performances comme Relay. C'est tout un spectre.

Ouais, je suppose que c'est assez juste. Mais je suis curieux de voir comment remix.run se révèle, peut-être qu'ils trouveront une nouvelle approche pour le faire fonctionner avec react-router . Oui, il est vrai que les itinéraires imbriqués ne sont pas obligatoires, mais vous devez sûrement convenir qu'il est plus intuitif de modifier certaines parties de l'interface utilisateur interne avec l'itinéraire que d'avoir des pages différentes et d'envelopper chacune de ces pages avec des mises en page différentes.

À partir du 9.3 suivant, il y a getStaticPaths en plus de getServerSideProps pour aider le framework à découvrir les chemins à pré-rendre lorsque le chemin a des paramètres d'itinéraire. Peut-être qu'une approche similaire pourrait être adoptée avec react-router.

@merryweather : "Next est construit avec les performances à l'esprit, et le

Question naïve: pouvez-vous simplement restituer les liens de niveau supérieur et récupérer / pré-lire / mettre en cache une fois le code exécuté sur le client. Si vous ne savez pas où le client va naviguer, est-il judicieux de parcourir l'arborescence DOM sur le serveur?

Scénario de travail naïf: lorsque le client demande une URL, il suffit de restituer les liens de niveau supérieur et le contenu du lien actif par défaut et ajax / récupérer tout le reste sur demande (ou une prélecture en arrière-plan une fois que la page est chargée) ... tout le reste inclut tous les niveaux inférieurs itinéraires ... rincer et répéter ...?

@laurencefass mais même les liens de niveau supérieur sont dans le code et doivent être découverts, n'est-ce pas? Ou voulez-vous utiliser le routage du système de fichiers aux côtés de react-router afin que les liens de niveau supérieur soient détectables?

@ avin-kavish Je ne suis pas la meilleure personne pour répondre aux détails de la mise en œuvre, mais le client n'a besoin que de rendre le contenu de l'écran initial: liens de niveau supérieur + contenu par défaut. Tout le reste est redondant lors du premier chargement, je pense. Alors pourquoi marcher le DOM sur le serveur?

Le principal problème avec Next.js n'est pas le routeur, c'est le modèle de récupération de données avec getInitialProps , getServerProps ou getStaticProps . Pourquoi ? Parce qu'il rompt l'isolation des données pour le composant qui en a besoin. Par exemple, vous souhaitez obtenir des données pour le menu, d'où allez-vous les récupérer? Je ne sais pas. Les principaux composants comme pages ne devraient rien savoir à ce sujet, non?

Le principal problème avec Next.js n'est pas le routeur, c'est le modèle de récupération de données avec getInitialProps , getServerProps ou getStaticProps . Pourquoi ? Parce qu'il rompt l'isolation des données pour le composant qui en a besoin. Par exemple, vous souhaitez obtenir des données pour le menu, d'où allez-vous les récupérer? Je ne sais pas. Les principaux composants comme pages ne devraient rien savoir à ce sujet, non?

Pourriez-vous élaborer s'il vous plaît. Et quelle est la solution alternative?

@lishine Je suis désolé pour un peu hors sujet ici, mais dans la plupart des cas, je ne vois pas que le routeur est le principal problème ici. Le routeur Next.js est bon, déclaratif, la convention de configuration est bonne. La seule chose que je ne peux pas utiliser dans Next.js, ce sont les méthodes de récupération de données comme getInitialProps , ...
Dans mes applications, chaque composant devra déclarer ses propres données au même endroit, dans le même fichier, quel que soit le graphql ou le repos.
Le composant Top pages sert uniquement à composer des composants enfants et la récupération de données n'est pas son travail. Le composant enfant doit obtenir des données sur lui-même, pas sur ses parents.

Voici mon exemple de code que j'utilise pour mon application pour plus de clarté:

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

Comme vous le voyez, vous avez un composant avec ses propres données. Vous pouvez le mettre où vous voulez.

Bien sûr, vous pouvez utiliser le modèle Next.js sans aucun problème, mais dans mon cas, je préfère autant que possible l'isolation des données et des composants pour faciliter la maintenance et la refactorisation plus tard.

Dans mes applications, chaque composant devra déclarer ses propres données au même endroit, dans le même fichier, quel que soit le graphql ou le repos.
Le composant Top pages sert uniquement à composer des composants enfants et la récupération de données n'est pas son travail. Le composant enfant doit obtenir des données sur lui-même, pas sur ses parents.

Je l'utilise de la même manière.
Vous n'utilisez donc pas la récupération SSR ...
Alors comment les gens font-ils la récupération SSR avec Next.js?!

@linshine nous devons télécharger tout ce dont nous avons besoin au niveau supérieur de la page.

@lishine Je suis désolé pour un peu hors sujet ici, mais dans la plupart des cas, je ne vois pas que le routeur est le principal problème ici. Le routeur Next.js est bon, déclaratif, la convention de configuration est bonne. La seule chose que je ne peux pas utiliser dans Next.js, ce sont les méthodes de récupération de données comme getInitialProps , ...
Dans mes applications, chaque composant devra déclarer ses propres données au même endroit, dans le même fichier, quel que soit le graphql ou le repos.
Le composant Top pages sert uniquement à composer des composants enfants et la récupération de données n'est pas son travail. Le composant enfant doit obtenir des données sur lui-même, pas sur ses parents.

Voici mon exemple de code que j'utilise pour mon application pour plus de clarté:

...

Comme vous le voyez, vous avez un composant avec ses propres données. Vous pouvez le mettre où vous voulez.

Bien sûr, vous pouvez utiliser le modèle Next.js sans aucun problème, mais dans mon cas, je préfère autant que possible l'isolation des données et des composants pour faciliter la maintenance et la refactorisation plus tard.

@ revskill10 Pourquoi ne pouvez-vous pas demander à l'enfant de déclarer son fragment de données et que le parent l'inclue ensuite dans la requête de niveau supérieur? Surtout lorsque vous créez plus de fragments associés aux enfants, vous obtenez une isolation parfaite des données. Avoir une requête parent avec un fragment enfant n'est pas différent de la déclaration de cet enfant dans JSX, vous avez donc le même niveau de couplage mais évitez les chutes d'eau de requête (beaucoup plus difficiles dans REST, malheureusement).

Nous avons une application Relay-Next et ce modèle fonctionne parfaitement, avec l'encapsulation des données et la composition réutilisable, et nous exploitons facilement getInitialProps .

@merrywhether Sans parler du much harder in REST , votre approche pose un problème en ce sens que vous ne pouvez pas décider quel fragments sera SSG / SSR ou CSR.
Dans mon approche, c'est aussi simple que d'importer ce composant avec { noSSR: true/false} .

Je trouve que le verrouillage d'une bibliothèque de routage spécifique au fournisseur qui ne partage pas une implémentation sous-jacente avec une bibliothèque de routage majeure est extrêmement préoccupant.

J'ai récemment examiné Next.js pour évaluer s'il devait être utilisé comme base pour le noyau commun partagé entre un certain nombre d'applications frontales en cours de construction pour notre client actuel. Alors que Next.js a du potentiel; ce routeur est l'une des principales raisons pour lesquelles j'ai fini par rejeter Next.js et à la place garder CRA comme base pour ces applications.

Je comprends la difficulté d'utiliser l'API de premier niveau basée sur les composants de react-router / @reach/router comme base pour SSR. Mais ce n'est pas une bonne raison pour que l'implémentation sous-jacente soit entièrement personnalisée. Le SSG de Gatsby a les mêmes préoccupations que Next.js et une structure de routage basée sur des fichiers semi-similaire; mais à ma connaissance, Gatsby utilise @reach/router sous le capot pour alimenter son implémentation de routage au lieu de réinventer la roue ou d'exposer une API Link qui est incongrue avec l'API Link utilisée par d'autres bibliothèques.

@dantman puis-je demander ce que vous avez choisi pour l'alternative Next.js. En supposant que vous ayez besoin d'un rendu côté serveur ... J'ai essayé After.js, peut-être que cela peut fournir une inspiration / des idées sur la façon de l'implémenter dans Next.js s'il n'est pas pris en charge par Zeit.

@dantman puis-je demander ce que vous avez choisi pour l'alternative Next.js. En supposant que vous ayez besoin d'un rendu côté serveur ... J'ai essayé After.js, peut-être que cela peut fournir une inspiration / des idées sur la façon de l'implémenter dans Next.js s'il n'est pas pris en charge par Zeit.

Désolé, je n'ai pas de réponse utile pour vous. La SSR n'était pas une exigence absolue, nous avons donc continué à utiliser CRA, avec lequel le prototype a été construit.

Je pensais que Next.js était prometteur en tant que cadre universel car il avait récemment acquis la possibilité d'avoir un mélange de pages SSR / SSG / client uniquement et pouvait fonctionner comme une application isomorphe ou comme une application statique / PWA. La personnalisation de WebPack était tentante parce que l'ARC a rendu l'utilisation de globalize-compiler difficile. Le serveur Next.js était neutre / positif car nous avions de toute façon besoin d'un serveur API pour un pont GraphQL / REST. Et l'option SSR / SSG était positive puisque je construis le noyau sur lequel une demi-douzaine d'applications seront basées et ce n'est pas impossible que cela puisse devenir utile à l'avenir. Cependant, j'ai également eu des problèmes avec le fonctionnement du SSR de Next.js et ces points positifs ne valaient pas le problème causé par le routeur.

@dantman

Je trouve que le verrouillage d'une bibliothèque de routage spécifique au fournisseur qui ne partage pas une implémentation sous-jacente avec une bibliothèque de routage majeure est extrêmement préoccupant.

Il est assez étrange de qualifier un composant open source avec une API qui n'a pas changé depuis 3 ans en raison de sa grande stabilité et de son «ajustement produit / marché» comme «verrouillage»

Next.js a réussi et continue de montrer sa croissance grâce à son routeur et non malgré lui.

Comme beaucoup m'ont vu commenter sur Twitter, une fois, nous avons sérieusement envisagé de fusionner un routeur (bien que je ne sois pas certain de savoir lequel est le standard dans votre esprit, Reach ou React Router, et à quelle version principale). Mais le monde nous a entraînés dans d'autres directions intéressantes. En réalité, nous ne savions même pas à quoi bon l'ajouter, car tout le monde réussissait avec Next.js et construisait de merveilleux produits.

Lorsque je demandais aux gens pourquoi ils voulaient une API de routeur différente, la raison qui revenait le plus souvent était que les gens étaient bloqués et frustrés par les solutions de cadre développées à domicile construites sur un routeur, et ils avaient hâte de migrer vers Next . Ce n'était pas une raison enracinée dans la conception du produit.

Quand je dis que Next a réussi grâce à son routeur, c'est parce qu'il a éliminé deux problèmes:
1️⃣ L'idée de devoir choisir un routeur . Nous retirer cela est rétrospectivement une excellente décision. Depuis que Next.js a existé avec son routeur stable, le monde des routeurs s'est séparé et a lancé toutes sortes de changements d'API

2️⃣ La courbe d'apprentissage d'un routeur . De nombreux ateliers et tutoriels ont été donnés sur le routage, mais le routage du système de fichiers Next.js prend 2 secondes d'explication et vous donne la plate-forme pour créer des choses incroyables, et vous passez directement au développement de produit

Je tiens à souligner ce dernier point. Considérez l'un des sites Web les plus récents et les plus dynamiques au monde, TikTok.com, construit sur Next.js. La topologie de routage entière de ce site Web peut être expliquée avec cette courbe d'apprentissage de deux secondes. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 est pages/[user]/video/[id].js et https://www.tiktok.com/trending est pages/trending.js

Beaucoup des récentes innovations Next.js que vous mentionnez comme vous aimez, comme les hybrides statiques / SSG / SSR, sont également activées par la conception de notre routeur. En fait, le routeur permettra également de nombreuses autres optimisations similaires à venir pour fournir moins de JS aux clients.

Cependant, j'ai également eu des problèmes avec le fonctionnement du SSR de Next.js et ces points positifs ne valaient pas le problème causé par le routeur.

J'adorerais en entendre parler. L'exemple ci-dessus est alimenté par Next.js hybride statique / SSR et nous voyons beaucoup de succès avec lui dans tous les domaines!

C'est un fil tellement drôle. Next a des raisons concrètes d'éviter le routage en cascade (aka react-router et amis) car getInitialProps permet de nombreuses optimisations de performances, et l'approche de Next s'avère très populaire, d'autant plus que certaines personnes veulent spécifiquement ces optimisations. La performance vient avec des compromis de conception, et parfois vous préférerez peut-être choisir la conception plutôt que la performance, mais cela ne rend pas l'outil faux, tout simplement faux pour vous pour un projet spécifique.

En fin de compte, react-router n'est pas la solution de routage ultime. Il a ses avantages et ses inconvénients, tout comme Next. FWIW, Facebook n'utilise pas de React-router, et ils savent probablement une chose ou deux sur l'utilisation de React. C'est donc bien d'avoir des alternatives, et en fait l'une des grandes choses à propos de l'écosystème JS: laisser différentes choses rivaliser dans l'arène des idées et finalement nous allons tous de l'avant.

Puisque je ferme le problème, je tiens à préciser que nous sommes toujours ouverts aux commentaires, demandes de fonctionnalités et rapports de bogues sur les capacités de routage.

Idéalement, ceux-ci seraient axés sur le produit («Je dois faire X mais ce n'est pas possible» ou «Y est possible mais pas ergonomique»). Nous sommes toujours à la recherche d'améliorations qui vous aideront à créer des sites Web et des applications allégés avec une expérience utilisateur exceptionnelle 🤗

@rauchg Pouvez-vous expliquer la raison d'avoir deux accessoires, href et as vers un lien? Pourquoi ne peut-il pas déduire la page voulue en fonction de la valeur de la as ?

Par exemple, dans express, si j'ai un itinéraire comme /blog/:slug , je peux simplement envoyer une requête http à /blog/hello-world et m'attendre à ce que le routeur l'achemine. Je n'ai pas besoin d'envoyer à la fois /blog/:slug et blog/hello-world au serveur.

@ avin-kavish c'est une excellente question. Il y a une distinction importante à faire entre ce que l'URL affiche et quelle page doit être chargée. En fait, TikTok utilise cela pour rendre certaines choses en modaux, qui lorsque vous actualisez la page deviennent d'autres pages. Cependant, une grande amélioration ici est que nous devrions peut-être imposer statiquement que vous référencez une page valide qui existe dans le système de fichiers. Nous allons suivre en créant une discussion à ce sujet et vous taguer!

Je pense qu'un problème existe déjà pour cela https://github.com/zeit/next.js/issues/8207

Dans le cas où quelqu'un regardait ce problème pour une fonction de réaction-routeur comme "routes imbriquées" qui permet de naviguer vers de nouvelles pages sans tout refaire le rendu comme je l'étais, il y a en fait un problème dédié que vous pouvez regarder et voter. Je viens de découvrir celui-là: https://github.com/zeit/next.js/issues/8193

@rauchg

Pour être clair, mon problème principal n'est pas le manque d'API de composant de style RR / reach, je suis d'accord avec une API basée sur Bien que je sois un peu optimiste, Suspense pourrait à l'avenir rendre viables d'autres API SSR / routage. Mon principal problème est que le routeur est complètement personnalisé et que toutes les préoccupations communes concernant la mise en œuvre sont réimplémentées au lieu d'être partagées avec une partie de la communauté React plus large.

Je trouve l'approche de Gatsby acceptable. Ils ont un fichier compatible SSG + une API de routage basée sur la configuration et exportent leur propre composant Link amélioré; mais ils utilisent @reach/router pour alimenter l'implémentation sous-jacente.

Je trouve que le verrouillage d'une bibliothèque de routage spécifique au fournisseur qui ne partage pas une implémentation sous-jacente avec une bibliothèque de routage majeure est extrêmement préoccupant.

Il est assez étrange de qualifier un composant open source avec une API qui n'a pas changé depuis 3 ans en raison de sa grande stabilité et de son «ajustement produit / marché» comme «verrouillage»

Le routeur est intrinsèquement lié à Next.js. Adopter Next.js pour une raison signifie être lié au routeur. Si nous adoptons Next.js et découvrons plus tard que next / router a une limitation qui s'avère paralysante pour quelque chose que nous essayons de faire, il n'y a absolument aucune trappe de fuite raisonnable. "Lock-in" est un descripteur parfaitement fin pour cela.

Le verrouillage à lui seul ne serait pas un problème majeur. L'utilisation par Gatsby de @reach/router serait également verrouillée. Mais @reach/router est utilisé en dehors de Gatsby uniquement. Je n'ai pas à faire confiance à la communauté Gatsby seule pour maintenir la pile de routeurs entière; Je peux avoir confiance qu'une communauté plus large en dépend et qu'il y a plus de parties prenantes impliquées (spécifiques à la pile de routage) pour assurer sa maintenance, suivre les problèmes de routage difficiles (par exemple, l'accessibilité) et dépend d'une communauté plus large et plus variée partagera probablement tous les problèmes potentiellement paralysants que nous pourrions rencontrer à l'avenir.

bien que je ne sache pas quelle est la norme dans votre esprit, Reach ou React Router, et à quelle version principale

En termes de norme de facto de ce <Link> quoi <Link to='/about'>About</Link> est valable à la fois dans RR et Reach (et bien sûr par extension Gatsby). Ce qui rend l'idiosyncratique <Link href='/about'><a>About</a></Link> Next.js tellement plus discordant.

En termes de ce que je pense que Next.js devrait utiliser. Je ne suis pas lié à une bibliothèque spécifique, si Next.js en utilisait déjà une, je ne suggérerais pas de passer à une autre. Ma principale préoccupation est que l'implémentation du routage soit partagée avec une bibliothèque avec une communauté plus large en dehors de Next.js.

En pratique, c'est relativement théorique. Comme jusqu'à présent, je n'ai vu aucun routeur React en plus de RR et Reach avec une grande base d'utilisateurs. Et RR et Reach vont devenir une seule bibliothèque, donc celui que vous commenciez avec le résultat final sera le même.

J'ai essayé Next il y a quelque temps mais le manque de flexibilité sur le routeur m'a amené à découvrir une implémentation Razzle appelée After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com.

Comme React Router n'est qu'un package, ne pouvons-nous pas l'importer et limiter le rendu uniquement côté client pour qu'il fonctionne comme un SPA là où c'est nécessaire et nous donne des routes de composants imbriqués? Le routeur React n'est-il pas juste un ensemble de composants à intégrer (potentiellement) dans les pages et à charger avec le routeur de page Next.js comme tout autre composant?

J'ai lu dans les discussions précédentes que Zeit envisage d'intégrer RR est-ce toujours vrai aujourd'hui?

Pourquoi n'autorisons-nous pas les routes imbriquées dans le routeur next.js en dernier recours et expliquons clairement que ces zones ne seront pas pré-rendues. À tout le moins, cela nous évitera de devoir éviter d'écrire les conditions if que nous devons inévitablement écrire lorsque nous voulons qu'une sous-ressource de la page change en fonction de l'itinéraire.

J'ajoute mon vote sur cette question.

Un autre avantage, non mentionné, est que RR est plus testable (AFAIK, il n'y a pas d'API nextjs officielle pour les tests de routeur), il a MemoryRouter pour emballer les tests et les histoires.

Next. pour SSR et SSG même si l'API n'est pas géniale. Mais alors que le système de routage intégré et SSR / SSG fonctionne pour certains; pour d'autres, ils entravent le développement parce que les limites des deux API offrent les mauvais compromis pour ledit projet.

Que diriez-vous d'un compromis. Next.js a déjà des plugins. Au lieu de remplacer le routeur en interne, que se passerait-il si nous séparions le routeur et l'API SSR (c'est-à-dire le getStaticProps / getServerSideProps dans les fichiers de route) du noyau de Next.js. Par exemple, nous pourrions mettre les parties fondamentales très fondamentales dans @next/core et déplacer le routeur actuel et les API get*Props vers @next/router . Pour plus de simplicité et de rétrocompatibilité, next pourrait être un framework qui réexporte @next/core et est pré-configuré avec le routeur préféré de Vercel. Mais alors, il serait possible pour la communauté de développer des routeurs et des API SSR / SSG avec différents compromis qui sont mieux adaptés aux projets qui autrement seraient bloqués à jeter les bonnes parties de Next.js avec l'eau du bain.

Quelques réflexions sur ce que le noyau Next.js exigerait que le plugin du routeur fournisse:

  • Étant donné une requête {url, body, etc}, le noyau s'attend à ce que le plugin du routeur rende cette requête dans un document (chaîne ou flux) ou lance une réponse (c'est-à-dire 404 ou redirection).
  • Lors de l'exportation, le noyau s'attend à ce que le plug-in du routeur fournisse une liste de pages à rendre.

@next/router implémenterait probablement les mêmes modèles via l'API en faisant des choses comme:

  • Compte tenu d'une demande, identification du fichier de route responsable et rendu normal
  • Sur le client faisant quelque chose de similaire à ce qu'il fait actuellement pour savoir quand appeler l'API SSR et rendre la route dont il a besoin (éventuellement en déplaçant l'API SSR basée sur l'API vers une route d'API d'apparence normale)
  • Lors de l'exportation en utilisant l'arborescence des fichiers de pages et getStaticPaths pour fournir la liste des pages statiques

Je pourrais probablement me voir expérimenter un plugin de routeur en utilisant React Router v6 avec @apollo/react-ssr et Suspense avec react-ssr-prepass ou react@experimental . Qui renonce aux routes SSR uniquement pour les routes SSR isomorphes et implémente SSR / SSG sans une API de style get*Props restrictive.

Ce que j'ai réalisé, c'est que le routage imbriqué + SSG est réalisable sans casser l'API actuelle. Nous avons donc getStaticPaths pour le moment, nous pouvons l'utiliser pour indiquer des routes imbriquées pour le pré-rendu. Par exemple,

Étant donné un itinéraire /foo/[...slug] ,

function FooPage() {

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

peut être pré-rendu avec,

export async function getStaticPaths() {

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

Dans l'état actuel des choses, next.js est comme un framework côté serveur avec la commodité de créer des pages en réaction. Cela ne semble pas aussi puissant que react-router . Le routage basé sur un répertoire peut avoir sa place dans la création de sites destinés aux consommateurs comme tiktok, comme mentionné précédemment, mais pour les portails d'applications complexes basés sur les données, le routage imbriqué est toujours roi. C'est pourquoi des applications à une seule page ont été créées en premier lieu, cela permet de changer des bits de l'interface utilisateur sans avoir à remplacer la page entière. Cela peut être mis à profit pour modéliser les relations ressources-sous-ressources assez facilement. Dans l'état actuel des choses, je peux utiliser next.js si je devais créer les pages publiques d'un site grand public comme un site de commerce électronique, mais lorsque j'ai besoin de créer des zones privées telles que les portails d'administration, d'acheteur et de vendeur, je le ferais passer à l'ARC.

@ avin-kavish le principal problème n'est pas de le faire fonctionner, mais de le rendre optimisé: chaque page sur Next.js par défaut a son propre bundle et est optimisée pour la vitesse.

Si vous commencez à ajouter beaucoup de contenu / sous-contenu dans une seule page comme vous l'avez fait, vous pourriez vous retrouver avec un paquet assez gros à la fin (ce qui n'est pas "terrible" en soi, mais vous devez simplement être conscient du compromis). Vous pourrez peut-être faire une optimisation manuelle avec next/dynamic pensé :)

@rauchg la seule dimension n'est pas de savoir si le prochain routeur est bon ou mauvais. Une autre chose très importante est la migration vers et depuis next.js et le support de la communauté, et https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 le dit bien. Next.js est une si bonne solution pour résumer une grande partie des besoins standard d'une application SSR de haute qualité, et en tant que telle, c'est une cible de migration très attrayante pour de nombreuses applications Web. Le problème à l'heure actuelle est qu'il faudrait une réécriture complète du routage à la fois pour migrer vers next.js et pour en sortir si le besoin s'en fait sentir.

Le routage enfichable suggéré par @dantman plus tôt résoudrait ce problème de manière très élégante et n'obligerait personne à vendre ses principes 😉

Le problème avec react-router (et toute solution de routage imbriquée) est qu'il rend l'analyse statique beaucoup plus difficile car les chemins de code pertinents pour une URL spécifique ne sont pas disponibles sans exécuter (ou simuler) le code lui-même. Ensuite, il y a plus qu'un simple cadre "mettre l'interface utilisateur sur une page Web", c'est pourquoi, par exemple, ils ont travaillé avec l'équipe Chrome pour créer des stratégies de regroupement plus optimisées.

Les utilisateurs de react-router sont habitués à utiliser directement react-loadable car il délègue entièrement cette responsabilité aux utilisateurs finaux, mais Next essaie d'abstraire et d'automatiser ce qui n'est pas facile. L'approche de routeur enfichable proposée devrait probablement impliquer des plugins de routeur fournissant des informations détaillées sur le temps de construction au cadre afin d'obtenir le même type de sortie, car chaque routeur devrait savoir comment générer de telles informations en fonction de ses propres modèles.

Purement spéculation, mais j'imagine que beaucoup de choses sont dans les limbes pendant que React termine Suspense, car en faire un modèle de première classe dans la bibliothèque affectera grandement toutes les bibliothèques de routeurs et donnera également une base concrète sur laquelle construire async / chargeable modèles de bundle.

Longue histoire courte / un bon résumé de ce qui suit: Il n'existe pas de solution «universelle». Tout a des compromis. Chaque "avantage" de la façon dont Next.js fait actuellement les choses a un inconvénient. Les avantages / inconvénients les plus importants sont quelque chose de différent pour chaque projet. Par conséquent, la recommandation pour une architecture routeur / ssg / ssr enfichable. Différents projets nécessitent des choses différentes et pour le moment Next.js ne fonctionne que pour les projets dont la priorité sur les compromis s'aligne sur la façon dont les choses sont codées en dur dans Next.js.

Le problème avec react-router (et toute solution de routage imbriquée) est qu'il rend l'analyse statique beaucoup plus difficile car les chemins de code pertinents pour une URL spécifique ne sont pas disponibles sans exécuter (ou simuler) le code lui-même.

Honnêtement, cela n'a d'importance que si vous utilisez SSG et que vous avez un tas d'itinéraires non dynamiques. Si tous vos itinéraires sont SSG ou client uniquement, cela n'est pas utile. Et si la plupart de vos itinéraires sont dynamiques, vous devez de toute façon les déclarer explicitement en utilisant getStaticPaths . Ce qui serait la même quantité de travail que la définition explicite des routes dans un plugin hypothétique Next.js qui utilise simplement un react-router brut sans modification et vous demande de définir explicitement les routes statiques.

C'est un avantage certain, et certaines équipes le voudront. Cependant, ce n'est qu'un sous-groupe d'utilisateurs potentiels de Next.js. Il existe d'autres groupes qui peuvent souhaiter certains des avantages fournis par RR ou une autre bibliothèque de routage et la nécessité de déclarer explicitement des routes statiques est un compromis acceptable ou un non-problème. Par exemple, mes derniers projets ont été le genre d'applications B2B / B2C où 100% des choses se trouvent derrière une page de connexion et il n'y a aucun intérêt à en restituer statiquement. Next.js présente certains avantages par rapport à CRA qui auraient rendu Next.js préférable; Mais des choses comme le routeur étaient de gros drapeaux rouges et nous avons continué à utiliser CRA. Ces projets auraient été très bien adaptés à un Next.js avec un react-router brut.

Cela suppose également que tous ceux qui ne veulent pas de next/router veulent utiliser la forme JSX de react-router. Ce n'est pas le seul type d'alternative next/router .

Un autre type de routeur serait le style Gatsby.js. Où un projet utilise toujours une structure de pages basée sur un système de fichiers, mais que les éléments internes sont implémentés avec une autre bibliothèque de routage comme react-router (Gatsby utilise @reach/router interne). Ce type de plug-in de routeur vous offrirait les mêmes avantages d'analyse statique. Mais cela vous donnerait également tous les avantages que le routeur alternatif n'a pas liés au routage imbriqué. Par exemple, prendre en compte les préférences potentielles pour l'API d'itinéraire, une meilleure gestion de l'accessibilité, une meilleure intégration dans l'écosystème autour de ce routeur.

Et bien sûr, même dans l'écosystème react-router, le formulaire JSX n'est pas le seul moyen d'utiliser react-router. Il existe également react-router-config . Ce qui est facile à faire une analyse statique et prend également en charge le routage imbriqué.

Les utilisateurs de react-router sont habitués à utiliser directement react-loadable car il délègue entièrement cette responsabilité aux utilisateurs finaux, mais Next essaie d'abstraire et d'automatiser ce qui n'est pas facile.

Et certains d'entre nous acceptent de gérer eux-mêmes le fractionnement de code. Le routage imbriqué peut être plus important pour un projet que le fractionnement automatique du code. Tout dépend des compromis les mieux adaptés à un projet.

C'est plus une note latérale, mais je suis en fait curieux de connaître le potentiel d'un plugin babel / webpack qui le ferait automatiquement pour les routes.

React-loadable est également une bibliothèque effectivement obsolète (2 ans depuis la publication, n'acceptant pas les rapports de bogue). Personnellement, je préférerais faire manuellement le fractionnement de code avec @loadable/components plutôt que d'utiliser quelque chose d'automatique intégré à Next.js basé sur un fork interne de react-loadable.

L'approche de routeur enfichable proposée devrait probablement impliquer des plugins de routeur fournissant des informations détaillées sur le temps de construction au cadre afin d'obtenir le même type de sortie, car chaque routeur devrait savoir comment générer de telles informations en fonction de ses propres modèles.

Ouaip. C'est généralement ainsi que fonctionnerait un système de plugins. Honnêtement, le fait que ce type d'informations puisse être fourni par le plugin est un avantage, pas un problème. Avoir cela dans un plugin signifie que si la façon dont Next.js rassemble ces informations ne convient pas aux besoins de certains types de projets, elle peut être remplacée par une autre qui répond aux besoins de ces projets. Mais sans avoir besoin de bifurquer et de réécrire tout Next.js pour le faire.

Purement spéculation, mais j'imagine que beaucoup de choses sont dans les limbes pendant que React termine Suspense, car en faire un modèle de première classe dans la bibliothèque affectera grandement toutes les bibliothèques de routeurs et donnera également une base concrète sur laquelle construire async / chargeable modèles de bundle.

Cela en soi pourrait en fait un très bon argument pour travailler sur un système de routeur enfichable. À l'heure actuelle, étant donné que tout le routage et le SSR sont codés en dur dans Next.js, il n'est pas possible de faire facilement l'expérimentation dans n'importe quel type de futur système de routage dans Next.js. Comment Suspense affecte-t-il le routage de Next.js et les autres bibliothèques de routage? Ce n'est pas quelque chose que vous pouvez expérimenter (du moins en ce qui concerne le SSR et le regroupement de Next.js) sans bifurquer et réécrire des morceaux de Next.js.

Les plugins de routeur seraient un excellent endroit pour faire ce genre d'expérimentation. Tant que l'API du plugin est suffisamment bas niveau, il serait possible de ne bifurquer que le plugin next/router et d'essayer d'écrire une version react @ experimental + Suspense de ce routeur. Et comme il s'agit d'un plugin (pas un fork de tout Next.js), il serait facile de participer à l'expérience et de tester le nouveau routeur basé sur Suspense. C'est important maintenant plutôt que plus tard, car ce type d'expérimentation est la raison pour laquelle react @ experimental existe, pour recueillir les commentaires de projets réels.

@dantman Je ne suis pas en désaccord avec tout ce que vous avez dit. Il est tout au sujet des compromis. Le plus gros compromis est sur quoi l'équipe Next passe son temps. Jusqu'à présent, le SSR hautes performances à faible configuration semble avoir été leur objectif principal. Je comprends que ce n'est pas nécessairement pertinent pour tous les utilisateurs, mais c'est l'angle que Next a initialement utilisé pour se démarquer (c'est pourquoi nous les choisissons au travail). Ils ont récemment creusé davantage dans SSG, apparemment en raison de la popularité de Gatsby et Jamstack, mais ils sont toujours les meilleurs pour SSR imo.

Honnêtement, cela n'a d'importance que si vous utilisez SSG et que vous avez un tas d'itinéraires non dynamiques

Je ne suis pas sûr de ce que vous entendez par là, car SSG vs SSR n'a pas vraiment d'importance pour essayer de fournir la plus petite charge utile JS possible pour la première page ("chemin critique" JS), pas plus que les routes dynamiques. Minimiser les ressources du chemin critique _est_ généralement assez important pour les applications SSR (donc tous les efforts), donc cela est apprécié. Et honnêtement, si vous ne faites que des applications CSR sécurisées par connexion, alors Next _does_ a beaucoup d'inconvénients par rapport à CRA (SSR ne sera jamais aussi pratique que CSR). On dirait que vous évitez les applications qui font réellement SSR d'exécution (avec la gestion côté serveur de la connexion / personnalisation) spécifiquement pour les gains de performance. Tout ne rentre pas dans la dichotomie SSG vs CSR.

certains d'entre nous acceptent de gérer eux-mêmes la division du code

Certains d'entre nous sont tout à fait capables de gérer nous-mêmes webpack, react-dom / serveur, etc. Jusqu'à présent, l'objectif de Next semble être de rendre cette éjection de plus en plus rare, tout comme le CRA. Et vous avez raison, j'aurais dû dire réactif chargeable, car il y a beaucoup de solutions dans cet espace, et elles ne font que devenir plus exotiques avec les modèles émergents de données plus code de bibliothèques comme Relay.

En fin de compte, je ne conteste pas qu'un système de routeur enfichable pourrait être bien. Je faisais juste remarquer que ce serait beaucoup de travail pour l'équipe Next de supprimer les éléments qui sont les principes centraux du framework (comme la logique de fractionnement de bundle) et de les extraire dans une architecture enfichable. Et ma spéculation mettait en évidence le fait que je ne voudrais pas commencer à concevoir un changement fondamental de ma bibliothèque qui pourrait facilement être bouleversé par les changements à venir de ma dépendance principale. Je suis certainement d'accord pour dire que certains aspects de la conception de Next sont limités, mais pour la plupart, ces limites ont du sens étant donné leurs contraintes de conception jusqu'à présent.

Honnêtement, cela n'a d'importance que si vous utilisez SSG et que vous avez un tas d'itinéraires non dynamiques

Je ne suis pas sûr de ce que vous entendez par là, car SSG vs SSR n'a pas vraiment d'importance pour essayer de fournir la plus petite charge utile JS possible pour la première page ("chemin critique" JS), pas plus que les routes dynamiques.

Nous pensons probablement à différentes raisons pour lesquelles la capacité d'analyser statiquement les itinéraires existants est nécessaire. En supposant que nous parlons tous les deux d '"analyse statique" comme de "la capacité d'identifier la liste des routes (par exemple ['/about', '/', '/profile'] ) au moment de la construction simplement en lisant le code".

On dirait que vous parlez d'un type d'optimisation de bundle JS? Sur lequel je n'ai trouvé aucune information dans la documentation, je ne sais donc pas exactement à quel type d'optimisation basée sur l'analyse d'itinéraire statique vous pensez.

Ma pensée était que cette analyse statique des routes était principalement utile pour SSG. ie Parce que le fichier pages/about.js existe lorsque vous construisez votre site Next.js sait qu'une route /about existe et qu'il doit pré-rendre le html pour cette route, même si vous ne l'avez jamais dit explicitement il y a une route /about pour le pré-rendu.

SSR n'a pas besoin de code HTML pré-construit car il ne le fait que lorsqu'une requête arrive (à quel point il exécute le code et a un chemin à rendre). Les pages rendues par le client n'ont pas du tout de HTML pré-rendu. Et si votre page SSG est dynamique, vous devez quand même déclarer tous les chemins. D'où mes pensées.

Et honnêtement, si vous ne faites que des applications CSR sécurisées par connexion, alors Next _does_ a beaucoup d'inconvénients par rapport à CRA (SSR ne sera jamais aussi pratique que CSR).

À quels inconvénients pensez-vous dans Next.js en ce qui concerne les applications RSE? Mis à part les problèmes de routeur susmentionnés.

À ma connaissance, Next.js prend en charge la gamme complète des routes SSR / SSG / CSR. Il est donc censé être toujours adapté à l'écriture d'applications CSR uniquement connectées.

Personnellement, mon point de vue est définitivement celui de quelqu'un qui écrit beaucoup d'applications en grande partie RSE, avec des besoins occasionnels en SSR et SSG, qui souhaite avoir une seule boîte à outils robuste pour tous mes projets, peu importe le mélange de SSR / SSG / RSE dont ils ont besoin.

D'après mon expérience, l'ARC présente un certain nombre d'inconvénients, même au sein des applications uniquement CSR, qui pourraient rendre les pages CSR de Next.js avantageuses. La personnalisation de la configuration WebPack sans éjection est importante. Cela m'a causé beaucoup de peine lorsque je ne pouvais pas simplement utiliser le plugin WebPack globalize-compiler lorsque j'ajoutais i18n à une application. La possibilité d'accepter SSR / SSG pour des pages spécifiques même si la plupart des pages sont CSR est également un avantage (par exemple, 99,9% de vos pages sont CSR et derrière une page de connexion; mais vous avez une page de destination et peut-être des termes / contact pages sur lesquelles vous souhaitez activer SSG ou SSR). Je ne peux faire aucune de ces choses raisonnablement avec des trucs comme l'ARC.

certains d'entre nous acceptent de gérer eux-mêmes la division du code

Certains d'entre nous sont tout à fait capables de gérer nous-mêmes webpack, react-dom / serveur, etc. Jusqu'à présent, l'objectif de Next a semblé être de rendre cette éjection de plus en plus rare, tout comme CRA

Honnêtement, effectuer manuellement un fractionnement de code basé sur l'itinéraire (en vous assurant d'en modifier un pour utiliser vos composants d'itinéraire via React.lazy ou une bibliothèque alternative au lieu d'une importation directe) est très loin de gérer manuellement une configuration WebPack personnalisée ou d'écrire vos propres gestionnaires SSR avec react-dom/server .

Il est tout à fait raisonnable de ne pas vouloir écrire manuellement une configuration WebPack entière ou un serveur SSR personnalisé (c'est-à-dire utiliser un framework largement utilisé comme Next.js), mais toujours accepter d'utiliser react-router et de faire manuellement le code basé sur l'itinéraire. scission. Surtout si opter pour le fractionnement automatique du code de base de routage signifie perdre la bibliothèque de routeurs largement utilisée que vous utilisez et utiliser un routeur manquant d'un certain nombre de fonctionnalités dont vous pourriez avoir besoin avec une API très différente de celle des routeurs dans une utilisation plus large.

J'arrive toujours à ce problème lorsque je recherche un moyen d'intégrer react-router avec NextJS qui ne nécessite pas de créer un serveur personnalisé, j'ai donc décidé de l'essayer moi-même.

Avec react-router v6 (beta), créez un _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>
            )
        }
    }
}

Pourquoi

Il n'est pas facile de gérer _optional catch all routes_ dans NextJS (par exemple: /foo/[[...bar]].js ), donc j'explore un moyen de pouvoir utiliser react-router pour ce type de pages. Peut-être que d'autres ont des raisons différentes, mais c'est ma principale préoccupation et react-router fournit une belle API, spécialement dans la v6 qui est actuellement en version bêta.

Comment ça fonctionne

Il crée simplement un MemoryRouter au lieu d'un BrowserRouter afin de ne pas gâcher l'historique du navigateur en ayant le routeur NextJS et le routeur NextJS. Il écoute les modifications de l'historique de la mémoire pour PUSH et REPLACE afin que vous puissiez utiliser react-router hooks ou Link pour naviguer mais sous le capot, ce serait appel des méthodes de routeur NextJS .push et .replace .

L'appel des méthodes de routeur NextJS est nécessaire, sinon les changements de route ne déclencheront pas réellement les méthodes NextJS get*Props . En d'autres termes, cela fonctionnerait de la même manière que l'option shallow utilisant NextJS Link . L'inconvénient d'utiliser react-router de Link est qu'il n'y a pas de prefetch . Cependant, vous pouvez toujours utiliser NextJS Link place et react-router peut toujours réagir aux changements d'itinéraire.

Ce qui est cool, c'est que vous pouvez maintenant tirer parti des routes NextJS dynamic et react-router et faire des choses telles que:

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

Quoi qu'il en soit, j'espère que cela aide quelqu'un. Je ne l'ai pas utilisé en production et ce code provient d'un terrain de jeu local, donc il y a probablement des choses qui pourraient être améliorées, mais c'est un début.

Utilisation de React Router avec Next.js 9.5+

Si vous utilisez Next.js 9.5 ou plus tard , la bonne façon de le faire est avec réécritures . _N'utilisez pas de serveur personnalisé_! Il existe un tutoriel détaillé sur la façon de procéder ici: https://colinhacks.com/essays/building-a-spa-with-nextjs

L'idée de base:

  1. Créer une application personnalisée ( /pages/_app.tsx )

  2. Renvoie null si typeof window === "undefined" . Ceci est nécessaire pour empêcher react-router de lancer des erreurs lors de l'étape SSR!

// 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;

L'attribut suppressHydrationWarning sert à empêcher les avertissements que React lance lorsque le contenu rendu par le serveur est en désaccord avec le contenu rendu par le client.

  1. Réécrire tous les itinéraires vers la page d'accueil
// next.config.js

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

Ensuite, vous pouvez utiliser React Router comme d'habitude! Il y a beaucoup plus de contexte / d'explications dans le didacticiel lié, mais cela vous aidera à démarrer. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks Nice solution peut confirmer que cela fonctionne. Il faut peut-être penser à déplacer l'application vers sa propre page comme app.js ou routes.js ou quelque chose comme ça. Puis avoir les réécritures

// next.config.js

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

Juste quelque chose à penser, votre solution est la meilleure que j'ai trouvée.

Cette page vous a été utile?
0 / 5 - 0 notes