React中SSR原理的详细介绍

上面我们说了，在 SSR 中，服务器端渲染的代码和客户端的代码的入口路由代码是有差异的，所以在 Webpack 中，Entry 的配置首先肯定是不同的。

在服务器端运行的代码，有时我们需要引入 Node 中的一些核心模块，我们需要 Webpack 做打包的时候能够识别出类似的核心模块，一旦发现是核心模块，不必把模块的代码合并到最终生成的代码中，解决这个问题的方法非常简单，在服务器端的 Webpack配置中，你只要加入 target: node 这个配置即可。

服务器端渲染的代码，如果加载第三方模块，这些第三方模块也是不需要被打包到最终的源码中的，因为 Node 环境下通过 NPM 已经安装了这些包，直接引用就可以，不需要额外再打包到代码里。为了解决这个问题，我们可以使用 webpack-node-externals 这个插件，代码中的 nodeExternals 指的就是这个插件，通过这个插件，我们就能解决这个问题。关于 Node 这里的打包问题，可能看起来有些抽象，不是很明白的同学可以仔细读一下 webpack-node-externals 相关的文章或文档，你就能很好的明白这里存在的问题了。

接下来我们继续分析，当我们的 React 代码中引入了一些 CSS 样式代码时，服务器端打包的过程会处理一遍 CSS，而客户端又会处理一遍。查看配置，我们可以看到，服务器端打包时我们用了 isomorphic-style-loader，它处理 CSS 的时候，只在对应的 DOM 元素上生成 class 类名，然后返回生成的 CSS 样式代码。

而在客户端代码打包配置中，我们使用了 css-loader 和 style-loader，css-loader 不但会在 DOM 上生成 class 类名，解析好的 CSS 代码，还会通过 style-loader 把代码挂载到页面上。不过这么做，由于页面上的样式实际上最终是由客户端渲染时添加上的，所以页面可能会存在一开始没有样式的情况，为了解决这个问题， 我们可以在服务器端渲染时，拿到 isomorphic-style-loader 返回的样式代码，然后以字符串的形式添加到服务器端渲染的 HTML 之中。

而对于图片等类型的文件引入，url-loader 也会在服务器端代码和客户端代码打包的过程中分别进行打包，这里，我偷了一个懒，无论服务器端打包还是客户端打包，我都让打包生成的文件存储在 public 目录下，这样，虽然文件会打包出来两遍，但是后打包出来的文件会覆盖之前的文件，所以看起来还是只有一份文件。

当然，这样做的性能和优雅性并不高，只是给大家提供一个小的思路，如果想进行优化，你可以让图片的打包只进行一次，借助一些 Webpack 的插件，实现这个也并非难事，你甚至可以自己也写一个 loader，来解决这样的问题。

如果你的 React 应用中没有异步数据的获取，单纯的做一些静态内容展示，经过上面的配置，你会发现一个简单的 SSR 应用很快的就可以被实现出来了。但是，真正的一个 React 项目中，我们肯定要有异步数据的获取，绝大多数情况下，我们还要使用 Redux 管理数据。而如果想在 SSR 应用中实现，就不是这么简单了。

SSR 中异步数据的获取 + Redux 的使用

客户端渲染中，异步数据结合 Redux 的使用方式遵循下面的流程（对应图中第 12 步）：

1. 创建 Store

2. 根据路由显示组件

3. 派发 Action 获取数据

4. 更新 Store 中的数据

5. 组件 Rerender

而在服务器端，页面一旦确定内容，就没有办法 Rerender 了，这就要求组件显示的时候，就要把 Store 的数据都准备好，所以服务器端异步数据结合 Redux 的使用方式，流程是下面的样子（对应图中第 4 步）：

1. 创建 Store

2. 根据路由分析 Store 中需要的数据

3. 派发 Action 获取数据

4. 更新Store 中的数据

5. 结合数据和组件生成 HTML，一次性返回

下面，我们分析下服务器端渲染这部分的流程：

1. 创建 Store：这一部分有坑，要注意避免，大家知道，客户端渲染中，用户的浏览器中永远只存在一个 Store，所以代码上你可以这么写：

const store = createStore(reducer, defaultState)
export default store;
然而在服务器端，这么写就有问题了，因为服务器端的 Store 是所有用户都要用的，如果像上面这样构建 Store，Store 变成了一个单例，所有用户共享 Store，显然就有问题了。所以在服务器端渲染中，Store 的创建应该像下面这样，返回一个函数，每个用户访问的时候，这个函数重新执行，为每个用户提供一个独立的 Store：
const getStore = (req) => {
  return createStore(reducer, defaultState);
}
export default getStore;
根据路由分析 Store 中需要的数据： 要想实现这个步骤，在服务器端，首先我们要分析当前出路由要加载的所有组件，这个时候我们可以借助一些第三方的包，比如说 react-router-config, 具体这个包怎么使用，不做过多说明，大家可以查看文档，使用这个包，传入服务器请求路径，它就会帮助你分析出这个路径下要展示的所有组件。
派发 Action 获取数据: 接下来，我们在每个组件上增加一个获取数据的方法：
Home.loadData = (store) => {
  return store.dispatch(getHomeList())
}
这个方法需要你把服务器端渲染的 Store 传递进来，它的作用就是帮助服务器端的 Store 获取到这个组件所需的数据。 所以，组件上有了这样的方法，同时我们也有当前路由所需要的所有组件，依次调用各个组件上的 loadData 方法，就能够获取到路由所需的所有数据内容了。
更新 Store 中的数据: 其实，当我们执行第三步的时候，已经在更新 Store 中的数据了，但是，我们要在生成 HTML 之前，保证所有的数据都获取完毕，这怎么处理呢？
// matchedRoutes 是当前路由对应的所有需要显示的组件集合
matchedRoutes.forEach(item => {
  if (item.route.loadData) {
    const promise = new Promise((resolve, reject) => {
      item.route.loadData(store).then(resolve).catch(resolve);
    })
    promises.push(promise);
  }
})

Promise.all(promises).then(() => {
  // 生成 HTML 逻辑
})
这里，我们使用 Promise 来解决这个问题，我们构建一个 Promise 队列，等待所有的 Promise 都执行结束后，也就是所有 store.dispatch 都执行完毕后，再去生成 HTML。这样的话，我们就实现了结合 Redux 的 SSR 流程。
在上面，我们说到，服务器端渲染时，页面的数据是通过 loadData 函数来获取的。而在客户端，数据获取依然要做，因为如果这个页面是你访问的第一个页面，那么你看到的内容是服务器端渲染出来的，但是如果经过 react-router 路由跳转道第二个页面，那么这个页面就完全是客户端渲染出来的了，所以客户端也要去拿数据。
在客户端获取数据，使用的是我们最习惯的方式，通过 componentDidMount 进行数据的获取。这里要注意的是，componentDidMount 只在客户端才会执行，在服务器端这个生命周期函数是不会执行的。所以我们不必担心 componentDidMount 和 loadData 会有冲突，放心使用即可。这也是为什么数据的获取应该放到 componentDidMount 这个生命周期函数中而不是 componentWillMount 中的原因，可以避免服务器端获取数据和客户端获取数据的冲突。
Node 只是一个中间层
上一部分我们说到了获取数据的问题，在 SSR 架构中，一般 Node 只是一个中间层，用来做 React 代码的服务器端渲染，而 Node 需要的数据通常由 API 服务器单独提供。
这样做一是为了工程解耦，二也是为了规避 Node 服务器的一些计算性能问题。
请大家关注图中的第 4 步和第 12，13 步，我们接下来分析这几个步骤。
服务器端渲染时，直接请求 API 服务器的接口获取数据没有任何问题。但是在客户端，就有可能存在跨域的问题了，所以，这个时候，我们需要在服务器端搭建 Proxy 代理功能，客户端不直接请求 API 服务器，而是请求 Node 服务器，经过代理转发，拿到 API 服务器的数据。
这里你可以通过 express-http-proxy 这样的工具帮助你快速搭建 Proxy 代理功能，但是记得配置的时候，要让代理服务器不仅仅帮你转发请求，还要把 cookie 携带上，这样才不会有权限校验上的一些问题。
// Node 代理功能实现代码
app.use('/api', proxy('http://apiServer.com', {
  proxyReqPathResolver: function (req) {
    return '/ssr' + req.url;
  }
}));
总结：
到这里，整个 SSR 的流程体系中关键知识点的原理就串联起来了，如果你之前适用过 SSR 框架，那么这些知识点的整理我相信可以从原理层面很好的帮助到你。
当然，我也考虑到阅读本篇文章的同学可能有很大一部分对 SSR 的基础知识非常有限，看了文章可能会云里雾里，这里为了帮助这些同学，我编写了一个非常简单的 SSR 框架，代码放在这里：
https://files.alicdn.com/tpss...
初学者结合上面的流程图，一步步梳理流程图中的逻辑，梳理结束后，回来再看一遍这篇文章，相信大家就豁然开朗了。
当然在真正实现 SSR 架构的过程中，难点有时不是实现的思路，而是细节的处理。比如说如何针对不同页面设置不同的 title 和 description 来提升 SEO 效果，这时候，我们其实可以用 react-helmet 这样的工具帮我们达成目标，这个工具对客户端和服务器端渲染的效果都很棒，值得推荐。还有一些诸如工程目录的设计，404，301 重定向情况的处理等等，不过这些问题，我们只需要在实践中遇到的时候逐个攻破就可以了。
好了，关于 SSR 的全部分享就到这里，希望这篇文章能够或多或少帮助到你。
以上就是React中SSR原理的详细介绍的详细内容，更多请关注php中文网其它相关文章！
				
				

					
微信
					
分享
				

网站建设是一个广义的术语，涵盖了许多不同的技能和学科中所使用的生产和维护的网站。



  
关键词：React中SSR原理的详细介绍