Closed yuqianma closed 5 years ago
最终是使用一套机制，还是结合各自优点混合？（暂时考虑混合）
props: VNode写组件，我们比较熟悉，开发体验也比较爽。组件本身的动效、交互逻辑，可以包裹在组件内。上层调用时只需要某种接口（props, handlers）。 cons: 如果：逻辑不内聚；对象数量非常大；对象数量大且要小部分更新，那么VNode的优势就成了麻烦。
props Marks本身是纯view，没有逻辑。配合上层机制可以精确控制。 cons 交互逻辑无法包裹成组件 group含marks、signals也算组件了？
使用Marks & Signals去组织交互，如果没有subflow，需要把状态暴露在全局。结果是添加一个组件，需要修改全局signals。（好像这个结果也挺应该的，实际上就是需要修改）
Marks Operator：changeset可以精确控制更新，精确到一组marks中的某一个。 VNode: 需要一路diff，最小更新单元是Component。
如果用group & marks机制重新审视一下这个复杂的axis，有没有什么新想法？
viewstate，既可以是抽象的上层state （读取一个list渲染成一组icons）；也可以是具体的element描述（state中直接是icons大小，位置等）。 如果是内聚的Component，显然保存抽象的state，用jsx写，体验还不错。 如果需要描述大量element属性，考虑VNode diff机制，反而造成复杂性。那不如不要用VNode。
所以，viewstate中不保存marks？直接通过Marks Op -> Render Op，Render中拿到的changeset就是add/mod/rem的element
其他问题： group - children树的结构怎么用Render Op？
问题
最终是使用一套机制，还是结合各自优点混合？（暂时考虑混合）
对比
VNode
props: VNode写组件，我们比较熟悉，开发体验也比较爽。组件本身的动效、交互逻辑，可以包裹在组件内。上层调用时只需要某种接口（props, handlers）。 cons: 如果：逻辑不内聚；对象数量非常大；对象数量大且要小部分更新，那么VNode的优势就成了麻烦。
Marks Operator
props Marks本身是纯view，没有逻辑。配合上层机制可以精确控制。 cons
交互逻辑无法包裹成组件group含marks、signals也算组件了？使用Marks & Signals去组织交互，如果没有subflow，需要把状态暴露在全局。结果是添加一个组件，需要修改全局signals。（好像这个结果也挺应该的，实际上就是需要修改）
更新的区别
Marks Operator：changeset可以精确控制更新，精确到一组marks中的某一个。 VNode: 需要一路diff，最小更新单元是Component。
混合方式（draft）
viewstate，既可以是抽象的上层state （读取一个list渲染成一组icons）；也可以是具体的element描述（state中直接是icons大小，位置等）。 如果是内聚的Component，显然保存抽象的state，用jsx写，体验还不错。 如果需要描述大量element属性，考虑VNode diff机制，反而造成复杂性。那不如不要用VNode。
所以，viewstate中不保存marks？直接通过Marks Op -> Render Op，Render中拿到的changeset就是add/mod/rem的element
其他问题： group - children树的结构怎么用Render Op？