Next.js: Possible de passer l'état au suivant/routeur ?

Actuellement, ce n'est pas possible et je ne pense pas que nous le soutiendrons dans l'immédiat.

Mais ouvrons ceci et voyons si nous en avons vraiment vraiment besoin.

Je pense que vous devriez le faire en passant des paramètres de requête.

Je veux dire que vous pouvez obtenir une chose similaire en transmettant des paramètres de requête comme l'a dit nkzawa, mais je préfère ne pas polluer mon URL avec http://www.example.com/?message=This%20is%20a%20long%20message%20forwarded%20to%20be%20displayed et je préfère avoir un transfert d'état comme le fait le routeur de réaction.

Vous pouvez utiliser as pour déguiser l'URL

Eh bien, je suppose que oui, mais si je devais utiliser as , le nom de chemin ne conserve pas le nom de chemin réel dans props.url.pathname, ce qui signifie plus de choses à passer dans la requête. C'est juste _plus propre_ de le faire passer l'état.

Je suis en train de porter un projet sur next.js et je n'ai rencontré aucun problème de compatibilité majeur depuis que j'ai trouvé des moyens de refactoriser les codes pour le faire fonctionner, c'est juste des inconvénients et de la verbosité à ce stade qui peuvent être améliorés et tout ce problème est .

Merci à tous pour votre contribution.

Fermeture de cette cause d'inactivité 👍

Un peu plus d'un an que j'en ai parlé, mais est-ce toujours insupportable ?

Vous pouvez enregistrer n'importe quel état requis dans localStorage, sessionStorage, une variable, un magasin Redux, etc., puis l'utiliser dans getInitialProps (en vérifiant que vous exécutez le côté client).

je pense que nextjs devrait commencer à prendre en charge le routeur de réaction

Je veux la même fonctionnalité.

Auparavant, j'utilisais CRA et j'avais l'habitude d'envoyer l'état au composant routé. Je veux la même fonctionnalité avec nextjs.

Ce que @sergiodxa a suggéré dans la solution de contournement, mais le support de la bibliothèque sera bon.

Pareil ici, ce serait formidable s'il était possible de transmettre des données avec Router.push() et de les récupérer plus tard avec withRouter

Je veux la même fonctionnalité. Une mise à jour pour ceci ?

Je veux la même fonctionnalité. Une mise à jour pour ceci ?

Moi aussi

Une autre question liée à ce problème est:

• Je ne veux pas polluer mon URL lorsque j'appelle le Router.push() et je veux passer un état au composant suivant. Y a-t-il un moyen de le faire? L'utilisation de localStorage ou de cookie est une mauvaise pratique car ils ne sont pas directement contrôlés par les hooks React ou l'ancien cycle de vie React

J'ai un scénario où j'ai un composant cliquable. cliquer dessus ouvrirait sa page de détails. Avec le fichier next.js actuel, je peux transmettre l'identifiant du projet, puis obtenir les détails à l'aide de useEffect et de l'appel axios, mais comme j'ai déjà les données, je souhaite vraiment pouvoir envoyer l'état à cette page.

Ce serait bien d'avoir ça.

@sergiodxa Oui, il existe de nombreuses façons de transmettre des messages temporaires, mais l'avantage de le lier au routeur est que nous n'avons pas à écrire de code supplémentaire pour gérer le cycle de vie des valeurs que nous transmettons. Ils seront liés aux événements de navigation du routeur et indisponibles dans d'autres contextes.

Par exemple, si je le pousse vers mon magasin redux, je dois l'exclure de la persistance dans le stockage local et également envoyer une action de message clair à la réception.

Si je l'ajoute à la chaîne de requête, il devient un lien permanent qui peut être mis en signet et revenir plus tard.

Mais si je peux le pousser à la page suivante et seulement à la page suivante via router.push je n'ai pas à faire de compensations ; la valeur ne sera disponible que dans ce contexte.

Très similaire à connect-flash

Pas de solution depuis le 15 janvier 2017 ?
Nous avons besoin de cette fonctionnalité :

Pareil ici, ce serait formidable s'il était possible de transmettre des données avec Router.push() et de les récupérer plus tard avec withRouter

Ce serait bien d'avoir ça dans nextjs

si vous voulez masquer les paramètres de requête, utilisez simplement comme ceci

Router.push(`/main?userName=${userName}`, 'main')

que la page principale, vous ne pouvez voir que /main sur l'url et
console.log(Router.route) affiche la requête

pathname: "/main"
query: {userName: "fadsfasd"}
asPath: "main"

ah ouais, c'est vrai. Au fait, je trouve vraiment gênant que le routeur nécessite deux chaînes. react-router fonctionne à merveille sans, pourquoi cela ?

Pour ceux qui veulent le faire, vous pouvez utiliser Context Api .

Next.js fournit le router.push() passant shallow: true comme accessoire.
C'est la gestion d'état la plus simple pour faire ça.
https://nextjs.org/docs/api-reference/next/router#routerpush

Désireux de reconsidérer cela, cependant, il a besoin d'une excellente proposition sur la façon d'empêcher les utilisateurs de se tirer une balle dans le pied en utilisant l'état de l'historique étant donné que vous ne pouvez pas accéder à l'état de l'historique côté serveur par exemple, il serait très facile de causer des problèmes d'hydratation.

Notez que rouvrir cela ne signifie pas que je ne vais pas écrire de RFC pour cette fonctionnalité, cela dépendrait des personnes qui souhaitent disposer de cette fonctionnalité.

Router.push({ pathname: '/', query: { message: 'This is a message forwarded in a state.' } }, '/')

Plus de 2 ans et toujours en attente de fonctionnalité d'état

Router.push({ pathname: '/', query: { message: 'This is a message forwarded in a state.' } }, '/')

Ce n'est toujours pas un état interne, c'est une chaîne de requête avec une fonctionnalité de masque, ce qui est une chose assez étrange à faire à mon avis.

Je ne suis pas très familier avec l'écosystème React. Mais il semble que tu puisses faire

router.push(
  { pathname: '/hello-world' }, 
  '/hello-world/2', 
  { step: 2 }
);

Lorsque vous revenez en arrière et vérifiez avant PopState, l'option prop contiendra { step: 2 } .

Nous n'en avons besoin que dans l'objet router .

Je ne suis pas très familier avec l'écosystème React. Mais il semble que tu puisses faire

router.push(
  { pathname: '/hello-world' }, 
  '/hello-world/2', 
  { step: 2 }
);

Lorsque vous revenez en arrière et vérifiez avant PopState, l'option prop contiendra { step: 2 } .

Nous n'en avons besoin que dans l'objet router .

Cela ressemble à un autre piratage temporel, pas à un comportement intentionnel. Les options attendues sont répertoriées dans la documentation . Mais quelque chose de similaire à cela serait formidable d'avoir le comportement attendu

@likerRr Apparemment, tous les paramètres d'options sont passés à window.history.state . Alors avec mon exemple :
window.history.state == { step: 2 }

@likerRr Apparemment, tous les paramètres d'options sont passés à window.history.state . Alors avec mon exemple :
window.history.state == { step: 2 }

On dirait que ça l'est. Quoi qu'il en soit, jusqu'à ce qu'il soit documenté, il ne peut pas être utilisé dans la production, car l'implémentation des options de passage peut être modifiée à tout moment :déçu: Un autre problème (?) avec l'état de l'historique, qu'il est persistant. Et si vous jouez avec les boutons "précédent"/"suivant", vous obtiendrez le plus souvent un comportement inattendu.

Autant que je sache, le cas d'utilisation de ce que la communauté veut est de transmettre des données qui ne partiront que lors de la transition d'une page à une autre et nous n'avons pas à nous soucier de les effacer. Et ces données ne doivent plus réapparaître lorsque l'utilisateur clique sur "retour/retour" dans un navigateur. Sinon, c'est la meilleure proposition (imo).

Ce serait bien si le prochain js considérait cela

Cela a fonctionné pour moi, vous pouvez utiliser
https://github.com/vercel/next.js/issues/771#issuecomment -612018764

1 : dans la page Abonnement :
const handleClick = useCallback((mount) => {
Routeur.push( /payment?mount=${mount} , '/ paiement');
}, []);
2 : dans la page de paiement
useEffet(() => {
const {
requête : {monter},
} = Routeur ;
!mount && Router.push('/campaign-overview/subscription');
console.log('PaymentVM:React.FC -> mount', mount);
}, []);

vous pouvez voir la valeur de mount dans le navigateur de la console.

Je comprends le problème et la commodité de pouvoir transmettre l'état dans router.push.

La solution suivante serait-elle temporaire ?

Utilisez le history.pushState du navigateur, ainsi qu'un useState local d'une chaîne d'emplacement, et lorsque nous voulons rediriger, nous utilisons history.pushState ainsi que la définition d'une nouvelle valeur pour l'état de l'emplacement local. Une mise à jour de location-string-state devrait déclencher une exécution useEffect. Ensuite, ayez une instruction JS swich qui évalue l'emplacement et renvoie les composants en fonction de l'emplacement. Et si nous voulons accéder au même composant sans history.pushState (par ex. si l'utilisateur actualise la page), nous pouvons faire de l'emplacement un prochain paramètre de requête dynamique. - Je n'ai pas essayé, j'ai juste essayé de penser à des solutions de contournement.

Pour ceux qui veulent le faire, vous pouvez utiliser Context Api .

Next.js fournit le router.push() passant shallow: true comme accessoire.
C'est la gestion d'état la plus simple pour faire ça.
https://nextjs.org/docs/api-reference/next/router#routerpush

Que se passe-t-il si dans my in my getServerSideProps , je fais deux appels, dont un doit être refait pour chaque chargement, et un ne doit être chargé qu'avec une condition. Pour cela, Shallow: true n'aiderait pas beaucoup car ce n'est pas un gestionnaire d'état, soit il refait getServerSideProps , soit il ne le fait pas du tout.
Un exemple de ce scénario serait si je fais deux appels séparés dans getServerSideProps . Un pour le contenu principal de la page puis un autre appel pour obtenir les liens de navigation. Dans un rendu initial, je veux que les deux appels soient sur le serveur, mais ensuite, j'ai déjà les liens de navigation en mémoire, donc je n'ai pas besoin de les récupérer. C'est pourquoi nous avons besoin d'état.

La seule solution consiste à envoyer une option as avec des paramètres de requête cachés, mais notre code serait affreux pour chaque <Link/> que nous transmettons dans un ensemble de paramètres de requête contenant notre état actuel. (En fait, au moment où j'écris, je pense créer un lien HOC qui devrait aller au href spécifié et envoyer un objet de requête avec l'état actuel, donc je n'aurais pas besoin d'écrire l'objet d'état dans chaque <Linke/> , je Je ne gérerai cela que dans le HOC)