En regardant les commentaires sur la réponse acceptée et la nature générique de cette question («ne fonctionne pas»), j'ai pensé que cela pourrait être un bon endroit pour quelques explications générales sur les problèmes impliqués ici. Cette réponse est donc conçue comme une information / élaboration de base sur le cas d'utilisation spécifique de l'OP. S'il vous plaît, supportez-moi.
Côté serveur vs côté client
La première chose importante à comprendre à ce sujet est qu'il y a maintenant 2 endroits où l'URL est interprétée, alors qu'il n'y en avait qu'un dans «l'ancien temps». Dans le passé, lorsque la vie était simple, certains utilisateurs envoyaient une demande http://example.com/about
au serveur, qui inspectait la partie chemin de l'URL, déterminait que l'utilisateur demandait la page à propos, puis renvoyait cette page.
Avec le routage côté client, ce que fournit React-Router, les choses sont moins simples. Au début, le client n'a pas encore de code JS chargé. Ainsi, la toute première demande sera toujours adressée au serveur. Cela retournera alors une page qui contient les balises de script nécessaires pour charger React et React Router, etc. Ce n'est que lorsque ces scripts ont été chargés que la phase 2 démarre. Dans la phase 2, lorsque l'utilisateur clique sur le lien de navigation `` A propos de nous '' par exemple, l'URL est modifiée localement uniquement en http://example.com/about
(rendue possible par l' API Historique ), mais aucune demande au serveur n'est faite. Au lieu de cela, React Router fait son travail côté client, détermine la vue React à restituer et la restitue. En supposant que votre page À propos n'a pas besoin d'appeler REST, c'est déjà fait. Vous êtes passé de Home à About Us sans qu'aucune demande de serveur n'ait été déclenchée.
Donc, fondamentalement, lorsque vous cliquez sur un lien, certaines exécutions Javascript manipulent l'URL dans la barre d'adresse, sans provoquer d'actualisation de la page , ce qui entraîne à son tour React Router à effectuer une transition de page côté client .
Mais considérez maintenant ce qui se passe si vous copiez-collez l'URL dans la barre d'adresse et l'envoyez par e-mail à un ami. Votre ami n'a pas encore chargé votre site Web. En d'autres termes, elle est toujours en phase 1 . Aucun React Router n'est encore en cours d'exécution sur sa machine. Son navigateur va donc faire une demande au serveurhttp://example.com/about
.
Et c'est là que commence votre problème. Jusqu'à présent, vous pouviez vous en sortir en plaçant simplement un code HTML statique à la racine Web de votre serveur. Mais cela donnerait des 404
erreurs pour toutes les autres URL à la demande du serveur . Ces mêmes URL fonctionnent très bien côté client , car React Router effectue le routage pour vous, mais elles échouent côté serveur, sauf si vous les faites comprendre à votre serveur.
Combinaison du routage côté serveur et côté client
Si vous souhaitez que l' http://example.com/about
URL fonctionne à la fois côté serveur et côté client, vous devez configurer des itinéraires pour celle-ci à la fois côté serveur et côté client. Est-ce logique, non?
Et c'est là que vos choix commencent. Les solutions vont du contournement complet du problème, via une route fourre-tout qui renvoie le HTML d'amorçage, à l'approche isomorphe complète où le serveur et le client exécutent le même code JS.
.
Contourner complètement le problème: Hash History
Avec l' historique de hachage au lieu de l' historique du navigateur , votre URL pour la page à propos ressemblerait à ceci:
http://example.com/#/about
La partie après le #
symbole hash ( ) n'est pas envoyée au serveur. Ainsi, le serveur ne voit http://example.com/
et n'envoie que la page d'index comme prévu. React-Router ramassera la #/about
pièce et affichera la bonne page.
Inconvénients :
- URL «moches»
- Le rendu côté serveur n'est pas possible avec cette approche. En ce qui concerne l'optimisation des moteurs de recherche (SEO), votre site Web se compose d'une seule page avec pratiquement aucun contenu.
.
Fourre-tout
Avec cette approche vous utilisez l' historique du navigateur, mais juste mettre en place un fourre-tout sur le serveur qui envoie /*
à index.html
, vous donnant effectivement la même situation avec Hash Histoire. Cependant, vous avez des URL propres et vous pouvez améliorer ce schéma plus tard sans avoir à invalider tous les favoris de vos utilisateurs.
Inconvénients :
- Plus complexe à mettre en place
- Toujours pas de bon référencement
.
Hybride
Dans l'approche hybride, vous développez le scénario fourre-tout en ajoutant des scripts spécifiques pour des itinéraires spécifiques. Vous pouvez créer des scripts PHP simples pour renvoyer les pages les plus importantes de votre site avec du contenu inclus, afin que Googlebot puisse au moins voir ce qu'il y a sur votre page.
Inconvénients :
- Encore plus complexe à mettre en place
- Seul bon référencement pour les itinéraires auxquels vous accordez le traitement spécial
- Duplication de code pour le rendu de contenu sur le serveur et le client
.
Isomorphe
Et si nous utilisons Node JS comme serveur pour pouvoir exécuter le même code JS aux deux extrémités? Maintenant, nous avons tous nos itinéraires définis dans une seule configuration de routeur de réaction et nous n'avons pas besoin de dupliquer notre code de rendu. C'est pour ainsi dire «le Saint Graal». Le serveur envoie exactement le même balisage que celui auquel nous nous retrouverions si la transition de page s'était produite sur le client. Cette solution est optimale en termes de référencement.
Inconvénients :
- Le serveur doit (pouvoir) exécuter JS. J'ai expérimenté avec Java icw Nashorn mais cela ne fonctionne pas pour moi. En pratique, cela signifie principalement que vous devez utiliser un serveur basé sur Node JS.
- Beaucoup de problèmes environnementaux délicats (utilisation
window
côté serveur, etc.)
- Courbe d'apprentissage abrupte
.
Que dois-je utiliser?
Choisissez celui avec lequel vous pouvez vous en sortir. Personnellement, je pense que le fourre-tout est assez simple à mettre en place, ce serait donc mon minimum. Cette configuration vous permet d'améliorer les choses au fil du temps. Si vous utilisez déjà Node JS comme plate-forme de serveur, j'envisagerais certainement de faire une application isomorphe. Oui, c'est difficile au début, mais une fois que vous avez compris, c'est en fait une solution très élégante au problème.
Donc, fondamentalement, pour moi, ce serait le facteur décisif. Si mon serveur fonctionne sur Node JS, je deviendrais isomorphe; Sinon, j'opterais pour la solution Catch-all et je développerais simplement celle-ci (solution hybride) au fur et à mesure que le temps et les exigences SEO l'exigent.
Si vous souhaitez en savoir plus sur le rendu isomorphe (également appelé «universel») avec React, il existe de bons tutoriels sur le sujet:
Aussi, pour commencer, je vous recommande de regarder quelques kits de démarrage. Choisissez-en un qui correspond à vos choix pour la pile technologique (rappelez-vous, React n'est que le V dans MVC, vous avez besoin de plus de choses pour créer une application complète). Commencez par regarder celui publié par Facebook lui-même:
Ou choisissez l'un des nombreux par la communauté. Il y a maintenant un joli site qui essaie de les indexer tous:
J'ai commencé avec ceux-ci:
Actuellement, j'utilise une version maison de brassage universel qui a été inspirée par les deux kits de démarrage ci-dessus, mais ils sont désormais obsolètes.
Bonne chance dans ta quête!