Clerk项目中Cherry Notebook的eval-cljs功能修复解析

在Clerk项目的开发过程中，最近发现了一个关于Cherry Notebook中eval-cljs功能的有趣问题。这个问题涉及到ClojureScript代码的评估方式以及元数据的处理机制，值得深入探讨。

问题背景

在Clerk的Cherry Notebook中，开发者原本使用eval-cljs来评估ClojureScript表达式。但在某次提交中，这些调用被改为使用eval-cljs-str。根据注释说明，这种改变是因为序列化到客户端的s表达式当时无法保留元数据，而异步函数需要^:async元数据标记。

然而，实际上在之前的版本中，eval-cljs确实能够正常工作。这表明底层实现可能已经发生了变化，使得原先的限制不再适用。

技术分析

经过调查发现，这个问题与以下几个技术点相关：

1. 元数据处理：Cherry的defn宏现在支持通过普通表达式添加元数据，而不再依赖传统的元数据语法。这意味着不再需要特殊处理元数据的序列化问题。

2. 评估机制：在某些情况下，表达式可能会被SCI（Small Clojure Interpreter）而非Cherry评估，这可能导致不一致的行为。不过这种问题可能是由于缓存导致的临时现象。

3. 字符串评估与表达式评估：eval-cljs-str和eval-cljs代表了两种不同的评估方式。前者直接评估字符串形式的代码，后者评估数据结构形式的代码。在元数据处理方面，它们有着不同的特性。

解决方案

经过测试验证，确认将代码恢复为使用eval-cljs后，静态Notebook能够正常工作。即使在清除Clerk缓存后，这种解决方案仍然有效。这表明：

1. 原先关于元数据序列化的限制已经不再适用
2. Cherry现在能够正确处理函数定义中的元数据
3. 不需要再为异步函数特别处理^:async标记

技术启示

这个问题的解决过程给我们带来了一些有价值的启示：

1. 框架演进：随着底层框架的改进，原先的一些限制可能会自然消失。开发者需要定期重新评估这些限制是否仍然存在。

2. 缓存影响：在开发过程中，缓存机制有时会掩盖真正的问题本质，导致难以复现的"海森堡bug"。清除缓存是调试的一个重要步骤。

3. 评估策略选择：在不同的场景下，选择字符串评估还是数据结构评估需要根据实际需求和框架特性来决定。

这个问题的解决不仅恢复了功能，也帮助我们更好地理解了Clerk项目中代码评估机制的工作原理和演进方向。