距離上一次寫電子報又有一段時間了，最近調整了一下寫作的方法，內容也傾向技術一點，這是不是又是一種抉擇呢。

有趣的是

Eagle 升級打造社群

作為長期的 Eagle 粉絲，看到 Eagle 從經營一點點的官網 blog 一舉跨到資源收集大平台，打破大家各自的資源圍牆，有趣的是，過去開發者多次說明為什麼選擇不開發同步功能（在雲端的投入成本極高），最終選擇與其將雲端資源配置在自有資源的同步，將雲端資源挹注在共有資源的同步，是一個非常聰明的決定，將成本花在刀口上，下一步這些資源可以想見，也許能逐步發展新商業模式，讓大家可以開放販售自己的設計圖庫、工具 ... etc，非常期待資源社群的下一步發展。

8n8 - 類似 zapier, IFFF 的開源 api 大平台服務

平時不乏使用各種軟體工具，但當不同工具需要串接的時候就很仰賴 zapier, IFFF 這類型的串接服務，不過隨著依賴這種中介服務越多，就越害怕類似 google 養套殺的作法，如果不想要依賴這些官方服務，可以嘗試使用開源的 8n8，自行架設自己的串接服務。8n8 也同樣的有提供官方的 cloud 可以註冊使用。

讀了一些

Faster JavaScript Builds with Metro

這篇文章的價值在提供了非常簡要清楚對 Metro 的介紹，且提供了其實 bundler server 也是可以自己打造的想像。

Airbnb Web 由於每一次存檔更新時間太長，從 webpack 改用 Metro，Metro 核心分為三塊：

• Resolution: 處理檔案的 import, export
• Transformation：轉換 typescript / ES* 到同義可執行的 JavaScript
• Serialization: 將所有 JavaScript 整合成一個 bundle

原先 webpack 每一次存檔並進行 serialization 時，都會需要爬過所有的檔案，但 metro 可以針對有更動的檔案去處理。

另外 Matro 有新的 multi-layered cache 雷同於 webpack 的 disk persistent cache，但提供更多彈性的設置，除了 memory, disk cache 外也能設定 remote resource cache。

轉移至 Metro 的挑戰在於，原先 Metro 的設置並不是為 Web 所開發，所以需要額外開發一些新功能並自架 bundle server 外，還需要自行根據 Metro 的架構去處理 code splitting 跟 tree shaking 的議題。

React state management libraries in 2022

這篇文章的價值在提供了掌握狀態管理工具的架構，並且提供了常見的狀態管理工具比較。

狀態管理大致可以分成下列三個區塊：

1. Structure：從 global, multiple store 或從 store 中取出來物件的其中一個 property e.g. user.name 存值。
2. Read from Store：透過 selector 或 getter function 來取值，避免重複運算。
3. Update Store
   1. 建立類似 setState 的 Reactish API
   2. 接著透過 dispatch action object 來呼叫，有一些更簡化的狀態管理工具會省略這個步驟，可以直接使用封裝後的 action function。

在思考狀態管理工具時可以參考下列架構：

• Usage: 最小可行的 api，也可以補充 Terminology e.g. redux 的 selector 在 vue 裡面是 getter
• The Problem; pros/cons: 目前這個工具的問題與優點
• The Solution: 使用這個工具面對上述問題的解法
• When to use; thinking; middleware: 什麼時機比較適合用，相關的 middleware

Reflection on two years of writing evergreen notes: Not optimal for skill acquisition and learning

這篇文章提供了 Evergreen Note/ Zhettlekasten 不適用的案例，跟可能會需要什麼。

這篇文章是在說 evergreen note 或 zhettlekasten 其實並不適合探索前沿知識外的做法，因為當要精熟一個領域可能更重要的是記憶。

而知識點很難被轉為 concept oriented 的單位，更多的是是什麼 (statement) 與如何做 (inperative) 缺乏原本有的 concept 跟無幾的 outline 筆記，

其中 statement 跟 imperative 當被引入進 context 時，很難被實際上的關聯再一起，因為這是名詞與名詞的關係而不是實質的概念關係， e.g. JavaScript this, hoisting, closure 可能有關，但實際上概念的關係卻是隱性的，另外大量的 evergreen note 連結其實也不容易回想，很難實際的回憶起來。

比較理想的 mental navigation 比起線性敘述中的連結，作者提到應該提取出其中的隱性關係且不超過七個節點，提取隱性關係的框架又可以有好幾種，應該要嘗試透過不同的提取框架來建構，而非全部一視同仁的使用相同的連結關係。