共计 1076 个字符，预计需要花费 3 分钟才能阅读完成。
对于 g6 绘图来说，最大的感触就是说，首先肯定要熟读文档，g6 上上手做之前，看他的例子，尽管看着简略，然而要定制做，合乎设计的话是比拟难的。
浏览文仔细阅读文档后，你会晓得有很多的货色，它有哪些货色能够用，就比方这个自定义的事件来说，（例如：hover 成果）一开始我是用了传统的绑定事件来解决他，然而在读文档的时候才发现用这个是更简略的。
开发简单组图，有些坑可能是不得不踩的，像这个布局，一开始我仅仅认为是把数图做一个扭转，就能够了。然而一遇到了问题就是说扭转当前，数据简略看着不会出错，数据一多他就有问题。g6 更新的底层算法就是说会复制一棵树，用旧树地位跟新树做比照，这个时候地位一重叠，造成抵触导致布局抵触开发失败，花了大笔的工夫去推敲它，越过他，例如在布局更新阶段，先扭转回来，在扭转回去。然而最初还是走不通。还想过把树图放在组外面进行开发，完了再用组做一个矩形变换来达到目标，文档感觉可行，然而没有实例，也找不到相干材料，试验了一天还是没有后果。完后就是想扒他的源码，最初没方法应用自定义布局，本人做数位算法，感觉有时候简单的形式感觉反而感觉更简略
在开发数位算法的时候，我的教训是简单的事件肯定要先把它简化，不能间接拿着后盾返回的数据进行试验，本人写一些简略的数据结构来做试验。这样影响的参数会变少，让开发更简略一些。同时对于简单的事件肯定要提前做好构造的布局，做不好到前期会越简单。这种树图算法出错，找到问题节点完了当前判断问题，发现哪里写错了，找到算法外面的有余是看起来就写了一点，然而调试起来会比拟吃力，所以一开始肯定要用本人污浊的数据来做试验，确保这个算法不会出问题在上真数据。就像在开发过程中，有时候会援用后端返回给我的数据来进行试验，这个时候就没方法保障这个数据是我想要的，就比方这个节点数据，我一开始是以 PID 是惟一的，完了当前我就用它来做这个节点的 ID，出错当前找了半天才发现是因为 PID 反复导致的，完了当前又加了很多的限定，来保障这个节点是惟一的，并且在前期是能够找到的。
同时也发现 g6 有一些不欠缺的中央，在我的开发中就发现了两个比拟显著的问题。
api 生效
插件逻辑不周全
援用工夫插件后, 自定义布局拿不到值
其余:
如果两次节点绘制是同步的, 那么很大可能导致位点错乱
graph.render()
graph.changeData({nodes: newNodes, edges: newEdges});
单个节点携带数据过大会导致出错
节点 id 反复会呈现绘制谬误,
视图存在缓存, 如果 id 雷同, 很可能不能齐全更新
大数据调试, 须要一些灵便的形式