結合自己造的輪子實踐按需載入

為了**按需載入的本質，選擇了對先前造的輪子 diana 進行實驗。

實驗一：全量引用

import * as _ from 'diana'

測試的是

diana 0.4.1

import  from 'diana'

經過測試，發現兩種方式打包後的體積都為 21 k，第二種方式仍然將整個包引入專案中了。可是 lodash 就是這麼玩的呀，這和說好的不一樣呀，難道是忽視了什麼細節麼。

下文就來揭開面紗，並動手改造專案，最終目標是用第二種寫法實現按需載入，減小打包體積。

按需載入的效果是最終打包的**裡沒有未引入的模組，從而優化專案體積。下面給出 3 種可以按需載入的方案。

給每個函式單獨發布 npm 模組

按需載入的方案一是將每個函式都單獨發布乙個包，可以在 npm 上查閱 lodash，這種引用方式如下：

import  from 'lodash.isequal'

按需載入的方案二是將每乙個函式都作為乙個單一的模組匯出，參照這種思路將 diana 的每個函式暴露在 lib 目錄下，部分截圖如下：

這時候再來測試下打包體積：

import equal from 'diana/lib/equal'

可以看到打包體積減小約為原來的 1/7 了，但是這種方案在寫法上過於冗長，那要不借助下 babel ？

方案三是在方案二的基礎上借助 babel 外掛程式後，寫法可以如下:

import  from 'diana'

// .babelrc

] ]
}

實際上，babel 外掛程式 的作用是將import from 'diana'編譯成import equal from 'diana/lib/equal'。

關於 babel 外掛程式執行機制，可以在babel執行機制中**，這裡先不展開了。

談談自己造輪子

寫下這篇文章，主要是對我近段時間工作的反思。對於一些程式設計師來說，喜歡自己造輪子可算是乙個很平常的事情，我想可能有如下原因 我不覺得造輪子不好，曾今很長一段時間我都認為造輪子是體現自己能力很好的一種方式，但是現在越來越覺得，不要過分的去造輪子。昨天，我需要對接amazon s3的儲存，官方沒有go...

該不該造自己的輪子？

你在學習和寫 的過程中一定聽過這個說法 不要重複造輪子，使用現成的類庫就好。一般知名的類庫都是大公司開發並維護的，正確性與效能都 自己再重新開發乙個相同功能的類庫，消耗時間 消耗精力 大概率做的還不如別人做的好。我平時寫文章時，也經常會遇到好的專欄與書籍，感覺已經有這麼多 這麼好的資料，這些就是好的...

動手造輪子 實現乙個簡單的 EventBus

eventbus 是一種事件發布訂閱模式，通過 eventbus 我們可以很方便的實現解耦，將事件的發起和事件的處理的很好的分隔開來，很好的實現解耦。微軟官方的示例專案 eshoponcontainers 也有在使用 eventbus 這裡的 eventbus 實現也是參考借鑑了微軟 eshopon...