Next.js: Possível passar o estado para o próximo/roteador?

Atualmente isso não é possível e eu não acho que vamos apoiá-lo no futuro imediato.

Mas vamos abrir isso e ver se realmente precisamos disso.

Eu acho que você deve fazer isso passando parâmetros de consulta.

Quero dizer, você pode conseguir uma coisa semelhante passando parâmetros de consulta como nkzawa disse, mas prefiro não poluir minha url com http://www.example.com/?message=This%20is%20a%20long%20message%20forwarded%20to%20be%20displayed e prefiro ter uma transferência de estado como o react-router faz isso.

Você pode usar as para disfarçar a URL

Bem, suponho que sim, mas se eu usar as , o nome do caminho não retém o nome do caminho real em props.url.nome do caminho, o que significa mais coisas para passar para a consulta. É apenas _cleaner_ fazer com que passe o estado.

Estou migrando um projeto para o next.js e não tive grandes problemas de compatibilidade desde que encontrei maneiras de refatorar códigos para fazê-lo funcionar, é apenas inconveniência e verbosidade neste ponto que pode ser melhorado e todo esse problema .

Obrigado a todos por sua entrada.

Fechando essa causa de inatividade 👍

Um pouco mais de um ano desde que eu mencionei isso, mas isso ainda não é suportável?

Você pode salvar qualquer estado necessário em localStorage, sessionStorage, uma variável, um armazenamento Redux, etc. e então usá-lo em getInitialProps (verificando se você está executando o lado do cliente).

eu acho que o nextjs deve começar a suportar o roteador de reação

Eu quero a mesma funcionalidade.

Anteriormente eu estava usando o CRA e lá eu costumava enviar o estado para o componente roteado. Eu quero a mesma funcionalidade com nextjs.

O que @sergiodxa sugeriu como solução alternativa, mas o suporte à biblioteca será bom.

O mesmo aqui, seria ótimo se fosse possível passar dados com Router.push() e recuperá-los depois com withRouter

Eu quero a mesma funcionalidade. Alguma atualização disso ?

Eu quero a mesma funcionalidade. Alguma atualização disso ?

eu também

Outra questão relacionada a este assunto é:

• Não quero poluir minha URL quando chamo Router.push() e quero passar um estado para o próximo componente. Há alguma forma de fazer isso? Usar localStorage ou cookie é uma prática ruim, pois eles não são controlados diretamente pelos ganchos do React ou pelo antigo ciclo de vida do React

Eu tenho um cenário onde eu tenho um componente clicável. clicar nele abriria sua página de detalhes. Com o next.js atual eu posso passar o id dos projetos e então obter os detalhes usando useEffect e axios call, mas como eu já tenho os dados eu realmente gostaria de poder enviar o estado para essa página.

Seria bom ter isso.

@sergiodxa Sim, existem muitas maneiras de passar mensagens temporárias, mas a vantagem de tê-lo vinculado ao roteador é que não precisamos escrever código extra para gerenciar o ciclo de vida dos valores que passamos. Eles estarão vinculados a eventos de navegação do roteador e indisponíveis em outros contextos.

Por exemplo, se eu o enviar para o meu armazenamento redux, terei que excluí-lo da persistência no armazenamento local e também despachar uma ação de mensagem clara no final do recebimento.

Se eu adicionar a string de consulta, ela se tornará um link permanente que pode ser usado como favorito e depois retornar.

Mas posso empurrar para a próxima página e somente a próxima página via router.push não tenho que fazer compensações; o valor só estará disponível nesse contexto.

Muito semelhante ao flash de conexão

Nenhuma solução desde 15 de janeiro de 2017?
Precisamos desse recurso:

O mesmo aqui, seria ótimo se fosse possível passar dados com Router.push() e recuperá-los depois com withRouter

Seria bom ter isso no nextjs

se você quiser ocultar os parâmetros de consulta, basta usar assim

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

do que a página principal, você pode ver apenas /main no url e
console.log(Router.route) mostra a consulta

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

ah sim, é verdade. Aliás, acho muito estranho que o roteador exija duas cordas. react-router funciona lindamente sem, por que isso?

Para quem quiser fazer, pode usar Context Api .

Next.js fornece o router.push() passando shallow: true como prop.
É o gerenciamento de estado mais simples para fazer isso.
https://nextjs.org/docs/api-reference/next/router#routerpush

Disposto a reconsiderar isso, no entanto, ele precisa de uma ótima proposta sobre como impedir que os usuários dêem tiros no pé usando o estado do histórico, pois você não pode acessar o lado do servidor do estado do histórico, por exemplo, seria muito fácil causar problemas de hidratação.

Observe que reabrir isso não significa que eu não vou escrever um RFC para esse recurso, isso depende das pessoas que desejam ter esse recurso.

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

Mais de 2 anos e ainda aguardando recurso de estado

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

Isso ainda não é um estado interno, é uma string de consulta com um recurso de máscara, o que é uma coisa bastante estranha de se fazer na minha opinião.

Eu não estou super familiarizado com o ecossistema React. Mas parece que você pode fazer

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

Quando você voltar e verificar antes do PopState, a opção prop conterá { step: 2 } .

Nós só precisamos disso no objeto router .

Eu não estou super familiarizado com o ecossistema React. Mas parece que você pode fazer

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

Quando você voltar e verificar antes do PopState, a opção prop conterá { step: 2 } .

Nós só precisamos disso no objeto router .

Parece outro hack temporal, não um comportamento intencional. As opções esperadas estão listadas nos documentos . Mas algo parecido com isso seria ótimo ter como comportamento esperado

@likerRr Aparentemente todos os parâmetros de opções estão sendo passados ​​para window.history.state . Então com meu exemplo:
window.history.state == { step: 2 }

@likerRr Aparentemente todos os parâmetros de opções estão sendo passados ​​para window.history.state . Então com meu exemplo:
window.history.state == { step: 2 }

Parece que é. De qualquer forma, até que seja documentado, não pode ser usado em prod, porque a implementação de opções de passagem pode ser alterada a qualquer momento :disappointed: Outro problema (?) com o estado do histórico, que é persistente. E se você jogar com os botões "voltar"/"avançar" na maioria das vezes terá um comportamento inesperado.

Tanto quanto eu entendo, o caso de uso do que a comunidade quer é passar dados que sairão apenas durante a transição de uma página para outra e não precisamos nos preocupar em limpá-los. E esses dados não devem aparecer novamente quando o usuário clicar em "voltar/avançar" em um navegador. Caso contrário, esta é a melhor proposta (imo).

Seria bom se o próximo js considerasse isso

Isso funcionou para mim, você pode usar
https://github.com/vercel/next.js/issues/771#issuecomment -612018764

1: na página Assinatura:
const handleClick = useCallback((mount) => {
Router.push( /payment?mount=${mount} , '/pagamento');
}, []);
2: na página de pagamento
useEfeito(() => {
const {
consulta: { montar },
} = Roteador;
!mount && Router.push('/campaign-overview/subscription');
console.log('PaymentVM:React.FC -> montar', montar);
}, []);

você pode ver o valor de mount no navegador do console.

Eu entendo o problema e a conveniência de poder passar o estado no router.push.

O seguinte seria uma solução temporária?

Use o history.pushState do navegador, bem como um useState local de uma string de localização e, quando quisermos redirecionar, usamos history.pushState, além de definir um novo valor para o estado de localização local. Uma atualização para o estado da string de localização deve acionar uma execução useEffect. Em seguida, tenha uma instrução swich JS que avalie a localização e retorne os componentes com base na localização. E se quisermos chegar ao mesmo componente sem history.pushState (por exemplo, se o usuário atualizar a página), podemos tornar o local um parâmetro de próxima consulta dinâmico. -- não tentei, apenas tentando pensar em soluções alternativas.

Para quem quiser fazer, pode usar Context Api .

Next.js fornece o router.push() passando shallow: true como prop.
É o gerenciamento de estado mais simples para fazer isso.
https://nextjs.org/docs/api-reference/next/router#routerpush

E se no my in my getServerSideProps , eu fizer duas chamadas, uma das quais deve ser refeita para cada carregamento, e a outra deve ser carregada apenas com uma condição. Para isso, Shallow: true não ajudaria muito porque não é um gestor de estado, ou é refazer getServerSideProps , ou não faz nada.
Um exemplo desse cenário seria se eu fizer duas chamadas separadas em getServerSideProps . Uma para o conteúdo principal da página e outra para obter os links de navegação. Em uma renderização inicial, quero que ambas as chamadas estejam no servidor, mas já tenho os links de navegação na memória para não precisar buscá-los novamente. Por isso precisamos do Estado.

A única solução é enviar uma opção as com parâmetros de consulta ocultos, mas nosso código seria horrível para cada <Link/> que passamos em um punhado de parâmetros de consulta que contém nosso estado atual. (Na verdade, enquanto estou escrevendo, estou pensando em fazer um link HOC que deve ir para o href especificado e enviar um objeto de consulta com o estado atual para que eu não precise escrever o objeto de estado em cada <Linke/> , eu só vai lidar com isso no HOC)