為什么從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打包的。
然后我又看了網頁云音樂客戶端，居然也是。。。。
然后我又看了其他幾個軟件。。。。
行吧，反正是誤打誤撞積累了點“主流技術”開發經驗。
