@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?

Consulte https://github.com/zachrbrown/next-react-router. Existem documentos atm escassos, mas alguma explicação breve em https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.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.

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?

https://github.com/zeit/next.js/issues/75

@ 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)
  
  
  
  • @ reach / [email protected] : 18,7 kB / 6kB ( link )
  
  
  • [email protected] : 44,1Kb / 10,4kB ( link )
  
  

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:

• Repositório GitHub
• dev.to postar

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?

Algo como isso https://github.com/jaredpalmer/after.js ?

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 https://github.com/jaredpalmer/after.js

@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:

• https://twitter.com/remix_run/status/1253043162714525696
• https://remix.run

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.