Cumulo Workflow 項目進展

這幾天在微博刷了 Woodenlist 的內容, 算是進展仍是滿意的.
Woodenlist 基於我以前的 Wanderlist 作的一個小項目, 惋惜如今還沒用起來.
要作到能用, 後面須要增長不少細節, 不展開了. 這裏只關心技術部分.

Recollect

Woodenlist 基於 Cumulo 方案和 ClojureScript 代碼, 開發使用 Stack Editor.
要更好地理解 Cumulo, 如今已經不用費口齒解釋了, 直接看 Console 中的 log.
或者 WebSocket 裏的數據更清晰一些, 能夠看到分紅兩種:

• 深色的, 客戶端發往服務器的數據, EDN 格式

• 淺色的, 客戶端接受的數據, 其實是 Diff 結果, EDN 格式

而 Diff 內容就構成了數據同步最主要的部分, 也就是本地的 Store 的數據來源.
也就是說 Cumulo 方案目前是有缺陷的, Store 是由服務端控制的,
前端僅有組件的局部狀態, 而局部狀態的功能有限.

其中提到的名詞不熟悉的話, 還有一些介紹, 好比 EDN 能夠看文檔.
而 Recollect 是我本身實現的一個 EDN 子集的 Diff/Patch 類庫.
經過 Recollect 最終實現了服務端 Diff, 客戶端 Patch 這個極端的方案.

Workflow

另外一個重要的部分是我將項目模板抽離出來放在倉庫維護, 也就是:
https://github.com/Cumulo/cum...
好像比較早就有了, 如今主要是基於新的 Respo 和 Recollect 作了升級,
也就是說後端用 Recollect 從 DB 同步到 Store, 前端用 Respo 從 Store 同步到界面.
而 Workflow 當中就是一個可運行的 demo, 同時也做爲代碼模板.

此前服務端代碼採用模塊化的方案發布了獨立的模塊, 兩個包,
後面考慮到項目仍是須要快速迭代, 仍是採用拷貝複用代碼的方式了.
隨之而來的問題升級的成本, 使用了模板的項目須要手動拷貝升級, 其實很麻煩.
但目前來講仍是直接使用的話, 反作用的代碼太多了, 抽象起來麻煩.

另外一個不小的轉變是後端是 Figwheel 切換到了 Lumo 做爲開發環境,
Lumo 的好處就是簡單, 不用像 Figwheel 那樣維護複雜的配置,
不過缺點也有, 相關的教授叫須要本身積攢, 甚至熱替換須要本身制定方案,
個人文檔裏如今對 Lumo 尚未作妥善的說明, 因此仍是挺麻煩的.
其中一些內容我在論壇上開帖子寫了, 應該是有點用的, 但也還不是文檔:
http://clojure-china.org/t/lu...

整體上說, 對於 Woodenlist 這樣一個最簡單的 Todolist 實時應用, Cumulo 足夠了.
並且開發能夠作到先後端實時熱替換, 這個玩法不少技術棧應該是玩不起來的.
同時我已經作到了直接用 Stack Editor 編輯遠程的應用, 支持多人同時開發.
至於數據量 scale 以後的性能問題, 網絡延時對體驗的影響, 短時間依然不考慮.
有興趣能夠去刷刷源碼 https://github.com/Cumulo/woo...

小結

進展良好, 籌碼繼續增長, 風險還好, 精力有點很差調整形成了一些麻煩.但如今我能作的恐怕也只有把事情作出來, 證實本身的方向是可靠的.想辦法集中精力, 儘快把 Woodenlist 弄好.