반응 라우터 브라우저 기록 새로 고침 페이지 404 문제를 해결하는 방법

React를 사용하여 새 프로젝트를 개발할 때 페이지를 새로 고치고 2차 또는 3차 라우팅에 직접 액세스하면 액세스가 실패하고 404 또는 리소스 로딩 예외가 발생합니다. 이 기사에서는 이 문제를 분석하고 해결 방법을 요약합니다. 이 글은 주로 React-Router BrowserHistory 새로고침 페이지의 404 문제에 대한 해결책을 소개합니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

Background

webpack-dev-server를 로컬 개발 서버로 사용하는 경우 일반적인 상황에서는 webpack-dev-server 명령만 사용하여 시작하면 됩니다. 다음 두 가지 상황에서는 내장된 Set 라우팅과 비동기 로딩 라우팅이 필요한 경우가 많습니다.

1. 단일 페이지 애플리케이션 라우팅을 구축하기 위해 React-router와 같은 라우팅 라이브러리를 사용합니다.

2. html-webpack을 사용합니다. -로드된 js의 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그를 html 문서에 동적으로 삽입하는 플러그인 ;

이때 localhost:9090에 액세스하면 페이지와 js 및 기타 파일이 정상적으로 로드될 수 있지만, 두 번째 수준 또는 심지어 세 번째 수준 라우팅에 액세스하거나 localhost:9090/posts/92와 같은 페이지를 새로 고쳐야 할 수도 있습니다. 두 가지 상황이 있습니다:

1. 페이지가 로드되지 않고 가져올 수 없습니다. (404)가 반환됩니다.

2. 서비스가 응답하지만 webpack 처리에 의해 출력된 html 파일이 반환되지 않아 js 리소스를 로드할 수 없습니다. 두 번째 상황은 그림과 같습니다.

그럼 정상적인 액세스를 보장하기 위해 각 페이지의 라우팅을 어떻게 처리해야 할까요? 해당 블로거는 문서 구성을 검색한 후 소스를 추적하고 문제를 해결했습니다. 이 글은 전체 문제 해결 과정을 요약한 것입니다.

문제 분석

문제를 발견한 후 문제를 분석하고 해결하기 시작합니다. 우리는 이 문제가 일반적으로 두 가지 이유 때문에 발생한다고 판단합니다:

1. react-router road front-end 구성. ;

2. webpack-dev-server 서비스 구성

react-router

프론트엔드 라우팅이 문제 식별이 더 쉽고, 분석에 더 편리하며, 반응 라우터에 더 친숙하기 때문입니다. 먼저 반응 라우터 라우팅 라이브러리를 쿼리 관련 구성 정보에 대해 browserHistory를 사용하면 실제 URL이 생성되고 초기/요청을 처리하는 데 문제가 없다고 문서에서 언급한 것을 발견했습니다. , 페이지를 새로 고치거나 URL에 직접 액세스하면 올바르게 응답할 수 없다는 것을 알게 될 것입니다. 자세한 내용은 참조 문서를 확인하세요. 이 문서는 또한 여러 서버 구성 솔루션을 제공합니다:

Node

const express = require('express')
const path = require('path')
const port = process.env.PORT || 8080
const app = express()

// 通常用于加载静态资源
app.use(express.static(__dirname + '/public'))

// 在你应用 JavaScript 文件中包含了一个 script 标签
// 的 index.html 中处理任何一个 route
app.get('*', function (request, response){
 response.sendFile(path.resolve(__dirname, 'public', 'index.html'))
})

app.listen(port)
console.log("server started on port " + port)

Node를 사용하는 경우 서비스로서 모든 요청을 수신하고 대상 html 문서(리소스의 js html 인용)를 반환하려면 와일드카드 *를 사용해야 합니다.

Nginx

nginx 서버를 사용하는 경우 try_files 지시어만 사용해야 합니다.

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

Apache

Apache 서버를 사용하는 경우 . ht 프로젝트 루트 디렉터리에 액세스 파일에는 다음 내용이 포함되어 있습니다.

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

다음은 서버에 대한 구성입니다. 안타깝게도 아직 해당 서버를 도입하지 않았으며 webpack에 내장된 서비스를 사용했습니다. -dev-server, 그러나 문제를 발견했습니다. 문제는 라우팅 요청이 반환된 HTML 문서와 일치할 수 없다는 것이므로 이제 webpack-dev-server 문서에서 해결책을 찾을 때입니다.

webpack-dev-server

공식 webpack-dev-server 문서에 대해 불평해야 합니다. 블로거는 문제를 명확하게 보기 전에 문서를 여러 번 읽었습니다.

1. output.publicPath가 수정되지 않았습니다. 즉, webpack 구성 파일에 선언된 값이 없습니다. 이는 기본값입니다.

2. output.publicPath를 사용자 정의 값으로 설정하세요.

문서를 보려면 여기를 클릭하세요.

default

기본적으로 output.publicPath 값은 수정되지 않습니다. webpack-dev-server의historyApiFallback 구성만 설정하면 됩니다.

devServer: {
 historyApiFallback: true
}

HTML5 기록을 사용하는 경우 API를 사용하려면 404 응답 대신 index.html을 제공해야 할 수 있습니다. 이는 HistoryApiFallback: true

애플리케이션이 HTML5 기록 API를 사용하는 경우 index.html을 사용하여 404에 응답해야 할 수도 있습니다. 질문 요청 시에는 g HistoryApiFallback: true

Custom value

을 설정하세요. 그러나 Webpack 구성에서 output.publicPath를 수정한 경우 리디렉션할 URL을 지정해야 합니다. 이 작업은 HistoryApiFallback.index 옵션을 사용하여 수행됩니다.

Webpack 구성에서 output.publicPath를 수정한 경우 리디렉션할 URL을 지정해야 합니다. 파일에서 output.publicPath 값이 수정된 경우 요청 리디렉션을 선언하고 HistoryApiFallback.index를 구성해야 합니다. 값.

// output.publicPath: '/assets/'
historyApiFallback: {
 index: '/assets/'
}

Proxy

위의 방법을 사용하면 항상 라우팅 요청 응답 예외가 발생하여 문제를 완전히 해결할 수 없다는 것을 알았으므로 블로거는 계속해서 더 나은 솔루션을 찾았습니다.

Click 문서를 보려면 여기

The proxy can be optionally bypassed based on the return from a function. The function can inspect the HTTP request, response, and any given proxy options. It must return either false or a URL path that will be served instead of continuing to proxy the request.

代理提供通过函数返回值响应请求方式，针对不同请求进行不同处理，函数参数接收HTTP请求和响应体，以及代理配置对象，这个函数必须返回false或URL路径，以表明如何继续处理请求，返回URL时，源请求将被代理到该URL路径请求。

proxy: {
 '/': {
  target: 'https://api.example.com',
  secure: false,
  bypass: function(req, res, proxyOptions) {
   if (req.headers.accept.indexOf('html') !== -1) {
    console.log('Skipping proxy for browser request.');
    return '/index.html';
   }
  }
 }
}

如上配置，可以监听https://api.example.com域下的/开头的请求（等效于所有请求），然后判断请求头中accept字段是否包含html，若包含，则代理请求至/index.html，随后将返回index.html文档至浏览器。

解决问题

综合以上方案，因为在webpack配置中修改了output.publicPath为/assets/，所以博主采用webpack-dev-server Proxy代理方式解决了问题：

const PUBLICPATH = '/assets/'
...
proxy: {
 '/': {
  bypass: function (req, res, proxyOptions) {
   console.log('Skipping proxy for browser request.')
   return `${PUBLICPATH}/index.html`
  }
 }
}

监听所有前端路由，然后直接返回${PUBLICPATH}/index.html，PUBLICPATH就是设置的output.publicPath值。

另外，博主总是习惯性的声明，虽然不设置该属性也能满足预期访问效果：

historyApiFallback: true

相关推荐：

使用Django实现自定义404，500页面的方法

IDEA导入web项目详解(解决访问的404)

thinkphp制作404跳转页的简单实现方法

위 내용은 반응 라우터 브라우저 기록 새로 고침 페이지 404 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!