Analisando os comentários sobre a resposta aceita e a natureza genérica dessa pergunta ('não funciona'), achei que esse seria um bom lugar para algumas explicações gerais sobre os problemas envolvidos aqui. Portanto, esta resposta é destinada a informações / elaboração de plano de fundo sobre o caso de uso específico do OP. Por favor, tenha paciência comigo.
Lado do servidor x lado do cliente
A primeira coisa importante a entender sobre isso é que agora existem 2 lugares onde a URL é interpretada, enquanto costumava haver apenas 1 nos 'velhos tempos'. No passado, quando a vida era simples, algum usuário enviava uma solicitação para http://example.com/about
o servidor, que inspecionava a parte do caminho da URL, determinava que o usuário estava solicitando a página sobre e depois a enviava de volta.
Com o roteamento do lado do cliente, que é o que o React-Router fornece, as coisas são menos simples. Inicialmente, o cliente ainda não possui nenhum código JS carregado. Portanto, a primeira solicitação sempre será para o servidor. Isso retornará uma página que contém as tags de script necessárias para carregar o React e o React Router, etc. Somente quando esses scripts foram carregados, a fase 2 é iniciada. Na fase 2, quando o usuário clica no link de navegação "Sobre nós", por exemplo, o URL é alterado localmente apenas para http://example.com/about
(tornado possível pela API de histórico ), mas nenhuma solicitação ao servidor é feita. Em vez disso, o React Router faz sua parte no lado do cliente, determina qual visualização do React renderizar e a renderiza. Supondo que sua página sobre não precise fazer chamadas REST, isso já foi feito. Você fez a transição da Página inicial para Sobre nós sem que nenhuma solicitação do servidor tenha sido acionada.
Então, basicamente, quando você clica em um link, algumas execuções de Javascript que manipulam o URL na barra de endereços, sem causar uma atualização da página , o que faz com que o React Router faça uma transição de página no lado do cliente .
Mas agora considere o que acontece se você copiar e colar o URL na barra de endereços e enviá-lo por e-mail a um amigo. Seu amigo ainda não carregou seu site. Em outras palavras, ela ainda está na fase 1 . O React Router ainda não está em execução em sua máquina. Então, o navegador dela fará uma solicitação ao servidorhttp://example.com/about
.
E é aí que o seu problema começa. Até agora, você poderia simplesmente colocar um HTML estático na raiz da web do seu servidor. Mas isso daria 404
erros para todos os outros URLs quando solicitados ao servidor . Esses mesmos URLs funcionam bem no lado do cliente , porque o React Router está fazendo o roteamento para você, mas eles falham no lado do servidor, a menos que você faça com que o servidor os entenda.
Combinando o roteamento do servidor e do cliente
Se você deseja que o http://example.com/about
URL funcione no servidor e no cliente, é necessário configurar rotas para ele no servidor e no cliente. Faz sentido certo?
E é aí que as suas escolhas começam. As soluções vão desde contornar completamente o problema, por meio de uma rota abrangente que retorna o HTML de inicialização, até a abordagem isomórfica completa, na qual o servidor e o cliente executam o mesmo código JS.
.
Ignorando o problema completamente: Histórico de Hash
Com o Hash History em vez do Browser History , o URL da página about seria parecido com o seguinte:
http://example.com/#/about
A parte após o #
símbolo hash ( ) não é enviada para o servidor. Portanto, o servidor apenas vê http://example.com/
e envia a página de índice conforme o esperado. O React-Router pega a #/about
peça e mostra a página correta.
Desvantagens :
- URLs 'feios'
- A renderização do servidor não é possível com essa abordagem. No que diz respeito à otimização de mecanismos de busca (SEO), seu site consiste em uma única página com quase nenhum conteúdo.
.
Catch-all
Com essa abordagem, você fazer História Navegador uso, mas apenas configurar um pega-tudo no servidor que envia /*
para index.html
, efetivamente dando-lhe muito a mesma situação que com a História Hash. No entanto, você possui URLs limpos e poderá aprimorar esse esquema posteriormente sem precisar invalidar todos os favoritos do usuário.
Desvantagens :
- Mais complexo de configurar
- Ainda não é um bom SEO
.
Híbrido
Na abordagem híbrida, você expande o cenário abrangente adicionando scripts específicos para rotas específicas. Você pode criar alguns scripts PHP simples para retornar as páginas mais importantes do seu site com o conteúdo incluído, para que o Googlebot possa pelo menos ver o que está na sua página.
Desvantagens :
- Ainda mais complexo de configurar
- Apenas um bom SEO para as rotas que você dá ao tratamento especial
- Código de duplicação para renderizar conteúdo no servidor e no cliente
.
Isomórfico
E se usarmos o Nó JS como nosso servidor para que possamos executar o mesmo código JS nas duas extremidades? Agora, temos todas as nossas rotas definidas em uma única configuração do roteador de reação e não precisamos duplicar nosso código de renderização. Este é 'o Santo Graal', por assim dizer. O servidor envia exatamente a mesma marcação que terminaríamos se a transição da página tivesse acontecido no cliente. Esta solução é ideal em termos de SEO.
Desvantagens :
- O servidor deve (pode) executar o JS. Eu experimentei o Java icw Nashorn, mas não está funcionando para mim. Na prática, significa principalmente que você deve usar um servidor baseado em Nó JS.
- Muitas questões ambientais complicadas (usando
window
no lado do servidor etc)
- Curva de aprendizado acentuada
.
Qual devo usar?
Escolha o que você pode se safar. Pessoalmente, acho que o catch-all é simples o suficiente para configurar, então esse seria o meu mínimo. Essa configuração permite que você melhore as coisas ao longo do tempo. Se você já está usando o Node JS como sua plataforma de servidor, eu definitivamente investigaria a execução de um aplicativo isomórfico. Sim, é difícil no começo, mas quando você pega o jeito, na verdade é uma solução muito elegante para o problema.
Então, basicamente, para mim, esse seria o fator decisivo. Se meu servidor for executado no nó JS, eu ficaria isomórfica; caso contrário, eu escolheria a solução Catch-all e a expandiria (solução híbrida) à medida que o tempo avança e os requisitos de SEO exigem.
Se você quiser saber mais sobre a renderização isomórfica (também chamada de 'universal') com o React, existem alguns bons tutoriais sobre o assunto:
Além disso, para você começar, recomendo olhar alguns kits iniciais. Escolha uma que corresponda às suas escolhas para a pilha de tecnologia (lembre-se, React é apenas o V no MVC, você precisa de mais coisas para criar um aplicativo completo). Comece analisando o publicado pelo próprio Facebook:
Ou escolha um dos muitos da comunidade. Existe um site legal agora que tenta indexar todos eles:
Comecei com estes:
Atualmente, estou usando uma versão caseira da renderização universal inspirada nos dois kits iniciais acima, mas eles estão desatualizados agora.
Boa sorte com sua busca!