为什么从B/S扩展到C/S？
- 对于企业来说，一个产品中突然多了一个CS客户端程序，相当于突然多了半个产品。企业可以稍微扩充一下产品线，或者稍微再彰显一下技术实力。
- 对于客户来说，由于项目多是定制化的性质，用户感知上CS客户端显得更加专业。
- 对于那些还在使用过时的浏览器，并且不肯更换现代浏览器的客户：我们直接提供CS客户端。避免强制推行现代浏览器的麻烦。
- 对于开发者来说，将js的纯前端单页应用转化为桌面程序，掌握这项技术也能为我们日常开发启发思路。你可能在想自己做一个跨平台/桌面应用时，多一条路可以走。
具体要做什么？
由于项目本身是纯粹的前后端分离，即前端js文件被请求后完全运行在浏览器上，再通过RESTful API与后端服务器交互。因此，将WEB前端用纯粹桌面程序（windows上即为exe可执行程序）代替成为可能。
那么，如果能把现成的、已开发的 WEB SPA 直接转换成桌面程序，岂不美哉？
我们要做的就是这个事情：将已开发好的WEB前端，直接转化为windows上的可执行程序。
（当然了，原来的WEB前端并不能受到影响）
Electron
Electron（或者看中文官网）这个工具/库就能完美解决上面说的这个事情。而我也是在ANTD的官方说明中看到说ant Design支持Electron环境才来研究它的。
Electron的原理大致说一下：
- 它封装了一个Chromium（含V8）
- 它还包装了nodejs
- Electron最后输出一个可执行程序（win上程序入口是exe）
- 这个程序执行时拉起Chromium，并且解析你的（已经开发好的、WEB版的）前端js\html\css，并将它们运行在chromium中
- electron还号称支持原生操作系统API调用，不过我们目前还用不到这个特性
因此，要想使用electron，你需要做的：
- 编译打包你的前端SPA
- 安装electron运行环境，以客户端的方式，通过命令行拉起来electron环境。在这个环境中调试你打包好的SPA（不打包直接调试可能会非常麻烦，面临很多调整。因此我建议先打包。）
- 调试没问题，你可能需要将你的产品封装成一个可执行程序了。（具体怎么做下面会讲）
- 可执行程序也没问题，你还可能需要一个installer。（具体怎么做下面会讲）
下面就详细讲一下这几步：
编译打包你原来的WEB前端
传统的webpack打包即可，这一步没什么特别的。我们使用了roadhog，直接roadhog build即可。
最后输出的还是那个几百K超大的js文件，一个css文件。以及你的public目录中不需要编译打包的内容，比如fonts目录。
调试Electron
官方的入门教程将这个步骤说的也比较清楚了，我也不细说。总之，你需要npm装electron，并且执行这个命令拉起CS客户端。
比较关键的是：你需要指定你的main.js，并且实现main.js本身。这是CS客户端程序的入口。官方提供了这个代码实现的样例，我就不附地址了，有兴趣自己去官网看。
入口代码文件内容呢，基本就是把窗口打开，并加载你打包好的那些js们，还有设置一些监听。
所以在运行electron命令之前，你需要先实现你的main.js，并（可以）把它加到现有的前端工程中。还需要再package.json指定它的路径。
封装成可执行程序
前面的调试环节完成了，你就应该对这一套东西有了一定的了解。
由于咱们这里是使用的打包好的前端，没有用源码。而打包好的前端往往和源码不放到一起----打包目录是个单独的目录。因此，对打包内容封装生成可执行程序，还需要一些额外的操作。
即：在生成可执行程序前，需要在打包好的目录中也有main.js、以及package.json（但并不需要调用npm i把所有node_module给装好，因为前面经历了编译打包过程，已经保证了node_modules里那些运行时库都包进去了），这是封装可执行程序的基础。
为什么需要这两样东西？
- main.js不需要编译。因为C/S客户端启动后，它是运行在nodejs上的，需要程序入口，还得是源文件。
- package.json中注明了程序入口，封装的exe程序会根据package.json中的设置的入口路径去找main.js
所以把这两个文件先要拷过去。
然后，npm安装electron-packager命令，安装好后执行它就行了。可执行程序生成了！
创建Installer
如果你不想让你的用户使用所谓的“绿色版”，想把自己的bigger提高的更多一些，那么你可以尝试创建Installer。让用户享受对exe程序“下一步”接“下一步”的步步为营的安装过程，带来丝滑体验。
不展开说了，反正这个bigger我本人并没有装。感兴趣自己去看官网吧，不附链接。
踩过的坑
干货预警 如果全过程真像上面讲的那样丝滑，那这篇写的就没什么意义了。
坑A 请求失利
基本的WEB前端请求后端，只需知道后端的API的URI，然后请求时会自动拼上当前域名发送请求。这是很自然的：因为访问WEB端肯定是需要域名在浏览器中进行访问的。发送请求时自然会自动拼上这个域名进行HTTP请求。
但是，C/S的客户端自己名没有域名。
因此，对于客户端，需要额外写一个服务器域名/配服务器地址。在进行RESTful请求时拼接成完整请求地址。
坑B 资源路径访问错误
这个情况比较个别，但是如果使用了我们这一套架构，一定会遇到这个问题。
由于本地化了antd的iconfont，资源下载下来了并放到系统中，按照antd官方的iconfont本地化教程，需要在主题less文件中配置@icon-url。这个值代表iconfont资源放到本地的相对路径，但是必须以/斜杠开头，不然roadhog不会让你通过编译和打包的，这个阶段它会报资源找不到。
但是一旦编译打包通过，在C/S客户端执行时，它会识别成绝对路径。
这个问题的规避办法：
- 调试时，根据环境变量（下面的坑C会解释环境变量的事情），如果是electron的打包，则将这个绝对路径变成完整路径，即根据本机的当前路径将这个icon-url改写，并写死。打包完成后直接调试没有问题。而且开发者在这个阶段，目前并不需要关心这个事情。
- 发布封装的可执行程序时，这就有点恶心了。因为不可写死绝对路径，每个人的电脑的路径都是不一样的。所以，需要手动改写编译好的index.css文件，进去找到这个路径并改掉它。目前我没别的好办法。
坑C 区分web模式和electron模式
这个非常有趣，因为我们的程序中还是有些细微的地方要对两种模式加以区分的。比如说，遇到上面两个问题，就要对两种模式分别对待。
这就要求程序中要有些if-else来区分两种模式（程序需要知道：我究竟是在调试web还是electron？我究竟是在打包web还是electron？），从而执行不同的逻辑。
那如何区分？我目前的方式是使用环境变量。
即electron启动时，和electron打包时，给某个环境变量赋值。这样，在运行时，直接判断该环境变量即可。
这里有几点需要注意：
- 程序启动和打包，是靠roadhog发起的，说白了本质上还是通过nodejs程序来启动的。
- C/S客户端启动时通过main.js加载的，这也是nodejs程序。
- 不管是WEB端还是C/S客户端，都尽量不要依赖于它执行时的环境的环境变量。也就是说，如果用户使用前还得配环境变量，那岂不是非常恶心？请参见java早期的版本：需要初学者使用java开发前，要硬着头皮配很多不知所以的环境变量。
- 而且WEB和C/S核心中的js是运行在浏览器中的，它如果能检测到系统中的环境变量也是奇了。
因此，需要在nodejs中判断环境变量。而且如果前端包中有依赖变量的地方，则必须在打包前，将变量的值定下来。
具体说一下我的做法：
- 在package.json中，配两个script
"build_electron": "set ENABLE_ELECTRON=true && roadhog build"和"start_electron": "set DEBUG_ELECTRON=true &&electron ."，分别表示打包electron和调试electron。 - 实质上分别是roadhog打包，和electron命令调试。
- 在这两个命令前，分别设置了
ENABLE_ELECTRON、DEBUG_ELECTRON两环境变量。 - 在roadhog的配置文件中，检测
ENABLE_ELECTRON，如果存在，则define一个js对象。这是roadhog提供的语法糖，这个js对象可以在react的js中直接拿来用。这样在react的js执行中，就知道自己是被谁启动或者是被谁打包的了。 - 有了这个define对象，就可以具体解决坑A的问题。即判断这个对象的值，如果检测到在electron模式下，就将RESTful API的url前面拼接上服务器地址。（这个对象在代码中未定义，它是被roadhog强行写进来的嘛，因此eslint肯定报错，想办法规避吧）
- 而有了
DEBUG_ELECTRON就可以知道C/S是运行在调试模式还是发布模式了。因为毕竟调试和发布还是要有点区别。这个变量是在main.js里进行判断和使用的，不影响别处的逻辑。
Electron个人体会
后来才知道，这东西原来是当前主流。
起因是我用电脑打开虾米音乐想听歌，发现虾米报错了。本来想直接关了，发现是个js错误，就仔细看了下，然后发现了不得了的事情：虾米客户端是用electron打包的。
然后我又看了网页云音乐客户端，居然也是。。。。
然后我又看了其他几个软件。。。。
行吧，反正是误打误撞积累了点“主流技术”开发经验。
