今天翻了翻一年多前寫的代碼，感覺年輕的自己寫的代碼真的是一個模式(不過現在好不了多少)。最近看了很多關于函數式編程和設計模式的書籍和文章，想分享一些讓JS代碼更優雅的小技巧。

1.善用函數式編程

2.lodash中一些有用的東西(LODASH是著名的JS工具庫，里面包含了很多函數方法和接口。在項目中引入邏輯可以簡化很多冗余的邏輯。)

babel介紹babel是一個js編譯器。我們通常使用react、vue等框架編譯成瀏覽器可以執行的代碼。個人感覺巴別塔是前端建筑中最低最核心的部分。沒有它，前端肯定會回到刀耕火種的時代。

既然是編譯器，當然會操作很多文件。在babel/core中，它讀取包括babelrc、pkgjson、插件、預置等在內的大部分文件。，所以緩存操作文件的結果是必不可少的！

巴別塔的緩存機制假設我們正在處理一個文件。對象和數組通常被用作js中的緩存容器。babel使用了es6提供的map，但它實際上是一個對象，只是它的鍵是任意的(不限于字符串)。

好了，現在我們有了一個緩存容器(map)，那么關鍵是什么呢？用來標記一個文件，一般可以選擇使用文件的路徑和文件名的md5值，babel使用的是前者。

處理文件的過程可以定義一個handle方法，文件路徑是handle的一個參數。有時候只有一個文件路徑不能滿足業務邏輯，還需要傳入其他參數，所以handle還有第二個參數。

這里babel封裝了第二個參數，使之成為具有狀態管理能力的對象，所以handle的第二個參數就是這個對象。

句柄處理后，你會得到這次一個文件的處理結果值。是否要現在保存地圖中的值？對不起，它不是的！

CacheConfigurator是一個具有狀態管理能力的對象，可以在句柄處理過程中進行修改。得到value的值后，需要識別CacheConfigurator的狀態。

CacheConfigurator有三種狀態:

紅色字體的有效項是check函數never，不需要緩存。

永遠，你需要緩存，但是下次處理這個文件的時候，跳過驗證部分，直接返回值。

有效，下次當處理這個文件時，你需要通過驗證邏輯有效。

那么這個檢查邏輯是怎么來的呢？

那個沒錯，它是在處理CacheConfigurator時由handle傳入的。

下次處理這個文件的時候，優先考慮緩存的邏輯，只有通過驗證后，才直接返回值！

整體思路是這樣的，蒙大拿的思路還是很微妙的。這個思路在其他業務中也可以參考！

喜歡我的回答就關注我。有問題可以評論。讓讓我們一起學習，一起成長！