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 弄好.