Os URLs do roteador reagente não funcionam ao atualizar ou escrever manualmente

Estou usando o React-router e funciona bem enquanto clico nos botões de link, mas quando atualizo minha página, ele não carrega o que eu quero.

Por exemplo, eu estou em localhost / joblist e está tudo bem, porque cheguei aqui pressionando um link. Mas se eu atualizar a página eu recebo: Não é possível GET / joblist

Por padrão, não funcionou assim. Inicialmente eu tive minha URL: localhost / # / e localhost / # / joblist e eles funcionaram perfeitamente bem. Mas eu não gosto desse tipo de URL, então tentando apagar isso ‘#’ eu escrevi:

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

Esse problema não acontece com o localhost /, este sempre retorna o que eu quero.

EDIT: Este aplicativo é de página única, portanto, / lista de tarefas não precisa pedir nada a qualquer servidor.

EDIT2: Meu roteador inteiro.

 var routes = (      ); Router.run(routes, Router.HistoryLocation, function (Handler) { React.render(, document.body); }); 

Olhando para os comentários sobre a resposta aceita e a natureza genérica desta questão (“não trabalhe”), achei que esse poderia ser um bom lugar para algumas explicações gerais sobre os assuntos envolvidos aqui. Portanto, esta resposta destina-se a informação / elaboração de um histórico sobre o caso de uso específico do OP. Por favor, tenha paciência comigo.

Lado do servidor x Lado do cliente

A primeira grande coisa a entender sobre isso é que agora há dois lugares em que a URL é interpretada, ao passo que costumava haver apenas 1 nos “velhos tempos”. No passado, quando a vida era simples, alguns usuários enviaram uma solicitação para http://example.com/about para o servidor, que inspecionou a parte do caminho do URL, determinou que o usuário estava solicitando a página sobre e enviou de volta esse página.

Com o roteamento do lado do cliente, que é o que o Roteador -Reat fornece, as coisas são menos simples. Inicialmente, o cliente ainda não tem nenhum código JS carregado. Portanto, o primeiro pedido será sempre 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 forem carregados, a fase 2 será 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 (possibilitado pela API de histórico ), mas não para o servidor é feito . Em vez disso, o React Router faz isso no lado do cliente, determina qual React view renderiza e renderiza. Supondo que sua página sobre não precise fazer nenhuma chamada REST, ela já está pronta. Você fez a transição de Home para About Us sem qualquer solicitação de servidor.

Então, basicamente, quando você clica em um link, algumas execuções de Javascript manipulam a URL na barra de endereços, sem causar uma atualização de página , o que faz com que o React Router execute 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 para um amigo. Seu amigo ainda não carregou seu site. Em outras palavras, ela ainda está na fase 1 . Nenhum roteador React está sendo executado em sua máquina ainda. Então, o navegador dela fará uma solicitação do servidor para http://example.com/about .

E é aí que o seu problema começa. Até agora, você poderia simplesmente colocar um HTML estático na webroot do seu servidor. Mas isso daria erros 404 para todas as outras URLs quando solicitado pelo servidor . Essas mesmas URLs funcionam bem no lado do cliente , porque o Roteador React está fazendo o roteamento para você, mas elas falham no lado do servidor, a menos que você faça com que o servidor as compreenda.

Combinando o roteamento do lado do servidor e do lado do cliente

Se você quiser que o http://example.com/about URL funcione no servidor e no lado do cliente, é necessário configurar rotas para ele no lado do servidor e do lado do cliente. Faz sentido certo?

E é aí que suas escolhas começam. As soluções vão desde ignorar completamente o problema, por meio de uma rota pega-tudo que retorna o HTML de bootstrap, até a abordagem isomórfica completa em que tanto o servidor quanto o cliente executam o mesmo código JS.

.

Ignorando o problema completamente: Hash History

Com o Histórico de Hash em vez do Histórico do Navegador , sua URL para a página sobre seria semelhante a esta: http://example.com/#/about A parte após o símbolo de hash ( # ) não ser enviado para o servidor. Assim, o servidor só vê http://example.com/ e envia a página de índice conforme o esperado. O React-Router selecionará a parte #/about e mostrará a página correta.

Desvantagens :

  • URLs ‘feias’
  • A renderização do lado do servidor não é possível com essa abordagem. Quanto Search Engine Optimization (SEO) está em causa, o site é composto por uma única página com quase nenhum conteúdo sobre ele.

.

Pegar tudo

Com essa abordagem, você usa o Histórico do Navegador, mas apenas configura um pega-tudo no servidor que envia /* para index.html , dando-lhe efetivamente a mesma situação que o Histórico de Hash. No entanto, você tem URLs limpas e pode melhorar esse esquema mais tarde sem precisar invalidar todos os favoritos de seu usuário.

Desvantagens :

  • Mais complexo para configurar
  • Ainda não é bom SEO

.

Híbrido

Na abordagem híbrida, você expande o cenário catch-all, 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 conteúdo da sua página.

Desvantagens :

  • Ainda mais complexo para configurar
  • Apenas bom SEO para as rotas que você dá o tratamento especial
  • Duplicando código para renderizar conteúdo no servidor e no cliente

.

Isomórfico

E se usarmos o Node JS como nosso servidor para que possamos executar o mesmo código JS em ambas as extremidades? Agora, temos todas as nossas rotas definidas em uma única configuração react-router 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 teríamos se a transição da página tivesse ocorrido no cliente. Esta solução é ótima em termos de SEO.

Desvantagens :

  • O servidor deve (poder) 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 Node JS.
  • Muitos problemas ambientais complicados (usando window no lado do servidor, etc)
  • Curva de aprendizagem íngreme

.

Qual devo usar?

Escolha o que você pode se safar. Pessoalmente, acho que o pega-tudo é simples o suficiente para configurar que isso seria o meu mínimo. Esta configuração permite melhorar as coisas ao longo do tempo. Se você já estiver usando o Node JS como sua plataforma de servidor, eu definitivamente investigaria fazendo um aplicativo isomorfo. Sim, é difícil no começo, mas quando você pega o jeito, é realmente uma solução muito elegante para o problema.

Então, basicamente, para mim, esse seria o fator decisivo. Se meu servidor for executado no Node JS, eu ficaria isomórfico, caso contrário, eu escolheria a solução Catch-all e apenas expandiria (solução híbrida) à medida que o tempo avançasse e os requisitos de SEO exigissem isso.

Se você gostaria de aprender mais sobre renderização isomórfica (também chamada de ‘universal’) com o React, existem alguns bons tutoriais sobre o assunto:

  • Reagir ao futuro com aplicativos isomórficos
  • A dor e a alegria de criar aplicativos isomórficos no ReactJS
  • Como implementar o Node + Reagir JavaScript Isomórfico e Por que é Importante

Além disso, para começar, eu recomendo olhar para alguns kits iniciais. Escolha um que corresponda às suas escolhas para a pilha de tecnologia (lembre-se, o React é apenas o V no MVC, você precisa de mais coisas para construir um aplicativo completo). Comece olhando o publicado pelo próprio Facebook:

  • Criar aplicativo Reagir

Ou escolha um dos muitos pela comunidade. Existe um site legal agora que tenta indexar todos eles:

  • Escolha o seu projeto starter React perfeito

Eu comecei com estes:

  • Reagir Kit Iniciante Isomórfico
  • React Redux Universal Hot Example

Atualmente estou usando uma versão caseira de renderização universal que foi inspirada nos dois kits iniciais acima, mas eles estão desatualizados agora.

Boa sorte com sua busca!

As respostas aqui são extremamente úteis, o que funcionou para mim foi configurar meu servidor Webpack para esperar as rotas.

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

O historyApiFallback é o que resolveu esse problema para mim. Agora o roteamento funciona corretamente e posso atualizar a página ou digitar diretamente o URL. Não há necessidade de se preocupar com o trabalho no servidor do nó. Esta resposta obviamente só funciona se você estiver usando o webpack.

EDIT: veja minha resposta aqui para uma razão mais detalhada porque isso é necessário: https://stackoverflow.com/a/37622953/5217568

Para usuários do React Router V4 :

Se você tentar resolver este problema pela técnica Hash History mencionada em outras respostas, note que

não funciona em V4, por favor use o HashRouter :

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

Referência: https://reacttraining.com/react-router/web/api/HashRouter

O roteador pode ser chamado de duas maneiras diferentes, dependendo se a navegação ocorre no cliente ou no servidor. Você o configurou para a operação do lado do cliente. O parâmetro chave é o segundo para o método run , o local.

Quando você usa o componente React Router Link, ele bloqueia a navegação do navegador e chama transitionTo para fazer uma navegação no lado do cliente. Você está usando o HistoryLocation, por isso, ele usa a API de histórico do HTML5 para concluir a ilusão de navegação, simulando o novo URL na barra de endereço. Se você estiver usando navegadores mais antigos, isso não funcionará. Você precisaria usar o componente HashLocation.

Quando você clica em Atualizar, você ignora todo o código React and React Router. O servidor obtém a solicitação de /joblist e deve retornar algo. No servidor, você precisa passar o caminho que foi solicitado ao método de run para que ele renderize a visualização correta. Você pode usar o mesmo mapa de rotas, mas provavelmente precisará de uma chamada diferente para Router.run . Como Charles salienta, você pode usar a regravação de URL para lidar com isso. Outra opção é usar um servidor node.js para manipular todas as solicitações e passar o valor do caminho como o argumento de localização.

Em expresso, por exemplo, pode ser assim:

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

Observe que o caminho da solicitação está sendo passado para ser run . Para fazer isso, você precisará ter um mecanismo de visualização do lado do servidor para o qual possa passar o HTML renderizado. Há várias outras considerações usando renderToString e executando React no servidor. Quando a página for renderizada no servidor, quando o aplicativo for carregado no cliente, ele será renderizado novamente, atualizando o HTML renderizado no lado do servidor conforme necessário.

Você pode mudar o seu htaccess e inserir isto:

 RewriteBase / RewriteRule ^index\.html$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.html [L] i am using react: "^15.3.2" , react-router: "^3.0.0", history: "^4.3.0", 

O Webpack Dev Server possui uma opção para habilitar isso. Abra o package.json e adicione --history-api-fallback . Essas soluções funcionaram para mim.

https://github.com/reactjs/react-router-tutorial/tree/master/lessons/10-clean-urls#configuring-your-server

Na sua head index.html, adicione o seguinte:

   

Então, ao executar com o servidor webpack dev, use este comando.

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

--history-api-fallback é a parte importante

Isso pode resolver seu problema

Também enfrentei o mesmo problema na aplicação ReactJS no modo de produção. Aqui está a 2 solução para o problema.

1.Alterar o histórico de roteamento para “hashHistory” em vez de browserHistory no lugar de

      

Agora crie o aplicativo usando o comando

 sudo npm run build 

Em seguida, coloque a pasta de compilation em sua pasta var / www / Agora, o aplicativo está funcionando bem com a adição de # tag em cada url. gostar

localhost / # / home localhost / # / aboutus

Solução 2: sem tag # usando o browserHistory,

Defina o seu histórico = {browserHistory} no seu Roteador, Agora construa-o usando o sudo npm run build.

Você precisa criar o arquivo “conf” para resolver a página 404 não encontrada, o arquivo conf deve ser assim.

abra o seu terminal digite os comandos abaixo

cd / etc / apache2 / sites-disponíveis ls nano sample.conf Adicione o conteúdo abaixo nele.

   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  Options Indexes FollowSymLinks AllowOverride all Require all granted   

Agora você precisa ativar o arquivo sample.conf usando o seguinte comando

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

então ele pedirá para você recarregar o servidor apache, usando o serviço sudo apache2 reload ou restart

em seguida, abra sua pasta localhost / build e adicione o arquivo .htaccess com o conteúdo abaixo.

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

Agora o aplicativo está funcionando normalmente.

Nota: altere o ip 0.0.0.0 para o seu endereço IP local.

Se tiver alguma dúvida sobre isso, fique à vontade para fazer um comentário.

Espero que seja útil para os outros.

adicione isso ao webpack.congif.js

 devServer: { historyApiFallback: true } 

Se você estiver hospedando um aplicativo de resposta por meio do AWS Static S3 Hosting & CloudFront

Esse problema se apresentou pelo CloudFront respondendo com uma mensagem 403 Access Denied porque esperava / algum / outro / caminho para existir na minha pasta S3, mas esse caminho só existe internamente no roteamento do React com o roteador react.

A solução foi configurar uma regra de páginas de erro de distribuição. Vá para as configurações do CloudFront e escolha sua distribuição. Em seguida, vá para a guia “Páginas de erro”. Clique em “Create Custom Error Response” e adicione uma input para 403, já que esse é o código de status de erro que recebemos. Defina o Caminho da Página de Resposta como /index.html e o código de status como 200. O resultado final me surpreende com sua simplicidade. A página de índice é exibida, mas a URL é preservada no navegador, portanto, assim que o aplicativo reagir for carregado, ele detectará o caminho da URL e navegará até a rota desejada.

Regra Páginas de erro 403

Se você estiver usando o aplicativo Create React:

No entanto, há uma ótima experiência com soluções para as principais plataformas de hospedagem que você pode encontrar AQUI na página Criar Aplicativo de Reação. Por exemplo, eu uso o React Router v4 e o Netlify para o meu código frontend. Tudo o que foi preciso foi adicionar um arquivo à minha pasta pública (“_redirects”) e uma linha de código nesse arquivo:

 /* /index.html 200 

Agora meu site renderiza corretamente caminhos como mysite.com/pricing quando inserido no navegador ou quando alguém acessa a atualização.

Pilha de produção: React, React Router v4, BrowswerRouter, Express, Nginx

1) User BrowserRouter para URLs bonitas

 // app.js import { BrowserRouter as Router } from 'react-router-dom' const App = () { render() { return (  // your routes here  ) } } 

2) Adicione index.html a todas as solicitações desconhecidas usando /*

 // 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) pacote webpack com webpack -p

4) execute nodemon server.js ou node server.js

Eu usei criar-reagir-app para fazer um site agora e tive o mesmo problema apresentado aqui. Eu uso BrowserRouting do BrowserRouting react-router-dom . Eu estou rodando em um servidor Nginx e o que resolveu para mim foi adicionar o seguinte em /etc/nginx/yourconfig.conf

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

O que corresponde a adicionar o seguinte ao .htaccess , caso você esteja executando o Appache

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

Esta também parece ser a solução sugerida pelo Facebook e pode ser encontrada aqui

Tente adicionar o arquivo “.htaccess” dentro da pasta pública com o código abaixo.

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

Se você tiver um retorno ao seu index.html, certifique-se de que no seu arquivo index.html você tenha isto:

  

Isso pode diferir de projeto para projeto.

Eu não estou usando a renderização do lado do servidor ainda, mas eu tive o mesmo problema que o OP, onde Link parecia funcionar bem na maioria das vezes, mas falhou quando eu tinha um parâmetro. Vou documentar minha solução aqui para ver se isso ajuda alguém.

Meu jsx principal contém isto:

  

Isso funciona bem para o primeiro link correspondente, mas quando o: id muda nas expressões aninhadas na página de detalhes desse modelo, a URL muda na barra do navegador, mas o conteúdo da página não foi alterado inicialmente para refletir o modelo vinculado.

O problema foi que eu usei o props.params.id para definir o modelo em componentDidMount . O componente é montado apenas uma vez, o que significa que o primeiro modelo é aquele que fica na página e os Links subsequentes alteram os objects, mas deixam a página inalterada.

Definir o modelo no estado do componente em componentDidMount e em componentWillReceiveProps (onde é baseado nos próximos props) resolve o problema e o conteúdo da página é alterado para refletir o modelo desejado.

Este tópico é um pouco antigo e está resolvido, mas gostaria de sugerir-lhe uma solução simples, clara e melhor. Funciona se você usar o servidor da web.

Cada servidor da Web tem a capacidade de redirect o usuário para uma página de erro no caso de HTTP 404. Para resolver esse problema, é necessário redirect o usuário para a página de índice.

Se você usar o servidor base Java (tomcat ou qualquer servidor de aplicativos java), a solução poderia ser a seguinte:

web.xml:

 < ?xml version="1.0" encoding="UTF-8"?>    index.jsp    404 /index.jsp   

Exemplo:

  • GET http://example.com/about
  • Servidor Web lança http 404 porque esta página não existe no lado do servidor
  • a configuração da página de erro informa ao servidor que envia a página index.jsp de volta ao usuário
  • então, o JS fará o resto do trabalho no lado do cliente, porque o URL no lado do cliente ainda é http://example.com/about .

É isso, não precisa mais de magia 🙂

Se você estiver hospedando no IIS; Adicionando isso ao meu webconfig resolvi meu problema

          

Você pode fazer configurações semelhantes para qualquer outro servidor

Eu tive esse mesmo problema e esta solução funcionou para nós ..

Fundo:

Estamos hospedando vários aplicativos no mesmo servidor. Quando atualizaríamos o servidor não entenderia onde procurar nosso índice na pasta dist desse aplicativo em particular. O link acima irá levá-lo para o que funcionou para nós … Espero que isso ajude, como nós gastamos bastante horas em descobrir uma solução para as nossas necessidades.

Nós estamos usando:

 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" } 

meu 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] } 

meu 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(  
, document.getElementById('mount') )

meu 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!'); }); 

Solução para Preact com o preact-router

Funciona com atualização e access direto

Para aqueles que estão descobrindo isso via Google, aqui está uma demonstração do histórico de hash-roteador + hash:

 const { h, Component, render } = preact; /** @jsx h */ const { Router } = preactRouter; const { createHashHistory } = History; const App = () => ( 

all paths in preact-router are still /normal/urls. using hash history rewrites them to /#/hash/urls

Example: page 2

Page Two

back to home
);

https://jsfiddle.net/developit/gLyL6rbn/

Se você estiver hospedando seu aplicativo reagente no IIS, basta adicionar um arquivo web.config contendo:

 < ?xml version="1.0" encoding="utf-8"?>         

Isso informará ao servidor IIS para retornar a página principal ao cliente, em vez do erro 404 e não será necessário usar o histórico de hash.

No caso, alguém está procurando solução no React JS SPA com o Laravel. A resposta aceita é a melhor explicação de por que tais problemas acontecem. Como já foi explicado, você precisa configurar o lado do cliente e o lado do servidor. Em seu modelo blade, inclua o arquivo js empacotado, certifique-se de usar a URL facade como esta

  

Em suas rotas, certifique-se de adicioná-lo ao endpoint principal, onde está o template blade. Por exemplo,

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

O acima é o ponto final principal do modelo da lâmina. Agora adicione uma rota opcional também

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

O problema que acontece é que primeiro o modelo da lâmina é carregado, então o roteador reage. Então, quando você está carregando '/setting-alerts' , ele carrega o html e o js. Mas quando você carrega '/setting-alerts/about' , ele primeiro é carregado no lado do servidor. Desde no lado do servidor, não há nada neste local, ele retorna não encontrado. Quando você tem aquele roteador opcional, ele carrega a mesma página e o roteador reage também é carregado, então o carregador de reação decide qual componente exibir. Espero que isto ajude.

Muitas boas respostas estão aqui e não há necessidade de escrever mais respostas aqui.

mas estou dando outro bom link aqui

https://css-tricks.com/learning-react-router/#article-header-id-9

É bastante simples quando você tem não pode obter erro 403 após atualizar o componente dom. basta adicionar essa linha na configuração do seu pacote da web, ‘historyApiFallback: true’. este savez meu dia inteiro.

Se você estiver usando o Express ou algum outro framework no backend, você pode adicionar a configuração similar como abaixo e verificar o caminho público do Webpack na configuração, ele deve funcionar bem mesmo no recarregamento se você estiver usando o BrowserRouter

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

If you’re using firebase all you have to do is make sure you’ve got a rewrites property in your firebase.json file in the root of your app (in the hosting section).

Por exemplo:

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

Hope this saves somebody else a hoard of frustration and wasted time.

Codificação feliz …

Further reading on the subject:

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

Firebase CLI: “Configure as a single-page app (rewrite all urls to /index.html)”

For those who are using IIS 10, this is what you should do to make this right. Be sure that you are using browserHistory with this. As for reference I will give the code for the routing, but this is not what matters, what matters is the next step after the component code below:

 class App extends Component { render() { return (  
) } } render (, window.document.getElementById("app"));

Since the problem is IIS receives request from client browsers, it will interpret the URL as if it is asking for a page, then returns a 404 page since there is no available page. Do the following:

  1. Open IIS
  2. Expand Server then open the Sites Folder
  3. Click the website/application
  4. Go to the Error Pages
  5. Open the 404 error status item in the list
  6. Instead of the option “Insert content from static file into the error response”, change it to “Execute a URL on this site” and add “/” slash value to the URL.

And it will now work fine.

insira a descrição da imagem aqui insira a descrição da imagem aqui

Espero que ajude. 🙂

Practical workaround:

  1. Duplicate and rename original html file as joblist.html
  2. Use joblist.html as route path

No server-side changes required.