Les URL React-router ne fonctionnent pas lors de l'actualisation ou de l'écriture manuelle

J'utilise React-router et cela fonctionne bien lorsque je clique sur les boutons de lien, mais lorsque je rafraîchis ma page Web, il ne charge pas ce que je veux.

Par exemple, je suis localhost/joblistdedans et tout va bien parce que je suis arrivé ici en appuyant sur un lien. Mais si je rafraîchis la page Web, j'obtiens:

Cannot GET /joblist

Par défaut, cela ne fonctionnait pas comme ça. Au départ, j'avais mon URL au fur localhost/#/et à mesure localhost/#/joblistet elles fonctionnaient parfaitement bien. Mais je n'aime pas ce type d'URL, alors en essayant de l'effacer #, j'ai écrit:

Router.run(routes, Router.HistoryLocation, function (Handler) {
 React.render(<Handler/>, document.body);
});

Ce problème ne se produit pas avec localhost/, celui-ci renvoie toujours ce que je veux.

EDIT: Cette application est d'une seule page, donc /joblistn'a pas besoin de demander quoi que ce soit à n'importe quel serveur.

EDIT2: Mon routeur entier.

var routes = (
    <Route name="app" path="/" handler={App}>
        <Route name="joblist" path="/joblist" handler={JobList}/>
        <DefaultRoute handler={Dashboard}/>
        <NotFoundRoute handler={NotFound}/>
    </Route>
);

Router.run(routes, Router.HistoryLocation, function (Handler) {
  React.render(<Handler/>, document.body);
});

_{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/aboutau 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 404erreurs 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/aboutURL 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 #/aboutpiè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 windowcô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:

• Réagissez à l'avenir avec des applications isomorphes
• La douleur et la joie de créer des applications isomorphes dans ReactJS
• Comment implémenter Node + React Isomorphic JavaScript & Why it Matters

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:

• Créer une application React

Ou choisissez l'un des nombreux par la communauté. Il y a maintenant un joli site qui essaie de les indexer tous:

• Choisissez votre projet de démarrage React parfait

J'ai commencé avec ceux-ci:

• React Isomorphic Starterkit
• React Redux Universal Hot Example

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!

Les réponses ici sont toutes extrêmement utiles, ce qui a fonctionné pour moi a été de configurer mon serveur Webpack pour attendre les itinéraires.

devServer: {
   historyApiFallback: true,
   contentBase: './',
   hot: true
},

L'historiqueApiFallback est ce qui a résolu ce problème pour moi. Maintenant, le routage fonctionne correctement et je peux rafraîchir la page ou saisir directement l'URL. Pas besoin de vous soucier des solutions de contournement sur votre serveur de noeud. Cette réponse ne fonctionne évidemment que si vous utilisez webpack.

EDIT: voir ma réponse ici pour une raison plus détaillée pour laquelle cela est nécessaire: https://stackoverflow.com/a/37622953/5217568

Vous pouvez modifier votre .htaccessfichier et insérer ceci:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteRule . /index.html [L]
</IfModule>

j'utilise react: "^16.12.0" et react-router: "^5.1.2" cette méthode est le fourre-tout et est probablement le moyen le plus simple de vous aider à démarrer.

Pour React Router V4 :

Si vous essayez de résoudre ce problème par la technique de Hash History mentionnée dans d'autres réponses, notez que

<Router history={hashHistory} >

ne fonctionne pas en V4, veuillez utiliser à la HashRouterplace:

import { HashRouter } from 'react-router-dom'

<HashRouter>
  <App/>
</HashRouter>

Référence: HashRouter

Le routeur peut être appelé de deux manières différentes, selon que la navigation s'effectue sur le client ou sur le serveur. Vous l'avez configuré pour un fonctionnement côté client. Le paramètre clé est le deuxième de la méthode d'exécution , l'emplacement.

Lorsque vous utilisez le composant React Router Link, il bloque la navigation du navigateur et appelle transitionTo pour effectuer une navigation côté client. Vous utilisez HistoryLocation, il utilise donc l'API d'historique HTML5 pour compléter l'illusion de navigation en simulant la nouvelle URL dans la barre d'adresse. Si vous utilisez des navigateurs plus anciens, cela ne fonctionnera pas. Vous devez utiliser le composant HashLocation.

Lorsque vous appuyez sur Actualiser, vous contournez tout le code React et React Router. Le serveur reçoit la demande /joblistet doit renvoyer quelque chose. Sur le serveur, vous devez transmettre le chemin d'accès qui a été demandé à la runméthode pour qu'elle affiche la vue correcte. Vous pouvez utiliser la même carte d'itinéraire, mais vous aurez probablement besoin d'un appel différent vers Router.run. Comme le souligne Charles, vous pouvez utiliser la réécriture d'URL pour gérer cela. Une autre option consiste à utiliser un serveur node.js pour gérer toutes les demandes et transmettre la valeur du chemin d'accès comme argument d'emplacement.

En express, par exemple, cela pourrait ressembler à ceci:

var app = express();

app.get('*', function (req, res) { // This wildcard method handles all requests

    Router.run(routes, req.path, function (Handler, state) {
        var element = React.createElement(Handler);
        var html = React.renderToString(element);
        res.render('main', { content: html });
    });
});

Notez que le chemin de demande est transmis à run. Pour ce faire, vous devez disposer d'un moteur de vue côté serveur auquel vous pouvez transmettre le code HTML rendu. Il existe un certain nombre d'autres considérations lors de l'utilisation renderToStringet de l'exécution de React sur le serveur. Une fois que la page est rendue sur le serveur, lorsque votre application se charge dans le client, elle s'affichera à nouveau, mettant à jour le HTML rendu côté serveur selon les besoins.

Dans votre index.html head, ajoutez ce qui suit:

<base href="/">
<!-- This must come before the css and javascripts -->

Ensuite, lors de l'exécution avec le serveur de développement webpack, utilisez cette commande.

webpack-dev-server --mode development --hot --inline --content-base=dist --history-api-fallback

--history-api-fallback est la partie importante

J'ai utilisé create-react-app pour créer un site Web tout à l'heure et j'ai présenté le même problème ici. J'utilise BrowserRoutingdu react-router-dompaquet. Je suis en cours d'exécution sur un serveur Nginx et ce qui a résolu pour moi l'ajout de ce qui suit à/etc/nginx/yourconfig.conf

location / {
  if (!-e $request_filename){
    rewrite ^(.*)$ /index.html break;
  }
}

Ce qui correspond à l'ajout de ce qui suit au .htaccesscas où vous exécutez Appache

Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]

Cela semble également être la solution suggérée par Facebook eux-mêmes et peut être trouvée ici

Cela peut résoudre votre problème

J'ai également rencontré le même problème dans l'application ReactJS en mode Production. Voici la 2 solution au problème.

1.Changez l'historique de routage en "hashHistory" au lieu de browserHistory à la place de

<Router history={hashHistory} >
   <Route path="/home" component={Home} />
   <Route path="/aboutus" component={AboutUs} />
</Router>

Maintenant, créez l'application en utilisant la commande

sudo npm run build

Ensuite, placez le dossier de construction dans votre dossier var / www /, Maintenant, l'application fonctionne correctement avec l'ajout de la balise # dans chaque URL. comme

localhost / # / home localhost / # / aboutus

Solution 2: sans balise # à l'aide de browserHistory,

Définissez votre historique = {browserHistory} dans votre routeur, maintenant construisez-le en utilisant sudo npm run build.

Vous devez créer le fichier "conf" pour résoudre la page 404 introuvable, le fichier conf devrait être comme ceci.

ouvrez votre terminal tapez les commandes ci-dessous

cd / etc / apache2 / sites-available ls nano sample.conf Ajoutez-y le contenu ci-dessous.

<VirtualHost *:80>
    ServerAdmin admin@0.0.0.0
    ServerName 0.0.0.0
    ServerAlias 0.0.0.0
    DocumentRoot /var/www/html/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    <Directory "/var/www/html/">
            Options Indexes FollowSymLinks
            AllowOverride all
            Require all granted
    </Directory>
</VirtualHost>

Vous devez maintenant activer le fichier sample.conf à l'aide de la commande suivante

cd /etc/apache2/sites-available
sudo a2ensite sample.conf

puis il vous demandera de recharger le serveur apache, en utilisant sudo service apache2 reload or restart

puis ouvrez votre dossier localhost / build et ajoutez le fichier .htaccess avec le contenu ci-dessous.

   RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-l
   RewriteRule ^.*$ / [L,QSA]

Maintenant, l'application fonctionne normalement.

Remarque: remplacez 0.0.0.0 ip par votre adresse ip locale.

En cas de doute à ce sujet, n'hésitez pas à formuler un commentaire.

J'espère que cela sera utile aux autres.

Si vous hébergez une application React via AWS Static S3 Hosting & CloudFront

Ce problème s'est présenté par CloudFront en répondant avec un message 403 Access Denied car il s'attendait à ce que / some / other / path existe dans mon dossier S3, mais ce chemin n'existe qu'en interne dans le routage de React avec react-router.

La solution était de mettre en place une règle de distribution des pages d'erreur. Accédez aux paramètres CloudFront et choisissez votre distribution. Allez ensuite dans l'onglet "Pages d'erreur". Cliquez sur "Créer une réponse d'erreur personnalisée" et ajoutez une entrée pour 403 car c'est le code d'état d'erreur que nous obtenons. Définissez le chemin de la page de réponse sur /index.html et le code d'état sur 200. Le résultat final m'étonne par sa simplicité. La page d'index est servie, mais l'URL est conservée dans le navigateur, donc une fois que l'application React se charge, elle détecte le chemin de l'URL et navigue vers l'itinéraire souhaité.

Pages d'erreur 403 règle

Le serveur de développement Webpack a une option pour l'activer. Ouvrez package.jsonet ajoutez --history-api-fallback. Ces solutions ont fonctionné pour moi.

réagir-routeur-tutoriel

Si vous hébergez votre application React sur IIS, ajoutez simplement un fichier web.config contenant:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/" responseMode="ExecuteURL" />
    </httpErrors>
  </system.webServer>
</configuration>

Cela indiquera au serveur IIS de renvoyer la page principale au client au lieu d'une erreur 404 et pas besoin d'utiliser l'historique de hachage.

Ajoutez ceci à webpack.config.js:

devServer: {
    historyApiFallback: true
}

Pile de production: React, React Router v4, BrowswerRouter, Express, Nginx

1) User BrowserRouter pour de jolies URL

// app.js

import { BrowserRouter as Router } from 'react-router-dom'

const App = () {
  render() {
    return (
        <Router>
           // your routes here
        </Router>
    )
  }
}

2) Ajoutez index.html à toutes les demandes inconnues en utilisant /*

// server.js

app.get('/*', function(req, res) {   
  res.sendFile(path.join(__dirname, 'path/to/your/index.html'), function(err) {
    if (err) {
      res.status(500).send(err)
    }
  })
})

3) bundle webpack avec webpack -p

4) exécuter nodemon server.jsounode server.js

EDIT: vous souhaiterez peut-être laisser nginx gérer cela dans le bloc serveur et ignorer l'étape 2:

location / {
    try_files $uri /index.html;
}

Si vous utilisez l'application Create React:

Il y a cependant une bonne marche à suivre pour résoudre ce problème avec des solutions pour de nombreuses plates-formes d'hébergement majeures que vous pouvez trouver ICI sur la page de l'application Create React. Par exemple, j'utilise React Router v4 et Netlify pour mon code frontal. Tout ce qu'il a fallu a été d'ajouter 1 fichier à mon dossier public ("_redirects") et une ligne de code dans ce fichier:

/*  /index.html  200

Maintenant, mon site Web affiche correctement des chemins tels que mysite.com/pricing lorsqu'il est entré dans le navigateur ou lorsque quelqu'un frappe actualiser.

Essayez d'ajouter le fichier ".htaccess" dans le dossier public avec le code ci-dessous.

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]

RewriteRule ^ /index.html [L]  

Si vous avez un repli sur votre index.html, assurez-vous que dans votre fichier index.html vous avez ceci:

<script>
  System.config({ baseURL: '/' });
</script>

Cela peut différer d'un projet à l'autre.

Si vous utilisez Firebase, tout ce que vous avez à faire est de vous assurer que vous avez une propriété de réécriture dans votre fichier firebase.json à la racine de votre application (dans la section hébergement).

Par exemple:

{ 
  "hosting": {
    "rewrites": [{
      "source":"**",
      "destination": "/index.html"
    }]    
  }
}

J'espère que cela fera économiser à quelqu'un d'autre un trésor de frustration et de perte de temps.

Bon codage ...

Pour en savoir plus sur le sujet:

https://firebase.google.com/docs/hosting/full-config#rewrites

Firebase CLI: "Configurer comme une application d'une seule page (réécrire toutes les URL dans /index.html)"

J'ai trouvé la solution pour mon SPA avec un routeur React (Apache). Ajoutez simplement .htaccess

<IfModule mod_rewrite.c>

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteRule . /index.html [L]

</IfModule>

source: https://gist.github.com/alexsasharegan/173878f9d67055bfef63449fa7136042

Je n'utilise pas encore le rendu côté serveur mais j'ai rencontré le même problème que l'OP où Link semblait bien fonctionner la plupart du temps mais a échoué lorsque j'avais un paramètre. Je vais documenter ma solution ici pour voir si elle aide quelqu'un.

Mon jsx principal contient ceci:

<Route onEnter={requireLogin} path="detail/:id" component={ModelDetail} />

Cela fonctionne bien pour le premier lien correspondant, mais lorsque: id change dans <Link> expressions imbriquées sur la page de détails de ce modèle, l'url change dans la barre de navigateur, mais le contenu de la page n'a pas initialement changé pour refléter le modèle lié.

Le problème était que j'avais utilisé le props.params.idpour définir le modèle componentDidMount. Le composant n'est monté qu'une seule fois, ce qui signifie que le premier modèle est celui qui reste sur la page et les liens suivants modifient les accessoires mais laissent la page inchangée.

La définition du modèle dans l'état du composant à la fois componentDidMountet dans componentWillReceiveProps(où il est basé sur les accessoires suivants) résout le problème et le contenu de la page change pour refléter le modèle souhaité.

Ce sujet est un peu ancien et résolu mais je voudrais vous proposer une solution simple, claire et meilleure. Cela fonctionne si vous utilisez un serveur Web.

Chaque serveur Web a la possibilité de rediriger l'utilisateur vers une page d'erreur dans le cas de http 404. Pour résoudre ce problème, vous devez rediriger l'utilisateur vers la page d'index.

Si vous utilisez un serveur de base Java (tomcat ou tout autre serveur d'applications Java), la solution pourrait être la suivante:

web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <!-- WELCOME FILE LIST -->
    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

    <!-- ERROR PAGES DEFINITION -->
    <error-page>
        <error-code>404</error-code>
        <location>/index.jsp</location>
    </error-page>

</web-app>

Exemple:

• OBTENEZ http://example.com/about
• Le serveur Web envoie http 404 car cette page n'existe pas côté serveur
• la configuration de la page d'erreur indique au serveur qui renvoie la page index.jsp à l'utilisateur
• alors JS fera le reste du travail côté client car l'url du côté client est toujours http://example.com/about .

Ça y est, plus besoin de magie :)

Si vous utilisez Express ou un autre framework dans le backend, vous pouvez ajouter la configuration similaire comme ci-dessous et vérifier le chemin public Webpack dans la configuration, cela devrait fonctionner correctement même lors du rechargement si vous utilisez BrowserRouter

expressApp.get('/*', (request, response) => {
    response.sendFile(path.join(__dirname, '../public/index.html'));
});

Correction de l'erreur "ne peut pas obtenir / URL" lors de l'actualisation ou lors de l'appel direct de l'URL.

Configurez votre webpack.config.js pour attendre le lien donné les itinéraires comme celui-ci.

module.exports = {
  entry: './app/index.js',
  output: {
       path: path.join(__dirname, '/bundle'),
       filename: 'index_bundle.js',
       publicPath: '/'
  },

Comme j'utilise .Net Core MVC, quelque chose comme ça m'a aidé:

    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            var url = Request.Path + Request.QueryString;
            return App(url);
        }

        [Route("App")]
        public IActionResult App(string url)
        {
            return View("/wwwroot/app/build/index.html");
        }
   }

Fondamentalement, du côté MVC, toutes les routes qui ne correspondent pas tomberont Home/Indexcomme indiqué dans startup.cs. À l'intérieur, Indexil est possible d'obtenir l'URL de demande d'origine et de la transmettre où vous en avez besoin.

startup.cs

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=Home}/{action=Index}/{id?}");

            routes.MapSpaFallbackRoute(
                name: "spa-fallback",
                defaults: new { controller = "Home", action = "Index" });
        });

Si vous hébergez dans IIS; L'ajout de ceci à ma configuration Web a résolu mon problème

<httpErrors errorMode="Custom" defaultResponseMode="ExecuteURL">
    <remove statusCode="500" subStatusCode="100" />
    <remove statusCode="500" subStatusCode="-1" />
    <remove statusCode="404" subStatusCode="-1" />
    <error statusCode="404" path="/" responseMode="ExecuteURL" />
    <error statusCode="500" prefixLanguageFilePath="" path="/error_500.asp" responseMode="ExecuteURL" />
    <error statusCode="500" subStatusCode="100" path="/error_500.asp" responseMode="ExecuteURL" />
</httpErrors>

Vous pouvez effectuer une configuration similaire pour tout autre serveur

Au cas où quelqu'un chercherait une solution sur React JS SPA avec Laravel. La réponse acceptée est la meilleure explication de la raison pour laquelle de tels problèmes se produisent. Comme déjà expliqué, vous devez configurer à la fois côté client et côté serveur. Dans votre modèle de lame, incluez le fichier js fourni, assurez-vous de l'utiliser URL facadecomme ceci

<script src="{{ URL::to('js/user/spa.js') }}"></script>

Dans vos itinéraires, assurez-vous de l'ajouter au point de terminaison principal où se trouve le modèle de lame. Par exemple,

Route::get('/setting-alerts', function () {
   return view('user.set-alerts');
});

Ce qui précède est le principal critère d'évaluation du modèle de lame. Maintenant, ajoutez également un itinéraire facultatif,

Route::get('/setting-alerts/{spa?}', function () {
  return view('user.set-alerts');
});

Le problème qui se produit est que le modèle de lame est d'abord chargé, puis le routeur React. Ainsi, lorsque vous chargez '/setting-alerts', il charge le html et le js. Mais lorsque vous chargez '/setting-alerts/about', il se charge d'abord côté serveur. Du côté serveur, il n'y a rien sur cet emplacement, il retourne non trouvé. Lorsque vous avez ce routeur en option, il charge la même page et le routeur React est également chargé, puis React Loader décide du composant à afficher. J'espère que cela t'aides.

Pour ceux qui utilisent IIS 10, voici ce que vous devez faire pour corriger ce problème. Assurez-vous que vous utilisez browserHistory avec cela. En ce qui concerne la référence, je donnerai le code pour le routage, mais ce n'est pas ce qui compte, ce qui compte c'est la prochaine étape après le code composant ci-dessous:

class App extends Component {
    render() {
        return (
            <Router history={browserHistory}>
                <div>
                    <Root>
                        <Switch>
                            <Route exact path={"/"} component={Home} />    
                            <Route path={"/home"} component={Home} />
                            <Route path={"/createnewproject"} component={CreateNewProject} />
                            <Route path={"/projects"} component={Projects} />
                            <Route path="*" component={NotFoundRoute} />
                        </Switch>
                    </Root>
                </div>
            </Router>
        )
    }
}
render (<App />, window.document.getElementById("app"));

Étant donné que le problème est qu'IIS reçoit une demande des navigateurs clients, il interprète l'URL comme s'il demandait une page, puis renvoie une page 404 car il n'y a pas de page disponible. Procédez comme suit:

1. Ouvrir IIS
2. Développez Serveur puis ouvrez le dossier Sites
3. Cliquez sur le site / l'application
4. Accédez aux pages d'erreur
5. Ouvrez l'élément d'état d'erreur 404 dans la liste
6. Au lieu de l'option "Insérer le contenu du fichier statique dans la réponse d'erreur", remplacez-le par "Exécuter une URL sur ce site" et ajoutez une valeur de barre oblique "/" à l'URL.

Et cela fonctionnera désormais correctement.

J'espère que ça aide. :-)

J'utilise WebPack, j'ai eu le même problème Solution => Dans votre fichier server.js

const express = require('express');
const app = express();

app.use(express.static(path.resolve(__dirname, '../dist')));
  app.get('*', function (req, res) {
    res.sendFile(path.resolve(__dirname, '../dist/index.html'));
    // res.end();
  });

Pourquoi mon application ne s'affiche-t-elle pas après avoir été actualisée?

L'utilisation HashRouterde Redux a également fonctionné pour moi , il suffit de remplacer simplement:

import {
  Router //replace Router
} from "react-router-dom";

ReactDOM.render(
    <LocaleProvider locale={enUS}>
    <Provider store={Store}>
        <Router history={history}> //replace here saying Router
            <Layout/>
        </Router>
    </Provider>
</LocaleProvider>, document.getElementById("app"));
registerServiceWorker();

à:

import {
  HashRouter //replaced with HashRouter
} from "react-router-dom";

ReactDOM.render(
    <LocaleProvider locale={enUS}>
    <Provider store={Store}>
        <HashRouter history={history}> //replaced with HashRouter
            <Layout/>
        </HashRouter>
    </Provider>
</LocaleProvider>, document.getElementById("app"));
registerServiceWorker();

J'ai eu ce même problème et cela solution a fonctionné pour nous ..

Contexte:

Nous hébergeons plusieurs applications sur le même serveur. Quand nous rafraîchirions le serveur ne comprendrait pas où chercher notre index dans le dossier dist pour cette application particulière. Le lien ci-dessus vous mènera à ce qui a fonctionné pour nous ... J'espère que cela vous aidera, car nous avons passé pas mal d'heures à trouver une solution à nos besoins.

Nous utilisons:

package.json

"dependencies": {
"babel-polyfill": "^6.23.0",
"ejs": "^2.5.6",
"express": "^4.15.2",
"prop-types": "^15.5.6",
"react": "^15.5.4",
"react-dom": "^15.5.4",
"react-redux": "^5.0.4",
"react-router": "^3.0.2",
"react-router-redux": "^4.0.8",
"redux": "^3.6.0",
"redux-persist": "^4.6.0",
"redux-thunk": "^2.2.0",
"webpack": "^2.4.1"
}

mon webpack.config.js

webpack.config.js

/* eslint-disable */
const path = require('path');
const webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const babelPolyfill = require('babel-polyfill');
const HTMLWebpackPluginConfig = new HtmlWebpackPlugin({
  template: __dirname + '/app/views/index.html',
  filename: 'index.html',
  inject: 'body'
});

module.exports = {
  entry: [
    'babel-polyfill', './app/index.js'
  ],
  output: {
    path: __dirname + '/dist/your_app_name_here',
    filename: 'index_bundle.js'
  },
  module: {
    rules: [{
      test: /\.js$/,
      loader: 'babel-loader',
      query : {
          presets : ["env", "react", "stage-1"]
      },
      exclude: /node_modules/
    }]
  },
  plugins: [HTMLWebpackPluginConfig]
}

mon index.js

index.js

import React from 'react'
import ReactDOM from 'react-dom'
import Routes from './Routes'
import { Provider } from 'react-redux'
import { createHistory } from 'history'
import { useRouterHistory } from 'react-router'
import configureStore from './store/configureStore'
import { syncHistoryWithStore } from 'react-router-redux'
import { persistStore } from 'redux-persist'

const store = configureStore();

const browserHistory = useRouterHistory(createHistory) ({
  basename: '/your_app_name_here'
})
const history = syncHistoryWithStore(browserHistory, store)

persistStore(store, {blacklist: ['routing']}, () => {
  console.log('rehydration complete')
})
// persistStore(store).purge()


ReactDOM.render(
    <Provider store={store}>
      <div>
        <Routes history={history} />
      </div>
    </Provider>,
  document.getElementById('mount')
)

mon app.js

var express = require('express');
var app = express();

app.use(express.static(__dirname + '/dist'));
// app.use(express.static(__dirname + '/app/assets'));
app.set('views', __dirname + '/dist/your_app_name_here');
app.engine('html', require('ejs').renderFile);
app.set('view engine', 'html');

app.get('/*', function (req, res) {
    res.render('index');
});

app.listen(8081, function () {
  console.log('MD listening on port 8081!');
});

J'aime cette façon de le gérer. Essayez d'ajouter: yourSPAPageRoute / * côté serveur pour vous débarrasser de ce problème.

J'ai choisi cette approche car même l'API native HTML5 History ne prend pas en charge la redirection correcte lors de l'actualisation de la page (pour autant que je sache).

Remarque: la réponse sélectionnée a déjà répondu à cela, mais j'essaie d'être plus précis.

Route express

Testé et je voulais juste partager cela.

J'espère que cela aide.