Eggjs 從放棄到開始使用

原文：codesky.me/archives/eg…

用掘金刊登雖然分流了可是主要是！如今分享的曝光率實在過低了！！因此…………↑支持的請點下原博收藏下關注下以及個人微博。

咦，這篇文章標題爲何反了？

實際上這是我的走過的心路歷程，最初看到 eggjs 的時候，我就以爲 Egg 很明顯不符合個人審美——我選擇 koa 的理由就是小巧精緻，all in middleware. 而 eggjs 不是多此一舉嗎？

此次新項目用到了公司自改版 egg，不過其實也就是 egg 多封裝了幾個 service。

——一開始我是拒絕的。

egg 與 koa

egg 底層用了 koa，從開發體驗上來講，有種求同存異的感受，由於 koa 是本身一個個包找來的，因此我彷彿從 0 開始知道了爲何世界這麼轉，而封裝好的世界就沒有這種快感，同時，它擴展了一些概念：service / model / middleware / controller 都會進行自動註冊，在 koa 的世界裏，你可能須要本身寫一段代碼來實現自動註冊。

此外，在 koa 的基礎上，它免於了一些選擇困難症，也就是說，只要開啓它的插件，你就遵照 egg 的規定就能夠了。

固然，這種時候也帶來了另外一種糾結，這類企業開發的框架規定了一種開發的標準語法和規範，你無法按照本身喜歡的方式來，只能遵照它的規定，沒有 koa 那種愛怎麼寫怎麼寫的自由感——不過從另外一個角度來看，多是爲了長期維護的可行性作出的犧牲。

配置

和咱們平時用的配置庫差很少，都是根據 env 區分文件名，值得一提的是，單元測試時，環境變量爲變動爲 unittest，因此能夠定製測試環境時的配置。若是沒有找到的配置會降級到 config.default.js 中取尋找。

測試

若是我這篇文章只是簡單的把官方文檔壓縮壓縮再灌輸給你們，你們確定也讀的不(hen)開心。主要想說的仍是 egg 給咱們在測試環節帶來的便利。

測試時每每我會思考如下問題：測些什麼，mock 些什麼，選擇啥庫，這三個問題每每會阻礙我行進的步伐，尤爲是 mock 步驟太多的時候——SSO 要不要 mock，某些服務要不要 mock。調用了其餘外部服務要不要 mock。這樣一來一去可能就更不想測試了。

在 egg 中封裝好的 Service 或者是 context 的屬性是能夠直接 mock 配置的，使得整個過程很是的流暢，流暢的另外一個緣由固然是不用想如同「今天吃什麼」同樣的問題——「今天挑什麼庫用」。

文檔

剩下的就是 koa 和 egg 的文檔了，koa 概念不多，基本是用到什麼查什麼就好了，而 egg 相比之下引入的新概念和內置的 API 就比較多了，按照咱們的尿性，字太長不看，頗有可能會錯過什麼，這裏已經把某些我曾經錯過的部分抽出來介紹了（逃）。

在 egg API 文檔的閱讀時，請記住，若是寫着 the same as 或者 alias，請到指定位置查看接口信息；點擊源代碼也可能有意外之喜。

總之

若是你期待被規範，egg 仍是一個值得選擇的框架，於此同時，也能夠定製本身的 egg 版本，封裝一些經常使用 Service 給本身用，不過另外一方面，因爲封裝的太齊全，我也遇到了：egg 是照着這個來的 -> 點擊進入這個東西的文檔 -> 這一部分請看這個文檔 -> 又進入了另外一個文檔的深層窘境，這種深化帶來的問題是，出了 Bug，若是定位到不是你——接下來甩鍋給誰好呢？

總的來講，雖然有些蛋疼，還不算太慘不忍睹，某些場景下仍是比較棒的。