為什么從B/S擴(kuò)展到C/S？
- 對于企業(yè)來說，一個產(chǎn)品中突然多了一個CS客戶端程序，相當(dāng)于突然多了半個產(chǎn)品。企業(yè)可以稍微擴(kuò)充一下產(chǎn)品線，或者稍微再彰顯一下技術(shù)實力。
- 對于客戶來說，由于項目多是定制化的性質(zhì)，用戶感知上CS客戶端顯得更加專業(yè)。
- 對于那些還在使用過時的瀏覽器，并且不肯更換現(xiàn)代瀏覽器的客戶：我們直接提供CS客戶端。避免強(qiáng)制推行現(xiàn)代瀏覽器的麻煩。
- 對于開發(fā)者來說，將js的純前端單頁應(yīng)用轉(zhuǎn)化為桌面程序，掌握這項技術(shù)也能為我們?nèi)粘ｉ_發(fā)啟發(fā)思路。你可能在想自己做一個跨平臺/桌面應(yīng)用時，多一條路可以走。
具體要做什么？
由于項目本身是純粹的前后端分離，即前端js文件被請求后完全運行在瀏覽器上，再通過RESTful API與后端服務(wù)器交互。因此，將WEB前端用純粹桌面程序（windows上即為exe可執(zhí)行程序）代替成為可能。
那么，如果能把現(xiàn)成的、已開發(fā)的 WEB SPA 直接轉(zhuǎn)換成桌面程序，豈不美哉？
我們要做的就是這個事情：將已開發(fā)好的WEB前端，直接轉(zhuǎn)化為windows上的可執(zhí)行程序。
（當(dāng)然了，原來的WEB前端并不能受到影響）
Electron
Electron（或者看中文官網(wǎng)）這個工具/庫就能完美解決上面說的這個事情。而我也是在ANTD的官方說明中看到說ant Design支持Electron環(huán)境才來研究它的。
Electron的原理大致說一下：
- 它封裝了一個Chromium（含V8）
- 它還包裝了nodejs
- Electron最后輸出一個可執(zhí)行程序（win上程序入口是exe）
- 這個程序執(zhí)行時拉起Chromium，并且解析你的（已經(jīng)開發(fā)好的、WEB版的）前端js\html\css，并將它們運行在chromium中
- electron還號稱支持原生操作系統(tǒng)API調(diào)用，不過我們目前還用不到這個特性
因此，要想使用electron，你需要做的：
- 編譯打包你的前端SPA
- 安裝electron運行環(huán)境，以客戶端的方式，通過命令行拉起來electron環(huán)境。在這個環(huán)境中調(diào)試你打包好的SPA（不打包直接調(diào)試可能會非常麻煩，面臨很多調(diào)整。因此我建議先打包。）
- 調(diào)試沒問題，你可能需要將你的產(chǎn)品封裝成一個可執(zhí)行程序了。（具體怎么做下面會講）
- 可執(zhí)行程序也沒問題，你還可能需要一個installer。（具體怎么做下面會講）
下面就詳細(xì)講一下這幾步：
編譯打包你原來的WEB前端
傳統(tǒng)的webpack打包即可，這一步?jīng)]什么特別的。我們使用了roadhog，直接roadhog build即可。
最后輸出的還是那個幾百K超大的js文件，一個css文件。以及你的public目錄中不需要編譯打包的內(nèi)容，比如fonts目錄。
調(diào)試Electron
官方的入門教程將這個步驟說的也比較清楚了，我也不細(xì)說?？傊阈枰猲pm裝electron，并且執(zhí)行這個命令拉起CS客戶端。
比較關(guān)鍵的是：你需要指定你的main.js，并且實現(xiàn)main.js本身。這是CS客戶端程序的入口。官方提供了這個代碼實現(xiàn)的樣例，我就不附地址了，有興趣自己去官網(wǎng)看。
入口代碼文件內(nèi)容呢，基本就是把窗口打開，并加載你打包好的那些js們，還有設(shè)置一些監(jiān)聽。
所以在運行electron命令之前，你需要先實現(xiàn)你的main.js，并（可以）把它加到現(xiàn)有的前端工程中。還需要再package.json指定它的路徑。
封裝成可執(zhí)行程序
前面的調(diào)試環(huán)節(jié)完成了，你就應(yīng)該對這一套東西有了一定的了解。
由于咱們這里是使用的打包好的前端，沒有用源碼。而打包好的前端往往和源碼不放到一起----打包目錄是個單獨的目錄。因此，對打包內(nèi)容封裝生成可執(zhí)行程序，還需要一些額外的操作。
即：在生成可執(zhí)行程序前，需要在打包好的目錄中也有main.js、以及package.json（但并不需要調(diào)用npm i把所有node_module給裝好，因為前面經(jīng)歷了編譯打包過程，已經(jīng)保證了node_modules里那些運行時庫都包進(jìn)去了），這是封裝可執(zhí)行程序的基礎(chǔ)。
為什么需要這兩樣?xùn)|西？
- main.js不需要編譯。因為C/S客戶端啟動后，它是運行在nodejs上的，需要程序入口，還得是源文件。
- package.json中注明了程序入口，封裝的exe程序會根據(jù)package.json中的設(shè)置的入口路徑去找main.js
所以把這兩個文件先要拷過去。
然后，npm安裝electron-packager命令，安裝好后執(zhí)行它就行了。可執(zhí)行程序生成了！
創(chuàng)建Installer
如果你不想讓你的用戶使用所謂的“綠色版”，想把自己的bigger提高的更多一些，那么你可以嘗試創(chuàng)建Installer。讓用戶享受對exe程序“下一步”接“下一步”的步步為營的安裝過程，帶來絲滑體驗。
不展開說了，反正這個bigger我本人并沒有裝。感興趣自己去看官網(wǎng)吧，不附鏈接。
踩過的坑
干貨預(yù)警 如果全過程真像上面講的那樣絲滑，那這篇寫的就沒什么意義了。
坑A 請求失利
基本的WEB前端請求后端，只需知道后端的API的URI，然后請求時會自動拼上當(dāng)前域名發(fā)送請求。這是很自然的：因為訪問WEB端肯定是需要域名在瀏覽器中進(jìn)行訪問的。發(fā)送請求時自然會自動拼上這個域名進(jìn)行HTTP請求。
但是，C/S的客戶端自己名沒有域名。
因此，對于客戶端，需要額外寫一個服務(wù)器域名/配服務(wù)器地址。在進(jìn)行RESTful請求時拼接成完整請求地址。
坑B 資源路徑訪問錯誤
這個情況比較個別，但是如果使用了我們這一套架構(gòu)，一定會遇到這個問題。
由于本地化了antd的iconfont，資源下載下來了并放到系統(tǒng)中，按照antd官方的iconfont本地化教程，需要在主題less文件中配置@icon-url。這個值代表iconfont資源放到本地的相對路徑，但是必須以/斜杠開頭，不然roadhog不會讓你通過編譯和打包的，這個階段它會報資源找不到。
但是一旦編譯打包通過，在C/S客戶端執(zhí)行時，它會識別成絕對路徑。
這個問題的規(guī)避辦法：
- 調(diào)試時，根據(jù)環(huán)境變量（下面的坑C會解釋環(huán)境變量的事情），如果是electron的打包，則將這個絕對路徑變成完整路徑，即根據(jù)本機(jī)的當(dāng)前路徑將這個icon-url改寫，并寫死。打包完成后直接調(diào)試沒有問題。而且開發(fā)者在這個階段，目前并不需要關(guān)心這個事情。
- 發(fā)布封裝的可執(zhí)行程序時，這就有點惡心了。因為不可寫死絕對路徑，每個人的電腦的路徑都是不一樣的。所以，需要手動改寫編譯好的index.css文件，進(jìn)去找到這個路徑并改掉它。目前我沒別的好辦法。
坑C 區(qū)分web模式和electron模式
這個非常有趣，因為我們的程序中還是有些細(xì)微的地方要對兩種模式加以區(qū)分的。比如說，遇到上面兩個問題，就要對兩種模式分別對待。
這就要求程序中要有些if-else來區(qū)分兩種模式（程序需要知道：我究竟是在調(diào)試web還是electron？我究竟是在打包web還是electron？），從而執(zhí)行不同的邏輯。
那如何區(qū)分？我目前的方式是使用環(huán)境變量。
即electron啟動時，和electron打包時，給某個環(huán)境變量賦值。這樣，在運行時，直接判斷該環(huán)境變量即可。
這里有幾點需要注意：
- 程序啟動和打包，是靠roadhog發(fā)起的，說白了本質(zhì)上還是通過nodejs程序來啟動的。
- C/S客戶端啟動時通過main.js加載的，這也是nodejs程序。
- 不管是WEB端還是C/S客戶端，都盡量不要依賴于它執(zhí)行時的環(huán)境的環(huán)境變量。也就是說，如果用戶使用前還得配環(huán)境變量，那豈不是非常惡心？請參見java早期的版本：需要初學(xué)者使用java開發(fā)前，要硬著頭皮配很多不知所以的環(huán)境變量。
- 而且WEB和C/S核心中的js是運行在瀏覽器中的，它如果能檢測到系統(tǒng)中的環(huán)境變量也是奇了。
因此，需要在nodejs中判斷環(huán)境變量。而且如果前端包中有依賴變量的地方，則必須在打包前，將變量的值定下來。
具體說一下我的做法：
- 在package.json中，配兩個script
"build_electron": "set ENABLE_ELECTRON=true && roadhog build"和"start_electron": "set DEBUG_ELECTRON=true &&electron ."，分別表示打包electron和調(diào)試electron。 - 實質(zhì)上分別是roadhog打包，和electron命令調(diào)試。
- 在這兩個命令前，分別設(shè)置了
ENABLE_ELECTRON、DEBUG_ELECTRON兩環(huán)境變量。 - 在roadhog的配置文件中，檢測
ENABLE_ELECTRON，如果存在，則define一個js對象。這是roadhog提供的語法糖，這個js對象可以在react的js中直接拿來用。這樣在react的js執(zhí)行中，就知道自己是被誰啟動或者是被誰打包的了。 - 有了這個define對象，就可以具體解決坑A的問題。即判斷這個對象的值，如果檢測到在electron模式下，就將RESTful API的url前面拼接上服務(wù)器地址。（這個對象在代碼中未定義，它是被roadhog強(qiáng)行寫進(jìn)來的嘛，因此eslint肯定報錯，想辦法規(guī)避吧）
- 而有了
DEBUG_ELECTRON就可以知道C/S是運行在調(diào)試模式還是發(fā)布模式了。因為畢竟調(diào)試和發(fā)布還是要有點區(qū)別。這個變量是在main.js里進(jìn)行判斷和使用的，不影響別處的邏輯。
Electron個人體會
后來才知道，這東西原來是當(dāng)前主流。
起因是我用電腦打開蝦米音樂想聽歌，發(fā)現(xiàn)蝦米報錯了。本來想直接關(guān)了，發(fā)現(xiàn)是個js錯誤，就仔細(xì)看了下，然后發(fā)現(xiàn)了不得了的事情：蝦米客戶端是用electron打包的。
然后我又看了網(wǎng)頁云音樂客戶端，居然也是。。。。
然后我又看了其他幾個軟件。。。。
行吧，反正是誤打誤撞積累了點“主流技術(shù)”開發(fā)經(jīng)驗。
