当cola.js失败时，您如何找出问题所在？

我没有一个可重现的最小示例，因为这可能要花几个小时进行调试，如果我有它，那么它就不是我要问的示例。我希望能听到一种迅速找出问题所在的方法。大概是我图中的一些不良数据。但是我怎么知道坏数据呢？

下面的屏幕快照说明了出现问题的典型情况。报告了各种NaN，有许多未捕获的TypeError，并且断言失败。有很多局部变量，所有局部变量都用一个字母命名。单击并查看它们表明NaN进入坐标，如先前的错误消息所建议。看起来好像早在某个时候，当它需要某种类似于列表的数据结构时，就会得到null。如何迅速找出图表中的不良数据？

我正在使用cola.v3.min.js。

详细信息

我正在寻找一种发现这种错误的通用方法，但是在此示例中，这是产生错误的特定数据。每一行都是传递给cy.add()的参数（正如Stepan T.建议的那样，打印传递给cy.add()的所有内容可能是答案的第一步！）。

{"group":"nodes","data":{"id":1,"label":"Workspace","parent":[]},"position":{"x":45,"y":0}}
{"group":"nodes","data":{"id":2,"label":"Target(121)","parent":[1]},"position":{"x":5,"data":{"id":3,"label":"WantFullySourced","position":{"x":50,"data":{"id":4,"label":"Brick(120)","position":{"x":10,"data":{"id":5,"label":"Avail","position":{"x":55,"data":{"id":6,"label":"Brick(1)","position":{"x":15,"data":{"id":7,"position":{"x":60,"data":{"id":8,"label":"Brick(2)","position":{"x":20,"data":{"id":9,"position":{"x":65,"data":{"id":10,"label":"Brick(3)","position":{"x":25,"data":{"id":11,"position":{"x":70,"data":{"id":12,"label":"Brick(4)","position":{"x":30,"data":{"id":13,"position":{"x":75,"data":{"id":14,"label":"Brick(5)","position":{"x":35,"data":{"id":15,"position":{"x":80,"data":{"id":16,"label":"NumericalRelationScout","position":{"x":40,"data":{"id":17,"label":"OperandView","position":{"x":0,"y":0}}
{"group":"edges","data":{"id":"2.member_of.1.members","source":2,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"4.member_of.1.members","source":4,"data":{"id":"6.member_of.1.members","source":6,"data":{"id":"8.member_of.1.members","source":8,"data":{"id":"10.member_of.1.members","source":10,"data":{"id":"12.member_of.1.members","source":12,"data":{"id":"14.member_of.1.members","source":14,"data":{"id":"16.member_of.1.members","source":16,"data":{"id":"17.member_of.1.members","source":17,"data":{"id":"3.taggees.2.tags","source":3,"source_port_label":"taggees","target":2,"target_port_label":"tags","data":{"id":"2.support_from.3.support_to","source_port_label":"support_from","target":3,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"3.support_from.2.support_to","data":{"id":"5.taggees.4.tags","source":5,"target":4,"data":{"id":"4.support_from.5.support_to","target":5,"data":{"id":"7.taggees.6.tags","source":7,"target":6,"data":{"id":"6.support_from.7.support_to","target":7,"data":{"id":"9.taggees.8.tags","source":9,"target":8,"data":{"id":"8.support_from.9.support_to","target":9,"data":{"id":"11.taggees.10.tags","source":11,"target":10,"data":{"id":"10.support_from.11.support_to","target":11,"data":{"id":"13.taggees.12.tags","source":13,"target":12,"data":{"id":"12.support_from.13.support_to","target":13,"data":{"id":"15.taggees.14.tags","source":15,"target":14,"data":{"id":"14.support_from.15.support_to","target":15,"weight":2}}

传递给cy.layout()的对象具有圆形结构，因此JSON.stringify()不会打印它。添加推荐的here getcircularReplacer()函数似乎会使浏览器崩溃。但是从布局对象中手动删除元素暴露了该错误：在相对的alignment约束（在API here中记录）中，我需要一个'0'的偏移量0，即需要数字的字符串。

好的，很高兴现在该问题已解决。这仍然留下了最初的问题：是否有更快的方法来查找类似的错误？ （现在，静态类型的提倡者肯定已经开始咯咯笑了。）