Next.js: Use com React Router 4

Criado em 5 abr. 2017  ¬∑  122Coment√°rios  ¬∑  Fonte: vercel/next.js

√Č poss√≠vel usar next.js com o novo roteador react v4?

Coment√°rios muito √ļteis

@timneutkens adicionar a integração do roteador react ajudaria a aumentar a adoção do nextjs e tornaria o desenvolvimento melhor. Desenvolvedores como eu adorariam ver isso acontecer, considere aumentar a prioridade.

Todos 122 coment√°rios

@Knaackee Você experimentou a possibilidade? Também estou me perguntando se alguém conseguiu que funcione com alguma versão do RR?

A seguir tem seu próprio roteador, por que usar RR?

@sergiodxa Op√ß√Ķes de pesagem conforme transporto meu aplicativo existente para Pr√≥ximo. Tenho uma configura√ß√£o de rota est√°tica aninhada funcionando e me perguntando o que posso continuar usando e o que n√£o.

@oyeanuj ūü§Ē voc√™ pode migrar gradualmente para Next, basta definir Next.js para lidar com 1 rota e usar um proxy para ter seu aplicativo atual e Next.js, ent√£o mover uma segunda rota de RR para Next.js, e isso maneira de manter seu aplicativo atual durante a migra√ß√£o, eventualmente voc√™ ter√° tudo em Next.js

Olhando para os exemplos, parece que a seguir tem uma √ļnica tabela de rota como RRv2-3 e n√£o suporta "rotas aninhadas" como RRv4. Estes s√£o bons.

Eu tentaria usar o RR ou há uma grande advertência que não conheço?

@igl Você descobriu uma solução para isso?

O novo paradigma react-router 4 de rotas aninhadas é uma virada de jogo e é algo indispensável em nosso projeto atual. Estou me perguntando se alguém conseguiu fazer o rr4 funcionar com next.js?

MemoryRouter funciona, se n√£o for como pretendido ...
Caso contr√°rio, os componentes din√Ęmicos podem ser apenas do lado do cliente, onde HashRouter funciona bem ...

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

Tamb√©m estou seguindo a abordagem react-router e todo o conte√ļdo renderizado do servidor com next roteador.

@malixsys @pegiadise pode dar mais alguns detalhes sobre como usar o próximo roteador e o roteador

Voc√™ pode definir um sinalizador em componentDidMount e renderizar condicionalmente <Router /> quando o sinalizador for verdadeiro. ( componentDidMount n√£o funciona no servidor ūüėČ)

Na verdade, iremos incorporar o React Router dentro do Next.js em breve :)
- https://twitter.com/rauchg/status/948318111828099072

Isso ainda está acontecendo? Posso ver as notas de lançamento do canário V6 e não há menção a isso.

Eventualmente. Est√° definitivamente em nossas mentes. Temos outras prioridades agora (componente de layout, desenvolvimento confi√°vel e alguns outros problemas em aberto de longa data).

√Č uma pena, pode ser de baixa prioridade para a equipe, mas √© basicamente a √ļnica coisa que impede pessoas como eu de come√ßar a us√°-lo. Eu li seu tutorial at√© chegar na parte em que dizia que as rotas devem ser configuradas duas vezes e desisti.

@timneutkens adicionar a integração do roteador react ajudaria a aumentar a adoção do nextjs e tornaria o desenvolvimento melhor. Desenvolvedores como eu adorariam ver isso acontecer, considere aumentar a prioridade.

√Č uma pena, pode ser de baixa prioridade para a equipe, mas √© basicamente a √ļnica coisa que impede pessoas como eu de come√ßar a us√°-lo.

Mesmo.

Podemos pelo menos reabrir este problema para que possa ser rastreado?

Vou reabrir isso, mas observe que este é um projeto de código aberto e não temos um caso muito forte para ele neste momento para zeit.co, uma vez que usamos Next.js para tudo.

√Č por isso que eu estava dizendo que faz parte dos objetivos de longo prazo e n√£o pode ser implementado imediatamente, mas estamos trabalhando para isso.

Os recursos que introduzi no Next 6 est√£o, na verdade, trabalhando para o suporte do React Router.

Tínhamos outras prioridades para o Next 6, que estão melhorando tremendamente a confiabilidade e escalabilidade do Next.js, por exemplo resolução de página 100x mais rápida, componente do aplicativo, trabalho de próxima exportação em desenvolvimento, babel 7, etc.

Espero que isso elabore meu coment√°rio anterior.

Portanto, o TLDR é:

  • Vamos fazer isso, mas n√£o imediatamente
  • Next 6 tem muitas melhorias em diferentes partes do Next.js

Para estender ainda mais o comentário de @timneutkens : nós definitivamente queremos RR, mas não temos nenhuma limitação urgente no roteador atual que o torne uma prioridade. Todos os casos de uso de roteamento que você pode imaginar foram implementados com sucesso com a API Next.js atual

H√° dois motivos pelos quais realmente queremos o suporte do React Router para:

  • Simplifique nossa pr√≥pria base de c√≥digo Next.js, n√£o precise manter nosso pr√≥prio roteador, torne as coisas menores e modulares
  • Simplifique o caminho de migra√ß√£o de grandes aplicativos que j√° usam RR

Como tal, concordo que devemos manter este assunto em aberto!

Como contraponto, n√£o ter o react-router significa que o next funciona bem com o relay-modern e foi uma das raz√Ķes pelas quais mudamos para next de nosso antigo app react-router.

@merrywhether eu trabalhei em um aplicativo RRv4 com relay-modern ano passado. Quer ser mais específico?
Não me lembro de termos problemas sérios por causa de qualquer um deles.

@igl Isso está de acordo com a documentação do relé: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

O problema é que a abordagem de componente do RRv4 não permite determinismo durante a etapa de pré-compilação, o que pode resultar em cascatas de solicitação no cliente.

@rauchg Por curiosidade, meu entendimento sobre o roteador do Next é que ele não oferece suporte ao conceito de roteamento aninhado, de modo que você pode manter a marcação externa enquanto navega em uma página. Você sabe se existe uma maneira de tornar isso possível com o roteador atual?

@dbbk verifique nosso aplicativo de exemplo de nextgram (https://github.com/now-examples/nextgram), ele faz exatamente isso

Nos pr√≥ximos 5, estaremos realizando "marca√ß√£o externa" com componentes de layout de n√≠vel superior que todas as nossas p√°ginas estendem: o layout de base tem navega√ß√£o superior, depois alguns sub-layouts que estendem a base para listas / detalhes / etc, e ent√£o nossos componentes de p√°ginas estendem esses sub-layouts com seu pr√≥prio conte√ļdo espec√≠fico. Nos pr√≥ximos 6, voc√™ tamb√©m pode realizar a "marca√ß√£o externa" b√°sica usando _app.js eu acredito.

A próxima versão será configurável para escolher uma solução de roteamento que não seja o React Router?

Olá, eu só preciso do roteador Rea para passar props para as páginas (usando <Route render ={} /> vez de <Route component ={} /> ), posso fazer isso com o Next?

Olhando para os exemplos, parece que a seguir tem uma √ļnica tabela de rota como RRv2-3 e n√£o suporta "rotas aninhadas" como RRv4. Estes s√£o bons.

Oi,

Isso significa que devo criar uma √ļnica p√°gina para uma √ļnica rota?

Digamos que eu tenha 2 rotas sign up , log in . Eu teria 1 p√°gina que compartilhasse o mesmo layout, a √ļnica diferen√ßa √© a √°rea dos formul√°rios. Isto √©, eu s√≥ preciso criar 1 arquivo na pasta pages . Mas com as pr√≥ximas rotas, tenho que criar 2 arquivos na pasta pages . √Č isso?

Se for, o layout é remontado a cada navegação, não apenas à área de formulários, certo?

@ 7c78 Uma coisa que você pode fazer é aproveitar _app.js para um layout de página persistente para todas as páginas. A outra coisa a fazer é criar componentes de layout compartilhados que você pode reutilizar em várias páginas para alcançar o que você está procurando:

// pages/login.js

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

Além disso, você pode fazer o que fizemos recentemente e definir componentes de layout de base que todos os componentes de sua página estendem:

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

E então você apenas estende BaseAuth em suas páginas de login e inscrição e define formContent e formSubmit em cada uma delas (esses são exemplos de brinquedo, já que não conheço seus requisitos exatos).

@merrywhether
Atualmente, uso sua abordagem e os próximos exemplos também a usam.

Mas minha preocupação é que preciso criar páginas separadas para formulários separados. Ou seja, o layout é reutilizado, mas não a página. E o layout é remontado a cada navegação.

Com o RRv4, temos uma p√°gina √ļnica e os formul√°rios s√£o renderizados / remontados com base em rotas (n√£o a p√°gina inteira). As rotas s√£o apenas componentes.

Obrigado pela resposta r√°pida!

@ 7c78 Isso é verdade sobre remontagem, embora eu ache que os nós DOM são reutilizados quando o vDOM é resolvido para o mesmo estado.

Não é algo com que nos preocupamos muito porque também não podemos usar o react-router com relay-modern, então tivemos que usar esse padrão de qualquer maneira.

@merrywhether Não tenho certeza sobre o vDOM porque o servidor retorna um novo documento / html para todas as rotas. Desculpe, ignore essa suposição, sou apenas um novato.

Concordo que temos que usar esse padr√£o de qualquer maneira. Obrigado!

Você pode usar RR com next.js fazendo com que todo o seu aplicativo esteja em pages / index.js, mas você perde algumas das vantagens da divisão de código next like out of the box e precisa configurar isso sozinho.

Eu adoraria se o Reach Router fosse considerado. √Č muito semelhante ao react-router e traz alguns benef√≠cios importantes:

  • Ele resolve algumas quest√Ķes importantes a11y em torno da gera√ß√£o de links e gerenciamento de foco (https://reach.tech/router/accessibility).
  • Pesa menos (no momento da escrita)

O roteador de alcance tamb√©m √© √≥timo ūü•á

Rotas din√Ęmicas no estilo RR s√£o uma boa API, mas o roteamento est√°tico (e estaticamente analis√°vel) traz muitos benef√≠cios tamb√©m. Nenhuma das abordagens √© vencedora.

@sorokinvj Isso só é compatível com um plugin (atualmente) .. https://github.com/fridays/next-routes

links est√°ticos s√£o t√£o b√°sicos que nem mesmo suportam par√Ęmetros em links ...

Estou usando um pacote de terceiros next-routes agora https://github.com/fridays/next-routes para contornar isso

Enviado do meu iPhone

Em 24 de outubro de 2018, √†s 23:01, Andy Ingram [email protected] escreveu:

Rotas din√Ęmicas no estilo RR s√£o uma boa API, mas o roteamento est√°tico (e estaticamente analis√°vel) traz muitos benef√≠cios tamb√©m. Nenhuma das abordagens √© vencedora.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Estamos usando next-routes tamb√©m por enquanto, mas acredito que a pr√≥xima equipe est√° trabalhando para adicionar par√Ęmetros de caminho ao roteamento do sistema de arquivos por meio de nomes de arquivo regex (inspirados no Sapper).

@merrywhether Estou usando next-routes tamb√©m, mas preferiria que isso fizesse parte do n√ļcleo do Next.js.

Você mencionou

Acredito que a pr√≥xima equipe est√° trabalhando para adicionar par√Ęmetros de caminho ...

Estou curioso, voc√™ tem alguma refer√™ncia para isso? Talvez um problema aberto para par√Ęmetros de rota? N√£o estou conseguindo encontrar um ... Talvez o plugin resolva a necessidade e essa seja a solu√ß√£o recomendada daqui para frente.

@curran A fonte foi um tweet dos devs sapper.js, dizendo que a seguir estava se inspirando em sapper.js e implementando regex-filename-routing em uma vers√£o futura. √Č claro que, sendo o Twitter o que √©, n√£o pude nem de longe encontrar o tweet original.

Este problema foi levantado em 5 de abril de 2017 e agora é 27 de fevereiro de 2019. Quase 2 anos e nenhuma solução
Pode ser a hora de substituir o roteador embutido pela metade por algo bom?

Ai. Isso é um insulto para os desenvolvedores do NextJS que dedicam muitas horas à solução de roteamento.

Eu perdi ReactRouter no in√≠cio. Agora nem lembro que o NextJS tem um roteador diferente at√© que algu√©m me lembre. Detalhado Link API √© f√°cil de envolver com proxies (dependendo de sua arquitetura de dados / API), por exemplo. Compartilhando este segredo: ūüėÜ

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

Acho que todos dever√≠amos gastar menos tempo reclamando de coisas secund√°rias ūüėČ

@ ivan-kleshnin Legal, eu adicionei um invólucro semelhante

Conforme o coment√°rio anterior, gostaria de apontar para https://www.contributor-covenant.org/version/1/4/code-of-conduct

Eu escondi esse coment√°rio.

N√£o tenho problemas com next/router para a maioria dos casos de uso.
Mas deve melhorar um pouco na parte universal routing .
No caso da implantação do Now 2, eu adoraria pegar now.json e usá-lo para rotear em meu aplicativo.

Se você deseja implementar RR4 no projeto nextJs, você precisa fazer 2 coisas:

  1. Previna NextJS SSR, usando next/dynamic você pode fazer isso.
  2. Usando HashRouter vez de BrowserRouter -> se o usu√°rio recarregar a p√°gina, o navegador pode carregar a p√°gina anterior (n√£o a p√°gina 404)

Se você deseja implementar RR4 no projeto nextJs, você precisa fazer 2 coisas:

  1. Previna NextJS SSR, usando next/dynamic você pode fazer isso.
  2. Usando HashRouter vez de BrowserRouter -> se o usu√°rio recarregar a p√°gina, o navegador pode carregar a p√°gina anterior (n√£o a p√°gina 404)

Obrigado pela resposta, me ajudou muito.

@ reach / router e react-router 5 est√£o se fundindo: https://reacttraining.com/blog/reach-react-router-future/

Como isso afeta o next.js?

@ alp82 Como Next.js ainda n√£o usa React Router ou Reach Router, ele n√£o afetar√° Next.js de forma alguma.

Eu preciso mudar a funcionalidade de rotas em nextjs para renderizar vários componentes de páginas em páginas de índice.
ent√£o, como posso implementar isso no nextjs ....... ???

Se você deseja implementar RR4 no projeto nextJs, você precisa fazer 2 coisas:

  1. Previna NextJS SSR, usando next/dynamic você pode fazer isso.
  2. Usando HashRouter vez de BrowserRouter -> se o usu√°rio recarregar a p√°gina, o navegador pode carregar a p√°gina anterior (n√£o a p√°gina 404)

se você quiser renderizar novamente sua página anterior sem lançar o erro 404, então usei apenas esta rota de obtenção em seu arquivo de servidor expresso

server.get ('seus par√Ęmetros', (req, res) => {
const actualPage = '/ sua_pagina'
const queryParams = {id: req.params.id}
app.render (req, res, actualPage, queryParams)
})

Documentei uma abordagem para usar next.js com react-router , fornecendo um √ļnico arquivo de preservando totalmente SSR nativos .

Ficarei feliz em receber feedbacks e melhorar o que fiz.

A documentação está disponível como:

Felicidades!

Eu altamente desencorajaria incluir o react-router dessa forma, pois voc√™ acaba com um √ļnico ponto de entrada, o que significa (tremendamente) compila√ß√Ķes de desenvolvimento mais lentas, maior chance de enviar muito c√≥digo para o lado do cliente e menos visibilidade em otimiza√ß√Ķes como exporta√ß√£o est√°tica autom√°tica.

@timneutkens Talvez eu esteja errado. Mas com o carregamento lento, a configuração de roteamento é apenas um arquivo de configuração. Não vejo como isso afetará a escalabilidade ou o desempenho aqui. Eu adoraria aprender mais sobre isso.
O benefício do react-router é que os desenvolvedores têm controle total sobre o código.

@timneutkens , não vou começar uma discussão aqui, mas peço a você que

@timneutkens quanto aos pontos que você menciona, é uma questão de troca. O meu é um experimento para verificar como Next.js pode ser usado com uma configuração diferente.

Muito código no lado do cliente

Qualquer pacote moderno pode dividir os ativos do cliente em partes e react-router rotas s√£o, na verdade, pontos de divis√£o muito convenientes.

Tempos de build de desenvolvimento mais altos

√Č um pre√ßo a pagar por um grande projeto, mas nada que n√£o possa ser resolvido com um ajuste fino do webpack adequado.

Sem exporta√ß√Ķes est√°ticas

Concordo que as exporta√ß√Ķes est√°ticas s√£o uma camada de otimiza√ß√£o importante. A maioria das p√°ginas servidas por um aplicativo Next.js comum precisa recuperar dados din√Ęmicos de qualquer maneira e n√£o pode se beneficiar das exporta√ß√Ķes est√°ticas.

N√£o faltam solu√ß√Ķes para esta preocupa√ß√£o. Por exemplo. ainda pode ser poss√≠vel declarar manualmente uma lista de rotas a serem exportadas estaticamente

O motivo pelo qual escondi o comentário é que este é um problema de alto tráfego e não reflete nossa recomendação para a construção de aplicativos Next.js. Se alguém acabar aqui procurando usar o react-router, acabará usando cegamente o seu exemplo e não investigando como configurar o roteamento corretamente usando Next.js.

√Č um pre√ßo a pagar por um grande projeto, mas nada que n√£o possa ser resolvido com um ajuste fino do webpack adequado.

Voc√™ n√£o pode acelerar a inicializa√ß√£o em tempo de desenvolvimento com base em sua abordagem, n√£o h√° um ajuste fino espec√≠fico da configura√ß√£o do webpack, pois o webpack apenas compilar√° e observar√° cada rota que voc√™ importar, o que diminui enormemente as edi√ß√Ķes de componentes comuns. Da√≠ porque Next.js tem entradas sob demanda: https://nextjs.org/blog/next-8#improved -on-demand-entries

Além disso, há uma pré-busca (automática) de rotas, etc. Há muitos detalhes que eu poderia entrar aqui, mas o tldr é que você acabará com uma experiência de desenvolvedor e aplicativo piores.

N√£o me importo de revelar o coment√°rio se ele refletir corretamente que a √ļnica vez que voc√™ deseja us√°-lo √© migrar um aplicativo que j√° est√° usando o react-router e, em seguida, mover gradualmente para v√°rias p√°ginas.

Ei @timneutkens
Voc√™ contaria alguns dos pr√≥s que serem estaticamente analis√°veis ‚Äč‚Äčtrazem para a mesa e n√£o s√£o poss√≠veis com as solu√ß√Ķes de roteamento din√Ęmico?

Eu li todos os comentários e ainda não estou claro se RR4 + será incluído ou opcional na iteração futura de next.js. O roteiro de um roteador ou algo semelhante?

@laurencefass parece que n√£o h√° nenhum plano para apoiar react-router (a partir de hoje).

Para mim, o sistema de roteamento do Next.js est√° se tornando maduro o suficiente, ent√£o provavelmente n√£o precisamos dele (mais) de qualquer maneira :)

"Para mim, o sistema de roteamento do Next.js est√° se tornando maduro o suficiente, ent√£o provavelmente n√£o precisamos (mais) dele de qualquer maneira :)"

Exceto para aqueles que buscam adotar o Next.js de forma incremental em uma base de c√≥digo existente. Acho que a discuss√£o mais √ļtil provavelmente n√£o √© "roteamento Next.js vs roteamento react-router". Acho que a discuss√£o mais √ļtil √© "como posso migrar um aplicativo enorme usando o react-router para Next.js, de forma incremental?"

O roteador da Next n√£o tem a capacidade de aninhar visualiza√ß√Ķes de rota, n√£o √©? Cada navega√ß√£o para uma rota elimina o DOM e o atualiza. Visualiza√ß√Ķes aninhadas s√£o um requisito bastante comum.

@dbbk Ouvi dizer que a equipe do nextjs est√° trabalhando nisso.

next js é bastante flexível com roteadores. https://dev.to/toomuchdesign/next-js-react-router-2kl8

Estou movendo um site de c√≥digos JS e jQuery normais para React. Ao contr√°rio dos c√≥digos antigos, preciso evitar que a m√ļsica pare ao mudar de p√°gina, ent√£o usei o React Router para isso.

Agora, para fins de SEO, como tenho bons tráfegos da Pesquisa Google, preciso mantê-los. Então, eu preferiria SSR com Next.js para melhor desempenho.

Se Next.js √© capaz de renderizar uma p√°gina no lado do servidor e, em seguida, uma vez que a p√°gina carrega no lado do cliente, Next.js permitiria a navega√ß√£o sob o controle React Router, de modo que se o usu√°rio estiver ouvindo m√ļsica, o link Next.js ganhar√° ' Preciso sair da p√°gina atual para interromper a m√ļsica?

O Next.js pode fazer o roteamento do lado do cliente apenas?

Se a integra√ß√£o do React Router puder resolver isso, ent√£o estou dentro. Porque a reprodu√ß√£o cont√≠nua de m√ļsica √© uma obriga√ß√£o para mim quando o aplicativo chega ao lado do cliente.

next js é bastante flexível com roteadores. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , essa é uma abordagem muito boa, eu li antes. E o artigo diz que a equipe Next.js não recomenda, não sei por quê. Mas me parece bom

@KeitelDOG você não precisa do

_edit: Vou apenas adicionar isto: talvez a √ļnica vantagem do react-router sejam as rotas aninhadas f√°ceis no mesmo recurso de visualiza√ß√£o, o roteador Next.js deve resolver 95% dos seus casos de uso_

@martpie Obrigado pela resposta, foi o que vi ontem à noite com o componente Link . Então Next.js é a combinação de servidor-cliente que eu queria.

E para um componente que controla granularmente suas pr√≥prias rotas aninhadas dinamicamente, eu realmente gosto disso com o React Router. Mas tenho quase certeza de que posso encontrar uma solu√ß√£o alternativa, porque n√£o estou mudando um site React para Next.js, mas sim planejando e testando para mudar um site JS - jQuery para um aplicativo React de m√ļltiplas p√°ginas sem perder minhas vantagens de SEO no Google. Ent√£o, acho que devo ir com Next.js

@timneutkens algum plano para suportar isso no Next.js 10?

@TrejGun obrigado, isso definitivamente n√£o est√° fora do assunto.

Tem algum plano?
O next/router é ótimo, ele fornece uma grande ajuda. Mas precisamos de um roteador mais profissional para lidar com aplicativos complexos. React-router é líder em roteadores.
Talvez possa se referir a after.js .

Sim, este sistema baseado em página simplesmente não é sofisticado o suficiente para lidar com aplicativos complexos de dados que poderiam se beneficiar de rotas aninhadas.

O React-router está prestes a lançar a versão v6 , que será o melhor roteador até o momento. Estou ansioso para next.js apoiá-lo.

Uma abordagem melhor é separar next.js e router , permitindo que as pessoas escolham seus router favoritos livremente.

1 para o coment√°rio anterior. next.js √© incr√≠vel, o √ļnico motivo pelo qual n√£o estou usando √© a falta de flexibilidade no roteador. Por favor, suporte React Router 6 em vers√Ķes futuras ou torne o roteador substitu√≠vel.

Quem realmente gosta do React Router pode se interessar em acompanhar o novo projeto ‚ÄĚRemix‚ÄĚ, √© uma alternativa do Next.js que usa o React Router, dos mesmos criadores:

Acho que o problema é que a estrutura está profundamente ligada a esse roteador por causa do SSR, Props do lado do servidor, etc.

O Next foi desenvolvido com o desempenho em mente, e o reac-router do lado do servidor tem uma implica√ß√£o importante no desempenho, pois voc√™ deve percorrer a √°rvore DOM antes de saber o que tentar√° renderizar e, portanto, de quais dados precisar√°. Todo o prop√≥sito de getInitialProps √© que voc√™ n√£o tenha que fazer uma renderiza√ß√£o descart√°vel de reagir antes de buscar dados, uma armadilha comum que muitos frameworks enfrentam no servidor (e no cliente, onde se manifesta como solicitar cachoeiras). Em seguida, poderia potencialmente contornar isso fazendo com que cada p√°gina de n√≠vel superior declarasse _todos_ os v√°rios padr√Ķes de dados de que seus v√°rios subcomponentes podem precisar e se ramificassem no caminho de solicita√ß√£o completo (ou fazer um √ļnico overfetch massivo), mas isso ficaria complicado rapidamente e n√£o seria t√£o diferente de declarar cada p√°gina individualmente.

Este é o mesmo motivo pelo qual o Relay também não é compatível com o react-router, e você não pode acusar o facebook.com de não ser um site complexo.

A principal estratégia de sucesso para trabalhar com o roteador Next é inclinar-se para a composibilidade (que é a tendência motriz no React moderno de qualquer maneira), permitindo que você reutilize componentes sem grande duplicação ao mesmo tempo que tem um SSR eficiente que pode buscar todos os seus dados (via getInitialProps ) antes de falar com o renderizador React.

Sinto como se a penalidade de desempenho de andar na árvore fosse exagerada. Muitos aplicativos de produção hoje estão fazendo isso, por exemplo, com o Apollo e parece estar bem.

Além disso, você também pode armazenar em cache as respostas do CDN se realmente quiser aliviar o servidor de fazer muito trabalho.

Claro, estou apenas apontando o motivo principal por tr√°s do motivo pelo qual react-router √© (AFAICT) fundamentalmente incompat√≠vel com Next em sua implementa√ß√£o atual. Muitos sites realmente n√£o precisam de perfei√ß√£o, como evidenciado por pessoas que usam alegremente dinos Heroku gr√°tis com tempos de inicializa√ß√£o a frio lentos (e quero enfatizar que n√£o digo isso de forma condescendente, pois fa√ßo isso para alguns sites tamb√©m e pode ser o ajuste perfeito). Mas o Next n√£o seria popular com algumas das grandes empresas que o utilizam se fosse menos agressivo em rela√ß√£o ao desempenho, pois essas empresas se preocupariam com o fato de os tempos de resposta do servidor serem consideravelmente mais lentos. Se n√£o fosse uma preocupa√ß√£o para alguns sites, as pessoas n√£o usariam (e aguardariam ansiosamente por melhorias) o renderizador de streaming do React para come√ßar a responder antes mesmo de uma √ļnica renderiza√ß√£o ser conclu√≠da, quanto mais duas.

Definitivamente, voc√™ pode armazenar em cache as respostas do CDN, mas isso elimina muitas op√ß√Ķes de personaliza√ß√£o / login (j√° que √© uma troca com o qu√£o baixo voc√™ deseja direcionar sua taxa de acertos ou adiar a renderiza√ß√£o parcial da p√°gina para o cliente). Se voc√™ pode armazenar em cache CDN todo o seu aplicativo, seria melhor usar CRA e react-snapshot e evitar servidores totalmente. N√£o √© necessariamente uma quest√£o de quanto trabalho seu servidor est√° fazendo, mas sim de quanto tempo leva para responder a uma solicita√ß√£o.

E o Apollo √© um √≥timo exemplo de uma estrutura que enfatiza a facilidade de uso sobre o desempenho, em compara√ß√£o com uma estrutura mais opinativa / orientada para o desempenho como o Relay. √Č tudo um espectro.

Sim, acho que isso é justo. Mas estou curioso para ver como será o resultado do remix.run, talvez eles venham com uma nova abordagem para fazê-lo funcionar com react-router . Sim, é verdade que as rotas aninhadas não são obrigatórias, mas certamente você deve concordar que é mais intuitivo ter partes da IU interna mudando com a rota do que ter páginas diferentes e envolver cada uma dessas páginas com layouts diferentes.

A partir do pr√≥ximo 9.3, h√° getStaticPaths al√©m de getServerSideProps para ajudar a estrutura a descobrir caminhos para pr√©-renderizar quando o caminho tem par√Ęmetros de rota. Talvez uma abordagem semelhante possa ser adotada com o roteador react.

@merryweather: "Next é construído com desempenho em mente, e do lado do servidor reagem-router tem uma implicação importante desempenho em que você deve percorrer a árvore DOM antes de saber o que você vai tentar render"

Pergunta ingênua: você pode apenas renderizar links de nível superior e buscar / pré-buscar / armazenar em cache uma vez que o código está sendo executado no cliente. Se você não sabe onde o cliente irá navegar, faz sentido atravessar a árvore DOM no servidor?

Cen√°rio de trabalho ing√™nuo: quando o cliente solicita uma URL, apenas renderiza os links de n√≠vel superior e o conte√ļdo do link ativo padr√£o e ajax / busca tudo o mais mediante solicita√ß√£o (ou pr√©-busca em segundo plano assim que a p√°gina √© carregada) ... tudo o resto inclui todos os n√≠veis inferiores rotas ... enx√°gue e repita ...?

@laurencefass, mas mesmo os links de nível superior estão em código e devem ser descobertos, certo? Ou você pretende usar o roteamento do sistema de arquivos junto com o react-roteador para que os links de nível superior sejam detectáveis?

@avin-kavish N√£o sou a melhor pessoa para responder a detalhes sobre a implementa√ß√£o, mas no cliente s√≥ precisa processar o conte√ļdo da tela inicial: links de n√≠vel superior + conte√ļdo padr√£o. Qualquer outra coisa √© redundante no primeiro carregamento, eu acho. Ent√£o, por que percorrer o DOM no servidor?

O principal problema com Next.js não é o roteador, é o padrão de busca de dados com getInitialProps , getServerProps ou getStaticProps . Por quê ? Porque quebra o isolamento de dados para o componente que precisa dele. Por exemplo, você deseja obter dados para o menu, de onde irá obtê-los? Eu não sei. Componentes principais como pages não deveriam saber nada sobre isso, certo?

O principal problema com Next.js não é o roteador, é o padrão de busca de dados com getInitialProps , getServerProps ou getStaticProps . Por quê ? Porque quebra o isolamento de dados para o componente que precisa dele. Por exemplo, você deseja obter dados para o menu, de onde irá obtê-los? Eu não sei. Componentes principais como pages não deveriam saber nada sobre isso, certo?

Você poderia elaborar, por favor. E qual é a solução alternativa?

@lishine , desculpe por estar um pouco fora do assunto aqui, mas na maioria dos casos n√£o vejo o roteador como o problema principal aqui. O roteador Next.js √© bom, declarativo, a conven√ß√£o sobre a configura√ß√£o √© boa. A √ļnica coisa que n√£o posso usar no Next.js s√£o os m√©todos de busca de dados como getInitialProps , ...
Em meus aplicativos, cada componente precisará declarar seus próprios dados no mesmo lugar, no mesmo arquivo, seja ele graphql ou resto.
O componente de páginas principais serve apenas para compor componentes filhos, e buscar dados não é seu trabalho. O componente filho deve obter dados de si mesmo, não de seus pais.

Aqui está meu exemplo de código que estou usando para meu aplicativo para maior clareza:

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

Como você pode ver, você tem um componente com seus próprios dados. Você pode colocá-lo onde quiser.

Claro, você pode usar o padrão Next.js sem nenhum problema, mas, no meu caso, prefiro o isolamento de dados e componentes o máximo possível para facilitar a manutenção e refatoração posteriormente.

Em meus aplicativos, cada componente precisará declarar seus próprios dados no mesmo lugar, no mesmo arquivo, seja ele graphql ou resto.
O componente de páginas principais serve apenas para compor componentes filhos, e buscar dados não é seu trabalho. O componente filho deve obter dados de si mesmo, não de seus pais.

Eu uso da mesma maneira.
Portanto, você não está usando a busca de SSR ...
Ent√£o, como as pessoas realmente fazem a busca de SSR com Next.js?!

@linshine , temos que baixar tudo o que precisamos no nível da página superior.

@lishine , desculpe por estar um pouco fora do assunto aqui, mas na maioria dos casos n√£o vejo o roteador como o problema principal aqui. O roteador Next.js √© bom, declarativo, a conven√ß√£o sobre a configura√ß√£o √© boa. A √ļnica coisa que n√£o posso usar no Next.js s√£o os m√©todos de busca de dados como getInitialProps , ...
Em meus aplicativos, cada componente precisará declarar seus próprios dados no mesmo lugar, no mesmo arquivo, seja ele graphql ou resto.
O componente de páginas principais serve apenas para compor componentes filhos, e buscar dados não é seu trabalho. O componente filho deve obter dados de si mesmo, não de seus pais.

Aqui está meu exemplo de código que estou usando para meu aplicativo para maior clareza:

...

Como você pode ver, você tem um componente com seus próprios dados. Você pode colocá-lo onde quiser.

Claro, você pode usar o padrão Next.js sem nenhum problema, mas, no meu caso, prefiro o isolamento de dados e componentes o máximo possível para facilitar a manutenção e refatoração posteriormente.

@ revskill10 Por que você não pode fazer com que o filho declare seu fragmento de dados e, em seguida, faça com que o pai inclua esse fragmento na consulta de nível superior? Especialmente ao criar mais fragmentos associados a filhos, você tem um isolamento de dados perfeito. Ter uma consulta pai com um fragmento filho não é diferente de ter esse filho declarado em JSX, então você tem o mesmo nível de acoplamento, mas evita cascatas de solicitação (muito mais difícil em REST, infelizmente).

Temos um aplicativo Relay-Next e esse padrão funciona perfeitamente, com encapsulamento de dados e composição reutilizável, e alavancamos getInitialProps com facilidade.

@merrywhether Sem mencionar sobre much harder in REST , sua abordagem tem o problema de que você não pode decidir qual fragments será SSG / SSR ou será CSR.
Na minha abordagem, é tão fácil quanto importar aquele componente com { noSSR: true/false} .

Acho extremamente preocupante o aprisionamento a uma biblioteca de roteamento específica do fornecedor que não compartilha uma implementação subjacente com nenhuma biblioteca de roteamento principal.

Recentemente, fiz uma revis√£o do Next.js para avaliar se ele deve ser usado como base para o n√ļcleo comum compartilhado entre v√°rios aplicativos de front-end que est√£o sendo desenvolvidos para nosso cliente atual. Embora Next.js tenha potencial; esse roteador √© um dos principais motivos pelos quais acabei rejeitando o Next.js e, em vez disso, mantendo o CRA como base para esses aplicativos.

Eu entendo a dificuldade de usar a API de n√≠vel superior baseada em componente de react-router / @reach/router como base para SSR. Mas esse n√£o √© um bom motivo para a implementa√ß√£o subjacente ser totalmente customizada. O SSG de Gatsby tem as mesmas preocupa√ß√Ķes que Next.js e uma estrutura de roteamento baseada em arquivo semi-semelhante; mas, no meu entendimento, Gatsby usa @reach/router sob o cap√ī para alimentar sua implementa√ß√£o de roteamento em vez de reinventar a roda ou expor uma API de link que √© incongruente com a API de link usada por outras bibliotecas.

@dantman, posso perguntar o que você escolheu para a alternativa Next.js. Assumindo que você precisava de renderização do lado do servidor ... Tenho experimentado o After.js, talvez ele possa fornecer alguma inspiração / idéias de como implementar no Next.js se não for suportado pelo zeit.

@dantman, posso perguntar o que você escolheu para a alternativa Next.js. Assumindo que você precisava de renderização do lado do servidor ... Tenho experimentado o After.js, talvez ele possa fornecer alguma inspiração / idéias de como implementar no Next.js se não for suportado pelo zeit.

Desculpe, n√£o tenho uma resposta √ļtil para voc√™. O SSR n√£o era um requisito dif√≠cil, ent√£o continuamos usando o CRA, com o qual o prot√≥tipo foi constru√≠do.

Achei que Next.js prometia ser uma estrutura universal, j√° que recentemente ganhou a capacidade de ter uma combina√ß√£o de p√°ginas SSR / SSG / somente cliente e podia ser executado como um aplicativo isom√≥rfico ou est√°tico / PWA. A customiza√ß√£o do WebPack era tentadora porque o CRA vinha dificultando o uso do globalize-compiler. O servidor Next.js foi neutro / positivo porque precis√°vamos de um servidor API de qualquer maneira para uma ponte GraphQL / REST. E a op√ß√£o de SSR / SSG foi positiva, j√° que estou construindo o n√ļcleo em que meia d√ļzia de aplicativos ser√° baseada e n√£o √© imposs√≠vel que possa acabar sendo √ļtil no futuro. No entanto, tamb√©m tive alguns problemas com a maneira como o SSR do Next.js funciona e esses aspectos positivos n√£o compensaram o problema causado pelo roteador.

@dantman

Acho extremamente preocupante o aprisionamento a uma biblioteca de roteamento específica do fornecedor que não compartilha uma implementação subjacente com nenhuma biblioteca de roteamento principal.

√Č muito estranho qualificar um componente de c√≥digo aberto com uma API que n√£o mudou em 3 anos devido √† sua grande estabilidade e ‚Äúadequa√ß√£o ao produto / mercado‚ÄĚ como ‚Äúbloqueio‚ÄĚ

Next.js teve sucesso e continua a mostrar o crescimento que faz por causa de seu roteador e n√£o apesar dele.

Como muitos me viram comentar no Twitter, uma vez n√≥s consideramos seriamente a fus√£o em algum roteador (embora eu esteja confuso quanto a qual deles √© o padr√£o em sua mente, Reach ou React Router, e em qual vers√£o principal). Mas o mundo nos puxou para outras dire√ß√Ķes interessantes. Na realidade, nem sab√≠amos qual era o objetivo de adicion√°-lo, porque todos continuaram tendo sucesso com Next.js e construindo produtos maravilhosos.

Quando eu de fato perguntava √†s pessoas por que elas queriam uma API de roteador diferente, o motivo que surgia com mais frequ√™ncia √© porque as pessoas estavam presas e frustradas com solu√ß√Ķes de estrutura desenvolvidas em casa constru√≠das em um roteador e mal podiam esperar para migrar para o Next . N√£o era um motivo enraizado no design do produto.

Quando digo que o Next teve sucesso por causa do roteador, é porque eliminou dois problemas:
1ÔłŹ‚É£ A ideia de ter que escolher um roteador . Remover isso √©, em retrospecto, uma excelente decis√£o. Em todo o tempo que Next.js com seu roteador est√°vel existiu, o mundo do roteador se dividiu e lan√ßou todos os tipos de mudan√ßas de API

2ÔłŹ‚É£ A curva de aprendizado de um roteador . Muitos workshops e tutoriais foram dados sobre roteamento, mas o roteamento do sistema de arquivos Next.js leva 2 segundos para explicar e oferece a plataforma para construir coisas incr√≠veis, e voc√™ segue direto para o desenvolvimento de produtos

Eu quero enfatizar este √ļltimo ponto. Considere um dos sites mais novos e de crescimento mais r√°pido do mundo, TikTok.com, criado em Next.js. Toda a topologia de roteamento desse site pode ser explicada com aquela curva de aprendizado de dois segundos. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 √© pages/[user]/video/[id].js e https://www.tiktok.com/trending √© pages/trending.js

Muitas das inova√ß√Ķes recentes do Next.js de que voc√™ mencionou, como o h√≠brido est√°tico / SSG / SSR, tamb√©m s√£o habilitadas pelo design do nosso roteador. Na verdade, o roteador tamb√©m permitir√° muitas outras otimiza√ß√Ķes semelhantes que vir√£o no futuro para entregar menos JS aos clientes.

No entanto, também tive alguns problemas com a maneira como o SSR do Next.js funciona e esses aspectos positivos não compensaram o problema causado pelo roteador.

Adoraria ouvir sobre isso. O exemplo acima é baseado em Next.js híbrido estático / SSR e vemos muito sucesso com ele em toda a linha!

Este √© um t√≥pico t√£o engra√ßado. O Next tem raz√Ķes concretas para evitar o roteamento em cascata (tamb√©m conhecido como react-router e amigos), pois getInitialProps permite muitas otimiza√ß√Ķes de desempenho, e a abordagem do Next est√° se tornando bastante popular, especialmente porque algumas pessoas desejam especificamente essas otimiza√ß√Ķes. O desempenho vem com compensa√ß√Ķes de design, e √†s vezes voc√™ pode preferir escolher o design ao inv√©s do desempenho, mas isso n√£o torna a ferramenta errada, apenas errada para voc√™ para um projeto espec√≠fico.

Em √ļltima an√°lise, o react-router n√£o √© a solu√ß√£o para todo o encaminhamento. Ele tem seus pr√≥s e contras, assim como o Next. FWIW, o Facebook n√£o usa o react-router e provavelmente sabem uma ou duas coisas sobre como usar o React. Portanto, n√£o h√° problema em ter alternativas e, na verdade, uma das grandes coisas sobre o ecossistema JS: deixe coisas diferentes competirem na arena de ideias e, no final das contas, todos n√≥s seguiremos em frente.

J√° que estou encerrando o problema, quero deixar claro que estamos sempre abertos a coment√°rios, solicita√ß√Ķes de recursos e relat√≥rios de erros sobre os recursos de roteamento.

Idealmente, esses seriam orientados pelo produto (‚ÄúEu preciso fazer X, mas n√£o √© poss√≠vel‚ÄĚ ou ‚ÄúY √© poss√≠vel, mas n√£o ergon√īmico‚ÄĚ). Estamos sempre em busca de melhorias que ajudem voc√™ a fazer sites e aplicativos enxutos com √≥timas experi√™ncias de usu√°rio ūü§ó

@rauchg Você pode explicar a razão de ter dois adereços, href e as em um link? Por que ele não pode inferir a página pretendida com base no valor de as prop?

Por exemplo, em expresso, se eu tiver uma rota como /blog/:slug , posso simplesmente enviar uma solicitação http para /blog/hello-world e esperar que o roteador faça a rota para ela. Não tenho que enviar /blog/:slug e blog/hello-world para o servidor.

@avin-kavish, essa é uma ótima pergunta. Há uma distinção importante a ser feita entre o que o URL exibe e qual página deve ser carregada. Na verdade, o TikTok usa isso para renderizar certas coisas em modais, que quando você atualiza a página se tornam outras páginas. No entanto, uma grande área de melhoria aqui é que talvez devêssemos impor estaticamente que você está referenciando uma página válida que existe no sistema de arquivos. Continuaremos criando uma discussão sobre isso e marcando você!

Acho que j√° existe um problema para esse https://github.com/zeit/next.js/issues/8207

Caso alguém tenha observado esse problema para um recurso de roteador de reação, como "rotas aninhadas", que permite navegar para novas páginas sem renderizar novamente tudo como eu estava, há na verdade um problema dedicado que você pode observar e votar. Acabei de descobrir sobre esse: https://github.com/zeit/next.js/issues/8193

@rauchg

Para deixar claro, meu problema principal n√£o √© a falta de uma API de componente de estilo RR / alcance, estou bem com uma API baseada em arquivo / configura√ß√£o compat√≠vel com SSR. Embora eu esteja um pouco otimista que no futuro o Suspense possa tornar vi√°vel APIs de SSR / roteamento alternativos. Meu principal problema √© o roteador ser totalmente personalizado, com quaisquer preocupa√ß√Ķes comuns na implementa√ß√£o sendo reimplementadas em vez de compartilhado com qualquer parte da comunidade React mais ampla.

Acho a abordagem de Gatsby aceitável. Eles têm uma API de roteamento baseada em arquivo + configuração compatível com SSG e exportam seu próprio componente de Link aprimorado; mas eles usam @reach/router para alimentar a implementação subjacente.

Acho extremamente preocupante o aprisionamento a uma biblioteca de roteamento específica do fornecedor que não compartilha uma implementação subjacente com nenhuma biblioteca de roteamento principal.

√Č muito estranho qualificar um componente de c√≥digo aberto com uma API que n√£o mudou em 3 anos devido √† sua grande estabilidade e ‚Äúadequa√ß√£o ao produto / mercado‚ÄĚ como ‚Äúbloqueio‚ÄĚ

O roteador está intrinsecamente ligado ao Next.js. Adotar Next.js por um motivo significa estar vinculado ao roteador. Se adotarmos Next.js e depois descobrirmos que next / router tem uma limitação que acaba sendo incapacitante para algo que estamos tentando fazer, não há absolutamente nenhuma saída de emergência razoável. "Lock-in" é um descritor perfeitamente adequado para isso.

O aprisionamento sozinho não seria um grande problema. O uso de @reach/router Gatsby também seria lock-in. Mas @reach/router é usado fora apenas de Gatsby. Não preciso confiar apenas na comunidade Gatsby para manter toda a pilha de roteadores; Posso confiar que uma comunidade maior depende dele e há mais partes interessadas envolvidas (específicas para a pilha de roteamento) para garantir que seja mantido, acompanhe os problemas de roteamento difíceis (por exemplo, acessibilidade) e seja dependente de uma comunidade mais ampla e variada que provavelmente compartilhará quaisquer problemas potencialmente incapacitantes que possamos encontrar no futuro.

embora eu esteja confuso sobre qual é o padrão em sua mente, Reach ou React Router, e em qual versão principal

Em termos do padrão de fato de como <Link> deve se parecer. O Reach e o React Router (RR) compartilham APIs muito semelhantes. por exemplo, <Link to='/about'>About</Link> é válido em RR e Reach (e, claro, por extensão Gatsby). O que torna o idiossincrático <Link href='/about'><a>About</a></Link> Next.js muito mais chocante.

Em termos do que acho que o Next.js deve usar. Não estou vinculado a uma biblioteca específica, se Next.js já estivesse usando uma, eu não sugeriria mudar para outra. Minha maior preocupação é que a implementação de roteamento seja compartilhada com uma biblioteca com uma comunidade mais ampla fora do Next.js.

Na prática, porém, isso é relativamente discutível. Até agora eu não vi nenhum roteador React além de RR e Reach com uma grande base de usuários. E RR e Reach vão se tornar uma biblioteca, então o que você começar com o resultado final será o mesmo.

Tentei Next há um tempo, mas a falta de flexibilidade no roteador me levou a descobrir uma implementação Razzle chamada After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com.

Como o React Router é apenas um pacote, não podemos importá-lo e limitar a renderização para o lado do cliente apenas para que funcione como um SPA onde é necessário e nos forneça rotas de componentes aninhados? O roteador React não é apenas um conjunto de componentes a serem (potencialmente) incorporados nas páginas e carregados com o roteador de páginas Next.js como qualquer outro componente?

Eu li em tópicos anteriores que zeit planeja integrar RR. Isso ainda é verdade hoje?

Por que n√£o permitimos rotas aninhadas no roteador next.js como √ļltimo recurso e deixamos claro que essas √°reas n√£o ser√£o pr√©-renderizadas. No m√≠nimo, isso nos poupar√° o esfor√ßo de ter que evitar escrever as condi√ß√Ķes if que inevitavelmente temos que escrever quando queremos que um sub-recurso na p√°gina seja alterado com base na rota.

Estou adicionando meu voto sobre esta quest√£o.

Outro pro, não mencionado, é que o RR é mais testável, (AFAIK não há API nextjs oficial para teste de roteador), tem MemoryRouter para empacotar testes e histórias.

Next.js tem muitos recursos bons (WebPack autom√°tico, arquivos est√°ticos e TypeScript como CRA, mas para mais do que apenas PWAs; rotas de API; suporte sem servidor, atualiza√ß√£o r√°pida e at√© suporte experimental de Expo para web + aplicativos nativos) e um n√ļcleo para SSR e SSG, mesmo que a API n√£o seja boa. Mas enquanto o sistema de roteamento embutido e SSR / SSG funcionam para alguns; para outros, eles prejudicam o desenvolvimento porque os limites de ambas as APIs oferecem as compensa√ß√Ķes erradas para o referido projeto.

Que tal um compromisso. Next.js j√° tem plugins. Em vez de substituir o roteador internamente, e se separ√°ssemos o roteador e a API SSR (ou seja, getStaticProps / getServerSideProps nos arquivos de rota) do n√ļcleo do Next.js. Por exemplo, poder√≠amos colocar as partes essenciais do n√ļcleo em @next/core e mover o roteador opinativo atual e get*Props APIs para @next/router . Para simplicidade e compatibilidade com vers√Ķes anteriores, next pode ser uma estrutura que reexporta @next/core e vem pr√©-configurada com o roteador preferido da Vercel. Mas ent√£o seria poss√≠vel para a comunidade desenvolver roteadores e APIs SSR / SSG com diferentes compensa√ß√Ķes que s√£o mais adequadas para projetos que, de outra forma, estariam presos jogando fora as partes boas do Next.js com a √°gua do banho.

Algumas ideias sobre o que o n√ļcleo Next.js requer que o plug-in do roteador forne√ßa:

  • Dada uma solicita√ß√£o {url, corpo, etc}, o n√ļcleo esperaria que o plug-in do roteador renderizasse essa solicita√ß√£o para um documento (string ou streaming) ou emitisse uma resposta (ou seja, 404 ou redirecionamento).
  • Na exporta√ß√£o, o n√ļcleo espera que o plug-in do roteador forne√ßa uma lista de p√°ginas que precisam ser renderizadas.

@next/router provavelmente implementaria os mesmos padr√Ķes por meio da API, fazendo coisas como:

  • Dado um pedido, identificando o arquivo de rota respons√°vel e processando normalmente
  • No cliente, fazendo algo semelhante a tudo o que faz atualmente para saber quando chamar a API SSR e renderizar a rota necess√°ria (possivelmente movendo a API SSR baseada em API para uma rota de API de apar√™ncia normal)
  • Na exporta√ß√£o usando a √°rvore de arquivos de p√°ginas e getStaticPaths para fornecer a lista de p√°ginas est√°ticas

Eu provavelmente poderia me imaginar experimentando um plugin de roteador usando React Router v6 com @apollo/react-ssr e Suspense com react-ssr-prepass ou react@experimental . Que renuncia às rotas somente SSR para rotas SSR isomórficas e implementa SSR / SSG sem uma API de estilo get*Props restrição.

O que percebi é que o roteamento aninhado + SSG pode ser alcançado sem quebrar a API atual. Portanto, temos getStaticPaths no momento, podemos usar isso para sugerir rotas aninhadas para pré-renderização. Por exemplo,

Dada uma rota /foo/[...slug] ,

function FooPage() {

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

pode ser pré-renderizado com,

export async function getStaticPaths() {

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

Do jeito que est√° no momento next.js √© como uma estrutura do lado do servidor com a conveni√™ncia de criar p√°ginas no react. N√£o parece t√£o poderoso quanto react-router . O roteamento baseado em diret√≥rio pode ter seu lugar na constru√ß√£o de sites voltados para o consumidor, como o tiktok, conforme mencionado antes, mas para portais de aplicativos baseados em dados complexos, o roteamento aninhado ainda √© rei. √Č por isso que os aplicativos de p√°gina √ļnica foram criados em primeiro lugar, ele permite a altera√ß√£o de bits da IU sem ter que substituir a p√°gina inteira. Isso pode ser aproveitado para modelar relacionamentos entre recursos e sub-recursos de maneira bastante conveniente. Da forma como est√°, posso usar next.js se for criar as p√°ginas p√ļblicas de um site de consumidor, como um site de com√©rcio eletr√īnico, mas quando precisar criar as √°reas privadas, como portais de administrador, comprador e vendedor, eu o faria mudar para CRA.

@avin-kavish, o principal problema não é fazê-lo funcionar, mas torná-lo otimizado: cada página no Next.js default tem seu próprio pacote e são otimizados para velocidade.

Se voc√™ come√ßar a adicionar muito conte√ļdo / subconte√ļdo em uma √ļnica p√°gina como fez, pode acabar com um pacote bem grande no final (o que n√£o √© "terr√≠vel" por si s√≥, mas voc√™ deve apenas estar ciente do trade-offs). Voc√™ pode ser capaz de fazer alguma otimiza√ß√£o manual com next/dynamic pensamento :)

@rauchg a √ļnica dimens√£o n√£o √© se o pr√≥ximo roteador √© bom ou ruim. Outra coisa muito importante √© a migra√ß√£o de e para o next.js e o suporte da comunidade, e https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 coloc√°-lo bem. Next.js √© uma boa solu√ß√£o para abstrair muito do clich√™ que um aplicativo SSR de alta qualidade precisa e, como tal, √© um destino de migra√ß√£o muito convidativo para muitos aplicativos da web. O problema agora √© que seria necess√°ria uma reescrita completa do roteamento tanto para migrar para next.js quanto para retir√°-lo, se necess√°rio.

O roteamento plug√°vel sugerido por

O problema com o react-router (e qualquer solução de roteamento aninhado) é que ele torna a análise estática muito mais difícil porque os caminhos de código relevantes para qualquer URL específico não estão disponíveis sem executar (ou simular) o próprio código. Em seguida, é mais do que apenas uma estrutura de "colocar IU em uma página da web", que é o motivo pelo qual, por exemplo, eles trabalharam com a equipe do Chrome na criação de estratégias de agrupamento mais otimizadas.

Os usu√°rios do react-router est√£o acostumados a usar o react-loadable diretamente, pois o rr delega essa responsabilidade inteiramente aos usu√°rios finais, mas o Next tenta abstrair e automatizar isso, o que n√£o √© f√°cil. A abordagem de roteador plug√°vel proposta provavelmente teria que envolver plug-ins de roteador fornecendo informa√ß√Ķes extensas em tempo de constru√ß√£o para a estrutura a fim de atingir o mesmo tipo de sa√≠da, j√° que cada roteador teria que saber como gerar tais informa√ß√Ķes com base em seus pr√≥prios padr√Ķes.

Puramente especula√ß√£o, mas eu imagino que muitas coisas est√£o no limbo enquanto o React termina o Suspense, j√° que criar um padr√£o de primeira classe na biblioteca afetar√° muito todas as bibliotecas do roteador e tamb√©m fornecer√° uma base concreta sobre a qual construir ass√≠ncronos / carreg√°veis padr√Ķes de pacote.

Resumindo a hist√≥ria / um bom resumo abaixo: N√£o existe uma solu√ß√£o "tamanho √ļnico". Tudo tem vantagens e desvantagens. Cada "vantagem" da maneira como o Next.js faz as coisas atualmente tem uma desvantagem. Quais s√£o as vantagens / desvantagens mais importantes √© algo que √© diferente para cada projeto. Portanto, a recomenda√ß√£o para uma arquitetura de roteador / ssg / ssr conect√°vel. Projetos diferentes precisam de coisas diferentes e, no momento, o Next.js s√≥ funciona para os projetos cuja prioridade nas compensa√ß√Ķes est√° alinhada com a maneira como as coisas s√£o codificadas no Next.js.

O problema com o react-router (e qualquer solução de roteamento aninhado) é que ele torna a análise estática muito mais difícil porque os caminhos de código relevantes para qualquer URL específico não estão disponíveis sem executar (ou simular) o próprio código.

Honestamente, isso s√≥ importa se voc√™ estiver usando SSG e tiver um monte de rotas n√£o din√Ęmicas. Se todas as suas rotas forem SSG ou somente cliente, isso n√£o ser√° √ļtil. E se a maioria de suas rotas s√£o din√Ęmicas, voc√™ deve declar√°-las explicitamente usando getStaticPaths qualquer maneira. O que seria a mesma quantidade de trabalho que definir explicitamente as rotas em um plugin Next.js hipot√©tico que usa apenas react-router bruto sem modifica√ß√£o e pede que voc√™ defina explicitamente as rotas est√°ticas.

√Č uma vantagem certa e algumas equipes v√£o querer isso. No entanto, esse √© apenas um subgrupo de usu√°rios potenciais do Next.js. Existem outros grupos que podem querer algumas das vantagens que o RR ou outra biblioteca de roteamento oferece e a necessidade de declarar explicitamente as rotas est√°ticas √© uma troca aceit√°vel ou um problema. Por exemplo, meus √ļltimos projetos foram o tipo de aplicativos B2B / B2C em que 100% das coisas est√£o atr√°s de uma p√°gina de login e n√£o h√° por que renderizar estaticamente nada disso. Next.js tem algumas vantagens sobre o CRA que tornariam o Next.js prefer√≠vel; Mas coisas como o roteador eram grandes bandeiras vermelhas e continuamos usando o CRA. Esses projetos teriam sido muito adequados para um Next.js com react-router bruto.

Isso tamb√©m pressup√Ķe que todos que n√£o desejam next/router desejam usar a forma JSX de react-router. Esse n√£o √© o √ļnico tipo de alternativa next/router .

Um outro tipo de roteador seria o estilo Gatsby.js. Onde um projeto ainda usa uma estrutura de páginas baseada em sistema de arquivos, mas os internos são implementados com outra biblioteca de roteamento como react-router (Gatsby usa @reach/router internamente). Esse tipo de plugin de roteador daria a você as mesmas vantagens de análise estática. Mas também daria a você quaisquer vantagens que o roteador alternativo não tenha relacionado ao roteamento aninhado. Por exemplo, acomodar preferências potenciais para API de rota, melhor manuseio de acessibilidade, melhor integração no ecossistema em torno desse roteador.

E, claro, mesmo dentro do ecossistema do roteador react, a forma JSX n√£o √© a √ļnica maneira de usar o roteador react. Tamb√©m existe react-router-config . O que √© f√°cil de fazer an√°lise est√°tica e tamb√©m suporta roteamento aninhado.

Os usuários do react-router estão acostumados a usar o react-loadable diretamente, pois o rr delega essa responsabilidade inteiramente aos usuários finais, mas o Next tenta abstrair e automatizar isso, o que não é fácil.

E alguns de n√≥s est√£o bem em lidar com a divis√£o de c√≥digo por conta pr√≥pria. O roteamento aninhado pode ser mais importante para um projeto do que a divis√£o autom√°tica de c√≥digo. √Č tudo uma quest√£o de quais trade offs s√£o mais adequados para um projeto.

Isso é mais uma observação lateral, mas estou curioso sobre o potencial de um plug-in babel / webpack que faria isso automaticamente para rotas.

Também é uma biblioteca reativa-carregável efetivamente extinta (2 anos desde a publicação, não aceitando relatórios de bug). Pessoalmente, prefiro fazer a divisão de código manualmente com @loadable/components que usar algo automático integrado ao Next.js com base em um fork interno do react-loadable.

A abordagem de roteador plug√°vel proposta provavelmente teria que envolver plug-ins de roteador fornecendo informa√ß√Ķes extensas em tempo de constru√ß√£o para a estrutura a fim de atingir o mesmo tipo de sa√≠da, j√° que cada roteador teria que saber como gerar tais informa√ß√Ķes com base em seus pr√≥prios padr√Ķes.

Sim. Geralmente √© assim que um sistema de plugins funcionaria. Honestamente, o fato de que esse tipo de informa√ß√£o pode ser fornecido pelo plugin √© uma vantagem, n√£o um problema. Ter isso em um plug-in significa que, caso a forma como o Next.js coleta essas informa√ß√Ķes n√£o seja adequada para alguns tipos de necessidades de projetos, ele pode ser substitu√≠do por um que atenda √†s necessidades desses projetos. Mas sem a necessidade de bifurcar e reescrever todo o Next.js para fazer isso.

Puramente especula√ß√£o, mas eu imagino que muitas coisas est√£o no limbo enquanto o React termina o Suspense, j√° que criar um padr√£o de primeira classe na biblioteca afetar√° muito todas as bibliotecas do roteador e tamb√©m fornecer√° uma base concreta sobre a qual construir ass√≠ncronos / carreg√°veis padr√Ķes de pacote.

Isso por si só poderia ser um bom argumento para trabalhar em um sistema de roteador conectável. No momento, como todo o roteamento e SSR estão codificados no Next.js, não é possível fazer facilmente a experimentação em qualquer tipo de sistema de roteamento futuro no Next.js. Como o Suspense afeta o roteamento do Next.js e outras bibliotecas de roteamento? Não é algo que você possa experimentar (pelo menos em relação ao SSR e agrupamento do Next.js) sem bifurcar e reescrever partes do Next.js.

Plugins de roteador seriam um ótimo lugar para fazer esse tipo de experimentação. Contanto que a API do plugin seja de baixo nível o suficiente, seria possível bifurcar apenas o plugin next/router e tentar escrever uma versão baseada em react @ experimental + Suspense desse roteador. E como este é um plugin (não uma bifurcação de todos Next.js), seria fácil aceitar o experimento e testar o novo roteador baseado em Suspense. Isso é importante agora, e não mais tarde, porque este tipo de experimentação é a razão pela qual o react @ experimental existe, para coletar feedback de projetos reais.

@dantman N√£o estou discordando de nada do que voc√™ disse. _Is_ tudo sobre trade-offs. A maior desvantagem √© o que a pr√≥xima equipe passa seu tempo. At√© agora, SSR de baixa configura√ß√£o e alto desempenho parece ter sido seu foco principal. Eu entendo que isso n√£o √© necessariamente relevante para todos os usu√°rios, mas √© o √Ęngulo que o Next inicialmente usou para se destacar (√© por isso que os escolhemos no trabalho). Recentemente, eles se aprofundaram em SSG, aparentemente devido √† popularidade de Gatsby e Jamstack, mas ainda s√£o os melhores para SSR imo.

Honestamente, isso s√≥ importa se voc√™ estiver usando SSG e tiver v√°rias rotas n√£o din√Ęmicas

N√£o tenho certeza do que voc√™ quer dizer com isso, pois SSG vs SSR realmente n√£o importa para tentar entregar a menor carga √ļtil de JS poss√≠vel para a primeira p√°gina ("caminho cr√≠tico" JS), nem fazer rotas din√Ęmicas. Minimizar ativos de caminho cr√≠tico _√©_ geralmente muito importante para aplicativos SSR (portanto, todo o esfor√ßo), portanto, apreciamos isso. E, honestamente, se tudo o que voc√™ est√° fazendo s√£o aplicativos somente CSR com login-walled, ent√£o o Next _s_ tem muitas desvantagens em compara√ß√£o com o CRA (o SSR nunca ser√° t√£o conveniente quanto o CSR). Parece que voc√™ est√° descontando aqueles aplicativos que est√£o realmente executando SSR em tempo de execu√ß√£o (com manipula√ß√£o de login / personaliza√ß√£o do lado do servidor) especificamente para ganhos de desempenho. Nem tudo se encaixa na dicotomia SSG vs CSR.

alguns de nós estão bem em lidar com a divisão de código por conta própria

Alguns de n√≥s tamb√©m s√£o capazes de lidar com webpack, react-dom / server, etc. O objetivo do Next at√© agora parece ser tornar essa eje√ß√£o cada vez mais rara, assim como o CRA. E voc√™ est√° certo, eu deveria ter dito reage-carreg√°vel da mesma forma, porque existem muitas solu√ß√Ķes nesse espa√ßo, e elas est√£o ficando mais ex√≥ticas com os padr√Ķes emergentes de dados mais c√≥digo de bibliotecas como Relay.

Em √ļltima an√°lise, n√£o discordo que um sistema de roteador plug√°vel possa ser bom. Eu estava apenas apontando que seria muito trabalhoso para a equipe do Next remover coisas que s√£o princ√≠pios centrais da estrutura (como l√≥gica de divis√£o de pacotes) e extra√≠-las em uma arquitetura plug√°vel. E minha especula√ß√£o estava destacando o fato de que eu n√£o gostaria de come√ßar a projetar uma mudan√ßa fundamental para minha biblioteca que pudesse ser facilmente revertida por mudan√ßas futuras em minha depend√™ncia principal. Eu certamente concordo que alguns aspectos do design do Next _s√£o_ limitantes, mas na maioria dos casos esses limites fazem sentido, dadas as restri√ß√Ķes de design at√© agora.

Honestamente, isso s√≥ importa se voc√™ estiver usando SSG e tiver v√°rias rotas n√£o din√Ęmicas

N√£o tenho certeza do que voc√™ quer dizer com isso, pois SSG vs SSR realmente n√£o importa para tentar entregar a menor carga √ļtil de JS poss√≠vel para a primeira p√°gina ("caminho cr√≠tico" JS), nem fazer rotas din√Ęmicas.

Provavelmente, estamos pensando em diferentes raz√Ķes pelas quais a capacidade de analisar estaticamente quais rotas existem √© necess√°ria. Assumindo que ambos estamos falando sobre "an√°lise est√°tica" como "a capacidade de identificar a lista de rotas (por exemplo, ['/about', '/', '/profile'] ) no momento da constru√ß√£o simplesmente lendo o c√≥digo".

Parece que você está falando sobre algum tipo de otimização de pacote JS? Sobre a qual não encontrei nenhuma informação na documentação, não sei exatamente em que tipo de otimização com base na análise de rota estática você está pensando.

Meu pensamento era que essa an√°lise est√°tica de rotas era principalmente √ļtil para SSG. ou seja, porque o arquivo pages/about.js existe quando voc√™ constr√≥i seu site, Next.js sabe que existe uma rota /about e precisa pr√©-renderizar o html para esta rota, mesmo que voc√™ nunca tenha dito explicitamente h√° uma rota /about para pr√©-renderizar.

O SSR n√£o precisa de html pr√©-constru√≠do, pois s√≥ faz isso quando uma solicita√ß√£o chega (nesse ponto, ele executa o c√≥digo e tem um caminho para renderizar). As p√°ginas renderizadas pelo cliente n√£o t√™m nenhum html pr√©-renderizado. E se sua p√°gina SSG for din√Ęmica, voc√™ precisa declarar todos os caminhos de qualquer maneira. Da√≠ meus pensamentos.

E, honestamente, se tudo o que você está fazendo são aplicativos somente CSR com login-walled, então o Next _s_ tem muitas desvantagens em comparação com o CRA (o SSR nunca será tão conveniente quanto o CSR).

Em que desvantagens você está pensando no Next.js em relação aos aplicativos de CSR? Além dos problemas de roteador mencionados acima.

No meu entendimento, Next.js oferece suporte a toda a gama de rotas SSR / SSG / CSR. Portanto, supostamente ainda é adequado para escrever aplicativos somente CSR com login-walled.

Pessoalmente, minha perspectiva √© definitivamente de algu√©m que est√° escrevendo um monte de aplicativos amplamente CSR, com necessidades ocasionais de SSR e SSG, querendo ter um √ļnico kit de ferramentas robusto para todos os meus projetos, n√£o importa que combina√ß√£o de SSR / SSG / CSR eles precisem.

Pela minha experi√™ncia, o CRA tem um bom n√ļmero de desvantagens, mesmo em aplicativos somente CSR, que podem tornar as p√°ginas CSR do Next.js vantajosas. A personaliza√ß√£o da configura√ß√£o do WebPack sem eje√ß√£o √© um grande problema. Isso me causou muita dor quando n√£o pude simplesmente usar o plug-in globalize-compiler WebPack ao adicionar i18n a um aplicativo. A capacidade de optar por SSR / SSG para p√°ginas espec√≠ficas, mesmo se a maioria das p√°ginas for CSR, tamb√©m √© uma vantagem (por exemplo, 99,9% de suas p√°ginas s√£o CSR e est√£o atr√°s de uma p√°gina de login; mas voc√™ tem uma p√°gina de destino e talvez termos / contato p√°ginas nas quais deseja SSG ou SSR). N√£o posso fazer nenhuma dessas coisas razoavelmente com coisas como CRA.

alguns de nós estão bem em lidar com a divisão de código por conta própria

Alguns de nós também são capazes de lidar com webpack, react-dom / server, etc. O objetivo do Next até agora parece ser tornar essa ejeção cada vez mais rara, assim como o CRA

Honestamente, fazer manualmente a divisão de código baseado em rota (certificando-se de modificar um para usar seus componentes de rota via React.lazy ou uma biblioteca alternativa em vez de uma importação direta) é muito longe de gerenciar manualmente uma configuração de WebPack personalizada ou escrita seus próprios gerenciadores de SSR com react-dom/server .

√Č totalmente razo√°vel n√£o querer escrever manualmente uma configura√ß√£o WebPack inteira ou um servidor SSR personalizado (ou seja, querer usar uma estrutura amplamente usada como Next.js), mas ainda assim usar o react-router e fazer manualmente o c√≥digo baseado em rota- divis√£o. Especialmente se optar pela divis√£o de c√≥digo de base de rota autom√°tica significa perder a biblioteca de roteadores amplamente usada que voc√™ est√° usando e usar um roteador sem uma s√©rie de recursos que voc√™ pode precisar com uma API muito diferente de qualquer um dos roteadores de uso mais amplo.

Sempre caio nessa questão quando procuro uma maneira de integrar react-router com NextJS que não exija a criação de um servidor personalizado, então decidi tentar eu mesmo.

Com react-router v6 (beta), crie um _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>
            )
        }
    }
}

Por quê

Não é fácil gerenciar _opcional pegar todas as rotas_ no NextJS (por exemplo: /foo/[[...bar]].js ), então estou explorando uma maneira de usar react-router para esse tipo de página. Talvez outros tenham motivos diferentes, mas essa é minha principal preocupação e react-router fornece uma boa API, especialmente na v6, que está atualmente em beta.

Como funciona

Ele apenas cria um MemoryRouter vez de um BrowserRouter portanto, n√£o bagun√ßamos o hist√≥rico do navegador por ter o roteador NextJS e o roteador NextJS. Ele ouve as mudan√ßas do hist√≥rico de mem√≥ria para PUSH e REPLACE ent√£o voc√™ pode usar react-router ganchos ou Link para navegar, mas por baixo do cap√ī, seria chamando os m√©todos do roteador NextJS .push e .replace .

√Č necess√°rio chamar os m√©todos do roteador NextJS, caso contr√°rio, as altera√ß√Ķes de rota n√£o acionar√£o os m√©todos NextJS get*Props . Em outras palavras, funcionaria de forma semelhante √† op√ß√£o shallow usando NextJS Link . A desvantagem de usar react-router 's Link √© que n√£o h√° prefetch . No entanto, voc√™ ainda pode usar NextJS Link vez disso e react-router ainda pode reagir a altera√ß√Ķes de rota.

O legal disso é que agora você pode aproveitar as rotas NextJS dynamic e react-router e fazer coisas como:

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

De qualquer forma, espero que isso ajude alguém. Eu não usei isso na produção e este código é de um playground local que eu tenho, então provavelmente há coisas que poderiam ser melhoradas, mas é um começo.

Usando React Router com Next.js 9.5+

Se você estiver usando Next.js 9.5 ou posterior, a maneira correta de fazer isso é com Rewrites . _Não use um servidor personalizado_! Há um tutorial detalhado sobre como fazer isso aqui: https://colinhacks.com/essays/building-a-spa-with-nextjs

A ideia b√°sica:

  1. Crie um aplicativo personalizado ( /pages/_app.tsx )

  2. Retorne null se typeof window === "undefined" . Isso é necessário para evitar que o roteador react lance erros durante a etapa 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;

O atributo suppressHydrationWarning serve para evitar avisos que o React lan√ßa quando o conte√ļdo renderizado pelo servidor discorda do conte√ļdo renderizado pelo cliente.

  1. Reescrever todas as rotas para a p√°gina inicial
// next.config.js

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

Então você pode usar o React Router normalmente! Há muito mais contexto / explicação no tutorial vinculado, mas isso o ajudará a começar. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks Uma boa solução pode confirmar que funciona. Algo em que pensar é mover o aplicativo para sua própria página, como app.js ou routes.js ou algo assim. Em seguida, ter as reescritas para

// next.config.js

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

Só para pensar, sua solução é a melhor que encontrei.

Esta p√°gina foi √ļtil?
0 / 5 - 0 avalia√ß√Ķes

Quest√Ķes relacionadas

knipferrc picture knipferrc  ¬∑  3Coment√°rios

havefive picture havefive  ¬∑  3Coment√°rios

renatorib picture renatorib  ¬∑  3Coment√°rios

kenji4569 picture kenji4569  ¬∑  3Coment√°rios

pie6k picture pie6k  ¬∑  3Coment√°rios