Example tutorial on how the server cooperates with BrowserRouter under react-router 4.0

react-router plays an important role in react projects as the react framework routing solution. This article mainly introduces the detailed explanation of how the server cooperates with BrowserRouter under react-router 4.0. The editor thinks it is quite good, so I will share it with you now and give it as a reference. Let’s follow the editor to take a look, I hope it can help everyone.

In react-router version 4.0, the API has been greatly modified compared with previous versions. The component commonly used in 2.0 and 3.0 is no longer commonly used as the underlying routing configuration component. Instead, There are four different routing components:

, , ,

The component is in memory Saving "URL" information does not modify the browser's address bar and is often used in non-browser environments such as React Native or test environments.

The component can be seen from its name that it never modifies the route, which is very useful when rendering on the server side.

component We are most familiar with the routing component without going into details. Here I will talk about the pitfalls I encountered when using the recommended by react-router.

and can both implement the front-end routing function. The difference is that the former is based on the rul pathname segment and the latter is based on the hash segment.

The former: http://127.0.0.1:3000/article/num1

The latter: http://127.0.0.1:3000/#/article/num1 (This is not necessarily the case , but # is indispensable)

The direct problem caused by this difference is that when it is in the second-level or multi-level routing state, refresh the page, will send the current route to the server (because it is pathname), but will not (because it is a hash segment).

Of course we don't want the front-end routes to be sent to the backend.

There is this passage in the documentation of react-router 4.0:

Note: Using hash to record navigation history does not support location.key and location.state. In previous versions we provided shims for this behavior, but there were still some issues we couldn't resolve. Any code or plugins that rely on this behavior will not function properly. Since this technology is only designed to support legacy browsers, can be used instead when used in browsers.

This requires the server to cooperate with the front-end to make some simple modifications.

The idea of ​​the modification is to reload the entry html file (my background is nodejs) when the requested url is not functional, but a front-end route.

// catch 404 and forward to error handler
app.use(function(req, res, next) {
  //判断是主动导向404页面，还是传来的前端路由。
　　 //如果是前端路由则如下处理

  fs.readFile(__dirname + '/public/dist/index.html', function(err, data){
    if(err){
      console.log(err);
      res.send('后台错误');
    } else {
      res.writeHead(200, {
        'Content-type': 'text/html',
        'Connection':'keep-alive'
      });
      res.end(data);
    }
  })
});

There are countless pitfalls here. After searching for methods on the Internet, I switched to nginx and used the try_files field to direct to the entry html. However, after redirection, the js file packaged by webpack did not exist. implement.

When checking firebug, I found that "Connection":"keep-alive" is set in the response header of this refresh;

I think the problem should be here, switch to nodejs and use 200 status to match keep-alive really solved the problem.

Refreshing the page under react-router 4.0 multi-level routing will not cause 404, but will save the front-end state.

Related recommendations:

A brief discussion on how to use react-router HashRouter and BrowserRouter

react-router browserHistory refresh How to solve the page 404 problem

Three kinds of Vue-Router to achieve jump between components

The above is the detailed content of Example tutorial on how the server cooperates with BrowserRouter under react-router 4.0. For more information, please follow other related articles on the PHP Chinese website!