文章目的
- 分享/记录 直接集成好的 react + mobx + ssr 的项目模板，方便快速搭建新项目
- 分享/记录 在集成项目的过程中，遇到的一些问题
方案案例仓库
方案特点
- 可以持续集成功能；
- 允许 ssr 出错自动降级，使用客户端渲染；
- 允许项目中存在部分页面使用同构，部分不使用同构；
- 案例中的 mobx 同构，不需要使用 Provider 提供整体的数据树；
遇到过的问题
1、monorepo 项目结构中，使用 babel 7 编译 node_modules 模块的问题
问题解析：
babel 7 开始，在使用 .babelrc 的情况下，默认忽略 node_modules，导致 node_modules 中 symlink 的 模块源码无法被正常编译
解决方法：
改为 babel.config.js 进行 babel 配置描述，可以顺利进行 symlink 模块的编译，并提高配置的灵活性
2、css-loader，babel-react-css-module 在同构两端 hash 问题
问题描述：
同构两端 的 style-name 编译过后，class name 后缀的 hash 不一致
问题解析：
查看 css-loader 源码，css-loader 与 babel-react-css-module 的配置项中，有个 context 的输入项，用于生产 hash。context 可为任意的 字符串，但是，context 在 css-loader 源码中会被 path resolve (context 与 resourcePath)，如果 context 不是一个有效的路径字符串，那么同构两侧最终用于生产 hash 的依据会不一致
问题解决：
a、将同构两侧的 css-loader 中的 context 统一改为当前项目的根路径
b、得益于使用 babel.config.js，为同构两端的 react-css-module 动态设置 context 为当前项目的根路径；
结果：
同构两端生产的 class 命名一致，同时保留 css-modules 特性
3、webpack 打包 nodejs 模块下 选择模块化标准问题（经典问题）
问题描述：
同构端获取客户端源码文件后，进行打包，打包后的代码无法在服务端进行运行，提示 “__webpack__require(…) is not a function”或者 模块初始化后没有正常 export
问题解析：
针对 webpack 配置，将输出 bundle 模块化形式改为可直接被 nodejs 读取使用的 commonjs 形式（commonjs2）
4、babel 配置中，preset-env 的设置问题
问题描述：
同构端 无需运行 preset-env
问题解决：
在同构端 的 babel.config.js 中，去除 preset-env
5、resolve-url-loader 在同构两端的配置问题
问题描述：
同构端 复用 客户端的打包配置，打包过程中，报错 媒体文件（图片，公共样式）无法 找到
问题解析 与 解决：
同理 css-loader，需要对同构端的 resolve-url-loader 的 root 指定为客户端模块的对应的资源目录
注意点
无法避免的问题，用于同构处理的客户端模块，必须考虑被同构使用时的兼容性处理，并非所有的客户端模块可以直接被用于同构
