Malli项目中的`unparse`行为解析与改进

Malli是一个强大的Clojure/Script数据验证和转换库，它提供了parse和unparse这对互补函数来处理数据的转换。然而，最近发现了一个关于unparse函数行为的有趣问题，值得深入探讨。

问题背景

在Malli中，parse函数将原始数据转换为带有类型标签的内部表示形式，而unparse函数则执行相反的操作，将内部表示转换回原始数据。例如，对于[:orn [:int :int] [:str :string]]这样的联合类型schema：

(def int-or-string [:orn [:int :int] [:str :string]])

(parse int-or-string 1)  ; 返回[:int 1]
(unparse int-or-string [:int 1])  ; 预期返回1

然而，直接使用看起来与parse结果相同的手工构造向量[:int 1]调用unparse时，却会返回:malli.core/invalid，这显然不符合直觉。

技术细节分析

深入Malli的实现可以发现，parse函数实际上返回的是一个MapEntry对象，而不是简单的向量。Clojure的=函数在比较MapEntry和两元素向量时会返回true，这导致了表面上的等价性，但在unparse内部检查时却无法识别。

Malli内部使用了一个-tagged辅助函数来创建这些带标签的值，它本质上创建了一个特殊的MapEntry。unparse函数在接收输入时，会检查值是否是通过这种方式"标记"过的。

解决方案演进

最初提出的解决方案是修改tagged?谓词函数，使其不仅接受MapEntry，也接受两元素向量作为有效输入。这种方法简单直接，但可能带来一些潜在问题：

1. 可能误判某些本应是普通向量的数据
2. 破坏现有的依赖于严格类型检查的代码

更稳健的解决方案是引入一个专用的记录类型来表示解析结果，而不是依赖MapEntry。这种方法：

• 提供了明确的类型区分
• 保持了向后兼容性
• 使API行为更加清晰和可预测

对用户的影响

这一改进使得Malli的API更加一致和用户友好。现在，用户可以采用以下任一方式使用unparse：

; 原始方式
(unparse schema (parse schema data))

; 使用MapEntry
(unparse schema (MapEntry. :tag value))

; 使用向量 (在新版本中支持)
(unparse schema [:tag value])

这种灵活性大大降低了使用门槛，特别是当用户需要手动构造解析结果时。

最佳实践建议

虽然Malli现在支持更宽松的输入格式，但建议用户：

1. 尽可能使用parse/unparse函数对来处理数据转换
2. 当需要手动构造解析结果时，优先使用官方提供的构造函数
3. 避免依赖具体的实现细节(如使用MapEntry直接构造)

这一改进体现了Malli项目对用户体验的持续关注，同时也保持了库的稳定性和可靠性。