js->clj 在具有键 "v" 的对象上中断

Question

在启用高级编译的情况下，具有键 "v" 的 JS 对象会使 (seq? x) 子句的 js->clj 返回 true，但由于 js/Object 不满足 ISeqable，下一行的 map 引发了错误。我在 circleci 前端代码库中发现了这个问题。目前正在创建一个最小化项目测试用例。

Answer 1

评论由：iandavis 发布

无法生成最小化案例。它肯定在我们仓库中失败，但无法使它在一个更简单的案例中失败。保留此问题以供其他人参考，但如果没有人报告，则不期望有任何后续跟进。

Answer 2

评论由：thheller_ 发布

《{{(seq? x)}}》进行协议检查，该检查检查给定对象是否具有协议的标记属性。在这种情况下，该属性最有可能被重命名为{{x.v}}，然后引起冲突。

这已在很久以前为常规协议修正：https://dev.clojure.org/jira/browse/CLJS-1658

但快速路径协议（即 ISeq）使用位检查{{(x.cljs$lang$protocol_mask$partition0$ & (64))}}，我假设您在{{v}}中的值满足此检查？

Answer 3

评论由：dnolen 发布

我认为托马斯的分析在这里是正确的。我认为在 js->clj 中使用 seq? 和 coll? 检查可能考虑不周，但改变这可能会为不同的用户群引入不同类型的故障。您可以提供包含您的 JS 对象及其属性的 externs 文件（如果动态，则难度较大），或者编写一个更简单的自定义 js->clj，它仅期望 JS 值（无需协议检查），并使用它代替。

Answer 4

评论由：iandavis 发布

好吧，我觉得可能就是这样。我曾考虑过删除前三种情况，或者只是交换 js 和协议检查的顺序，但我没有完全确定这可能会引入什么类型的故障。如果我们仅仅在我们的 json 解析器中使用修改后的版本，应该没问题，对吧？似乎那些协议检查只在你有 clojure 与 json 混合时才有用。

Answer 5

参考：[https://clojure.atlassian.net/browse/CLJS-2050](https://clojure.atlassian.net/browse/CLJS-2050)（由 alex+import 报告）