Next.js: ¿Es posible pasar el estado al siguiente / enrutador?

Actualmente eso no es posible y no creo que lo apoyemos en el futuro inmediato.

Pero abramos esto y veamos si realmente lo necesitamos.

Creo que deberías hacer esto pasando parámetros de consulta.

Quiero decir que puede lograr algo similar al pasar parámetros de consulta como dijo nkzawa, pero prefiero no contaminar mi URL con http://www.example.com/?message=This%20is%20a%20long%20message%20forwarded%20to%20be%20displayed y preferiría tener una transferencia de estado como lo hace el enrutador de reacción.

Puede usar as para disfrazar la URL

Bueno, supongo que sí, pero si tuviera que usar as , el nombre de ruta no retiene el nombre de ruta real en props.url.pathname, lo que significa que hay más cosas para pasar a la consulta. Es simplemente _más limpio_ que pase el estado.

Estoy transfiriendo un proyecto a next.js y no me he encontrado con ningún problema importante de compatibilidad desde que encontré formas de refactorizar códigos para que funcione, es solo inconveniente y verbosidad en este punto que se puede mejorar y todo este problema es .

Gracias a todos por su entrada.

Cerrando esta causa de inactividad 👍

Hace poco más de un año que mencioné esto, pero ¿todavía no es compatible?

Puede guardar cualquier estado requerido en localStorage, sessionStorage, una variable, una tienda Redux, etc. y luego usarlo en getInitialProps (verificando que está ejecutando el lado del cliente).

creo que nextjs debería comenzar a admitir react-router

Quiero la misma funcionalidad.

Anteriormente estaba usando CRA y allí solía enviar el estado al componente enrutado. Quiero la misma funcionalidad con nextjs.

Lo que @sergiodxa sugirió en la solución, pero el soporte de la biblioteca será bueno.

Lo mismo aquí, sería genial si fuera posible pasar datos con Router.push() y recuperarlos más tarde con withRouter

Quiero la misma funcionalidad. Algún avance en esto ?

Quiero la misma funcionalidad. Algún avance en esto ?

Yo también

Otra pregunta relacionada con este tema es:

• No quiero contaminar mi URL cuando llamo a Router.push() y quiero pasar un estado al siguiente componente. ¿Hay alguna forma de hacerlo? Usar localStorage o cookies es una mala práctica, ya que no están directamente controlados por los ganchos de React o el antiguo ciclo de vida de React.

Tengo un escenario en el que tengo un componente en el que se puede hacer clic. al hacer clic en él se abriría su página de detalles. Con next.js actual, puedo pasar la identificación del proyecto y luego obtener los detalles usando useEffect y axios call, pero como ya tengo los datos, realmente desearía poder enviar el estado a esa página.

Sería bueno tener esto.

@sergiodxa Sí, hay muchas formas de pasar mensajes temporales, pero la ventaja de tenerlo vinculado al enrutador es que no tenemos que escribir código adicional para administrar el ciclo de vida de los valores que pasamos. Estarán vinculados a los eventos de navegación del enrutador y no estarán disponibles en otros contextos.

Por ejemplo, si lo envío a mi tienda redux, entonces tengo que excluirlo para que no se conserve en el almacenamiento local y también enviar una acción de mensaje claro en el extremo receptor.

Si agrego la cadena de consulta, se convierte en un enlace permanente que se puede marcar y luego regresar.

Pero puedo empujarlo a la página siguiente y solo a la página siguiente a través router.push No tengo que hacer ninguna compensación; el valor solo estará disponible en ese contexto.

Muy similar a connect-flash

¿Sin solución desde el 15 de enero de 2017?
Necesitamos esa función:

Lo mismo aquí, sería genial si fuera posible pasar datos con Router.push() y recuperarlos más tarde con withRouter

Sería bueno tener esto en nextjs

si desea ocultar los parámetros de consulta, simplemente use así

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

que la página principal, solo puede ver /main en la URL y
console.log(Router.route) muestra consulta

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

oh sí, eso es cierto. Por cierto, me resulta muy incómodo que el enrutador requiera dos cadenas. react-router funciona maravillosamente sin, ¿por qué funciona esto?

Para aquellos que quieran hacerlo, pueden usar Context Api .

Next.js proporciona router.push() pasando shallow: true como apoyo.
Es la gestión estatal más simple para hacer eso.
https://nextjs.org/docs/api-reference/next/router#routerpush

Dispuesto a reconsiderar esto, sin embargo, necesita una gran propuesta sobre cómo evitar que los usuarios se disparen en el pie usando el estado del historial dado que no puede acceder al lado del servidor del estado del historial, por ejemplo, sería muy fácil causar problemas de hidratación.

Tenga en cuenta que reabrir esto no significa que no voy a escribir un RFC para esta función, eso depende de las personas que quieran tener esta función.

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

Más de 2 años y todavía esperando la función de estado

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

Esto todavía no es un estado interno, es una cadena de consulta con una función de máscara, lo cual es algo bastante extraño en mi opinión.

No estoy muy familiarizado con el ecosistema React. Pero parece que puedes hacer

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

Cuando regrese y verifique antes de PopState, la opción prop contendrá { step: 2 } .

Solo necesitamos esto en el objeto router .

No estoy muy familiarizado con el ecosistema React. Pero parece que puedes hacer

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

Cuando regrese y verifique antes de PopState, la opción prop contendrá { step: 2 } .

Solo necesitamos esto en el objeto router .

Parece otro truco temporal, no un comportamiento intencional. Las opciones esperadas se enumeran en los documentos . Pero algo similar a esto sería genial tener el comportamiento esperado.

@likerRr Aparentemente, todos los parámetros de opciones se pasan a window.history.state . Así que con mi ejemplo:
window.history.state == { step: 2 }

@likerRr Aparentemente, todos los parámetros de opciones se pasan a window.history.state . Así que con mi ejemplo:
window.history.state == { step: 2 }

Parece que lo es. De todos modos, hasta que esté documentado, no se puede usar en producción, porque la implementación de las opciones de paso se puede cambiar en cualquier momento: decepcionado: Otro problema (?) con el estado del historial, que es persistente. Y si juegas con los botones "atrás"/"adelante", en su mayoría obtendrás un comportamiento inesperado.

Según tengo entendido, el caso de uso de lo que la comunidad quiere es pasar datos que saldrán solo durante la transición de una página a otra y no tenemos que molestarnos en borrarlos. Y estos datos no deberían volver a aparecer cuando el usuario hace clic en "adelante/adelante" en un navegador. De lo contrario, esta es la mejor propuesta (imo).

Sería bueno si el próximo js considerara esto

Esto funcionó para mí, puedes usar
https://github.com/vercel/next.js/issues/771#issuecomment-612018764

1: en la página de suscripción:
const handleClick = useCallback((montar) => {
Router.push( /payment?mount=${mount} , '/pago');
}, []);
2: en la página de pago
usarEfecto(() => {
constante {
consulta: {montar},
} = Enrutador;
!mount && Router.push('/resumen-campaña/suscripción');
console.log('PagoVM:React.FC -> montar', montar);
}, []);

puede ver el valor de mount en el navegador de la consola.

Entiendo el problema y la conveniencia de poder pasar el estado en router.push.

¿Sería la siguiente una solución temporal?

Usa el history.pushState del navegador, así como un useState local de una cadena de ubicación, y cuando queremos redirigir, usamos history.pushState y establecemos un nuevo valor para el estado de la ubicación local. Una actualización de location-string-state debería desencadenar una ejecución de useEffect. Luego, tenga una declaración de cambio de JS que evalúe la ubicación y devuelva los componentes en función de la ubicación. Y si queremos llegar al mismo componente sin history.pushState (por ejemplo, si el usuario actualiza la página), podemos hacer que la ubicación sea un parámetro de consulta dinámico siguiente. - no lo probé, solo intenté pensar en soluciones alternativas.

Para aquellos que quieran hacerlo, pueden usar Context Api .

Next.js proporciona router.push() pasando shallow: true como apoyo.
Es la gestión estatal más simple para hacer eso.
https://nextjs.org/docs/api-reference/next/router#routerpush

¿Qué pasa si en mi getServerSideProps hago dos llamadas, una de las cuales se debe rehacer para cada carga y la otra solo se debe cargar con una condición? Para eso, Shallow: true no ayudaría mucho porque no es un administrador de estado, o rehace getServerSideProps , o no lo hace en absoluto.
Un ejemplo de este escenario sería si realizo dos llamadas separadas en getServerSideProps . Una para el contenido principal de la página y luego otra llamada para obtener los enlaces de navegación. En un renderizado inicial, quiero que ambas llamadas estén en el servidor, pero luego, ya tengo los enlaces de navegación en la memoria, así que no necesito recuperarlos. Es por eso que necesitamos el estado.

La única solución es enviar una opción as con parámetros de consulta ocultos, pero nuestro código sería horrible por cada <Link/> que pasemos en un conjunto de parámetros de consulta que contengan nuestro estado actual. (En realidad, mientras escribo, estoy pensando en hacer un enlace HOC que debería ir al href especificado y enviar un objeto de consulta con el estado actual, por lo que no necesitaría escribir el objeto de estado en cada <Linke/> , yo solo manejaré esto en el HOC)