背景

G6 3.0 ～ G6 4.x 经过近 3 年、186 个版本的迭代，当年的架构和细节设计逐渐浮现出了一些问题，不少用户反馈生命周期、API 合理性、数据结构合理性等问题。CY22 S2，我们将正式进入 G6 5.0 的设计阶段。

目标

期望在 CY23 推出 G6 5.0，具备更合理的架构，开发体验、使用体验更佳。更重要的是，希望 G6 5.0 较之于当前版本，有更强的代差感。-> 下面的问题治理仍然没有感觉到明显「代差」，需要更多 feature？

目前问题

1. 架构问题

  • 无 spec：本该正交的能力和语法糖 区分不开 #逍为
    • 配置项的一种规范，开发方式
    • 同样的功能多种实现方式，

  • 不必要的 export：这大概是当前 AntV 的通病。大概是因为扩展得机制不佳，所以需要 export 出去很多的变量和方法。 #逍为

    2. 生命周期

    常常出现异步更新，经常需要通过 setTimeout 来解决（类似 React）

  • 目前很多异步函数，生命周期是通过时机事件抛出的，需要通过 graph.on 进行监听

    • 文档中写明是否是异步函数
    • 增加 callback 的形式、promise 方式 => 5.0 layout promise
    • 渲染，动画

      3. API 合理性

  • 克制？

  • 缺失？

数据相关：用户分不清何时使用 data、changeData、updateItem、render。前两者可以合并。性能哪个好？各适合什么场景？数据存在很多份，原始数据、中间态数据。G6 修改的数据键放在指定 object

4. 功能机制

4.1 元素自定义机制

  • 使用的是 mixin 的方式，单个函数内部无法 super 后扩展
  • 继承含义不明确，用户常常不知道哪些函数被继承，会发生什么事情
  • 接触 G 的绘图 API，各种图形的概念
  • 超复杂节点 JSX，分层级（缩放等级）渲染的转换（包括布局、节点内部布局、全局重绘）

image.png

4.2. Behavior

  • 当前的每种 behavior 配置到 graph 上是单实例的，如“快捷键”等 behavior，需要多例
  • 如何规范化多个 behavior 之间产生冲突，更好地处理彼此间关系
    • 默认配置不冲突
    • 检测？
    • 需要让用户能感知到是自己配置导致的冲突

      4.3. 插件 —— 组件包？g-component

      当前 G6 对插件的定义是组合 UI 的组件，可插拔地配置到图示例上。但“插件”的意义应远不止于此，插件应该更开放，插槽需要更自由
      // plugin 实际是一段嵌入到主生命周期的代码片段，实际它能做任何事情，而不仅仅是 UI 或者交互
      区分插件和业务代码的事情
  • 机制目前没有开放，在生命周期的确定地方才可以插入，需要规范
  • 定义哪些功能可以被扩展
  • 核心模块插件化？灵活性与易读的平衡
  • 生命周期需要一致
  • 插件系统
  • 联合 g2 组件机制：

image.png

4.4. 撤销重做

  • 目前撤销重做栈存储的是变化前后的数据，是否应该改为命令的存储。X6 是怎么做的？
    • 命令存储可能存在问题
  • 目前无法处理多个原子操作的合并撤销/重做，例如将一个节点拖拽到 combo 内部，这里有的原子操作有：改变节点位置、改变节点与 combo 的从属关系、更新 combo 的位置和大小。预期撤销时，这几个原子操作应当一并撤销

  • 上下文问题？

    4.5 元素的状态管理

  • 目前状态管理有大量、频繁的 clone mix，将样式进行拷贝存储，有一定性能问题，也不太优雅。

    4.6 动画规范

  • 多动画的先后顺序、执行时间等，需要规范化

    5. 数据

    5.1. 数据隔离

    目前通过 graph.data 输入的原数据，在渲染、布局之后，都会被修改，写入样式、位置信息等。@antv/layout 包也存在同样的问题

  • 数据隔离是否必要？

  • 需要更合理的数据流管理机制

    5.2. 数据结构统一

    与算法包 @antv/algorithm、布局包 @antv/layout 通用。方便形成规范和扩展

    6. 布局

    6.1. 参数问题

    各个布局算法参数多，不好理解，用户需要凭借经验调参，很困难。希望能够参数自动化

  • 渲染后的大小，需要影响布局

  • 树图布局：混合多种，pipe 需要支持，#lizong

    6.2. 多布局

    多布局结合时（pipe），布局叠加处理、自动调整子布局位置

    6.3 增量数据布局保持一致性

    7. 工程合理性

  • graph 核心类超长代码

  • pnpm
  • TypeScript 规范化
  • 是否还有必要拆包？
    • 现在太细了，对于 G6 新开发者来说，难以找到代码，类型的问题
    • 过细的 repo 拆分带来： #逍为
      1. 代码归属，带来：代码 copy、更多的 repo、代码混乱
      2. 代码不可读
      3. 维护带来更多灵活性、可能性
    • 虽然移动端交给 F6，但不意味着 G6 完全散失移动端扩展的可能性。可能由社区来做。可能将来有更多的可扩展性。

X6 抄作业指南

  • 折线自动寻径算法，交叉、重叠

新需求

1. Debug 能力

例如性能问题，如何快速定位是自己带吗的问题还是 G6 的问题
抛出详细错误
redux dev tool: 看到所有事件的绑定、数据

2. 树图和图的转换？

3. 同画布多图实例

实例间的通信、管理问题。

  1. WebGL
  2. 包体积大小
  3. 风格化渲染
  4. L7 迁移完成后的打通，地图+图场景

  5. 自定义节点时就定义不同缩放等级下的渲染，大数据量自动省略等

    G6 4.0 可保留的优点

    1. 解耦合

    • element、item、graph 由下至上隔离，即 element 渲染层感知不到 item，item 层感知不到 graph。由上至下管理
    • behavior、分析算法、布局算法等与 graph 隔离，graph 与它们相互不感知。通过 graph 的各个 controller 进行管理
      • 例：布局算法中没有 graph 实例，只有数据。graph 实例中没有布局实例。layoutController 中有 graph 实例、布局实例，相关生命周期由 layoutController 管理。

架构

image.png

方案（TODO）

1. Spec

围绕 spec 进行架构设计，最好可以和 G2 的 spec 形成整体 AntV 的 spec。
#逍为

2. 函数式

不用 class 去存储一些状态啥的，就纯 spec 驱动 ui，函数式代码，降低复杂度，代码组织容易，且打包小。
#逍为

3. 图形语法

？理论上说，G6 应该也能基于图形语法，加布局，或者是否还有其他的理论/语法。
#逍为

4. 生命周期规范与管理

  • 清晰定义图的生命周期：创建（实例化） -> 读取数据 -> 渲染 -> 布局 -> 更新位置 -> 更新交互状态 -> 更换数据 -> 渲染 -> … -> 销毁
  • 对于生命周期中的每一步，需要有对应的时机

    5. 数据规范

    设计规范的图数据结构，数据结构下沉，作为 G6、layout、algorithm 的基座。
    #多牧

    6. 动画规范

    7. 状态规范

    8. 自定义规范

    9. 其他具体见「目前问题」中每项解法

    里程碑

    | 2022.6.1 | G6 4.x 问题梳理 | | —- | —- | | 2022.10.1 | G6 5.0 架构设计完成 | | 2023. 4.30 | beta | | 2023.6.6 | 正式版本 |