Respo Rust 版本的反思

[tiye]

起因是尝试了一下 Any trait 觉得挺不错, 在想能不能用来处理 Respo 当中的 State Tree 场景. 因为之前用的是 serde 的 Value, 性能是不好的. 代码稍微试了试, 就发现了挺多的问题. 可以说大量依赖 Value 来模拟动态类型的功能.

Respo 的 ClojureScript 和 Calcit 版本使用了一些很动态的做法, 实际执行是基于 JavaScript 和一些不可变数据,

• 状态是树形结构存储的, 所有组件状态. 于是就需要 dispatch action 然后把数据写到树上. 动态类型很好做.
• 组件树在热替换的时候是保留的, 用于下一轮代码执行的状态.
• 组件的 memoization 用的是函数的 memoization 方案, 但针对前端框架场景简化了, 就两种,
  • 一种是组件只渲染一次, 那么只存一个记录就好了
  • 另一种组件生成多次, 但是在类似列表的场景, 每个 key 对应一个实例,
• 另外还有一个场景, effect 也是需要判断参数是否改变的. 虽然 Respo 用法不一样, 但场景也是这样, 可以认为跟组件类似, 也是缓存一次.

动态类型没有什么限制, 把参数直接存储下来, 判断是否改变, 以及把执行结果存下来, 用于缓存, 没有什么限制. 把整个树存下来也没有限制. 而这个在 Rust 当中就有限制了. 这里边涉及到了一个 Trait Object 的使用场景, 具体看 https://doc.rust-lang.org/book/ch17-02-trait-objects.html , 我掌握得比较少. 而且 Trait Object 也比我现在的方案也更好的扩展能力. 但这样一来, 需要定义的数据生命周期就比较复杂了, 没搞定, 头绪也还不清楚.

全局状态存储的问题, 我考虑可能需要把代码拆成多个 dylib, 然后状态保存在一个 dylib 中, 作为 states container, 然后渲染是一个 dylib. 当组件更新时其实只是其中一个 dylib 的替换, 状态在另一个组件当中, 依然保留. 不过这样 Respo 就是以多个 WASM component 的方式加载了, 这就复杂多了, 目前也没有掌握里边的技术方案.

memoization 看了一圈, 基于 https://github.com/dermesser/memoize 大致可能是满足的, 用法上还要再确认. 但也能意识到明显的区别, JavaScript 当中很容易绕过的障碍, 在 Rust 当中是存在严格限制的. 那么就需要 macro 才能假装绕过那些限制, 最终得到的写法确实也精简, 但内部实现的复杂度很高, 同样我现在的精力还不能啃下来.

目前比较难推进.

另外一个思路是尝试用 Moonbit 实现, 具体编译到 js 还是 wasm 对我差别不那么大, 我需求的功能主要是 trait / type class 路线的工具.现在一来是 Moonbit 生态还在建设中, 工具还有很大的工作量要填. 二来部分强类型的严格限制从 Rust 到 Moonbit 并不会消失, 上述不少问题仍需要体操技巧处理, 设置 Moonbit 不支持 Macro 也会限制一些思路.

再看吧, 也没精力, 诉求也不那么大.