入坑React之八 SPA用electron暴改C/S客户端程序

2017-08-22  本文已影响1673人  松鼠杨

为什么从B/S扩展到C/S?

  1. 对于企业来说,一个产品中突然多了一个CS客户端程序,相当于突然多了半个产品。企业可以稍微扩充一下产品线,或者稍微再彰显一下技术实力。
  2. 对于客户来说,由于项目多是定制化的性质,用户感知上CS客户端显得更加专业。
  3. 对于那些还在使用过时的浏览器,并且不肯更换现代浏览器的客户:我们直接提供CS客户端。避免强制推行现代浏览器的麻烦。
  4. 对于开发者来说,将js的纯前端单页应用转化为桌面程序,掌握这项技术也能为我们日常开发启发思路。你可能在想自己做一个跨平台/桌面应用时,多一条路可以走。

具体要做什么?

由于项目本身是纯粹的前后端分离,即前端js文件被请求后完全运行在浏览器上,再通过RESTful API与后端服务器交互。因此,将WEB前端用纯粹桌面程序(windows上即为exe可执行程序)代替成为可能。

那么,如果能把现成的、已开发的 WEB SPA 直接转换成桌面程序,岂不美哉?

我们要做的就是这个事情:将已开发好的WEB前端,直接转化为windows上的可执行程序。
(当然了,原来的WEB前端并不能受到影响)

Electron

Electron(或者看中文官网)这个工具/库就能完美解决上面说的这个事情。而我也是在ANTD的官方说明中看到说ant Design支持Electron环境才来研究它的。

Electron的原理大致说一下:

因此,要想使用electron,你需要做的:

下面就详细讲一下这几步:

编译打包你原来的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里那些运行时库都包进去了),这是封装可执行程序的基础。

为什么需要这两样东西?

所以把这两个文件先要拷过去。

然后,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客户端执行时,它会识别成绝对路径。

这个问题的规避办法:

  1. 调试时,根据环境变量(下面的坑C会解释环境变量的事情),如果是electron的打包,则将这个绝对路径变成完整路径,即根据本机的当前路径将这个icon-url改写,并写死。打包完成后直接调试没有问题。而且开发者在这个阶段,目前并不需要关心这个事情。
  2. 发布封装的可执行程序时,这就有点恶心了。因为不可写死绝对路径,每个人的电脑的路径都是不一样的。所以,需要手动改写编译好的index.css文件,进去找到这个路径并改掉它。目前我没别的好办法。

坑C 区分web模式和electron模式

这个非常有趣,因为我们的程序中还是有些细微的地方要对两种模式加以区分的。比如说,遇到上面两个问题,就要对两种模式分别对待。

这就要求程序中要有些if-else来区分两种模式(程序需要知道:我究竟是在调试web还是electron?我究竟是在打包web还是electron?),从而执行不同的逻辑。

那如何区分?我目前的方式是使用环境变量

即electron启动时,和electron打包时,给某个环境变量赋值。这样,在运行时,直接判断该环境变量即可。

这里有几点需要注意:

因此,需要在nodejs中判断环境变量。而且如果前端包中有依赖变量的地方,则必须在打包前,将变量的值定下来。

具体说一下我的做法:

Electron个人体会

后来才知道,这东西原来是当前主流。

起因是我用电脑打开虾米音乐想听歌,发现虾米报错了。本来想直接关了,发现是个js错误,就仔细看了下,然后发现了不得了的事情:虾米客户端是用electron打包的。

然后我又看了网页云音乐客户端,居然也是。。。。

然后我又看了其他几个软件。。。。

行吧,反正是误打误撞积累了点“主流技术”开发经验。

上一篇下一篇

猜你喜欢

热点阅读