问题描述
我在服务器端使用 datomic，在客户端使用多个试剂原子，现在正在考虑在客户端上尝试数据脚本。
目前，我通过初始 api 加载传递嵌套结构，其中包含数据拉取查询的结果。它非常简洁，而且运行良好。
然而，现在正在探索数据脚本的潜在好处。卖点是它似乎允许将规范化保留到属性级别。但是，我遇到了最初的障碍。 Datascript 不是，正如我想象的那样（也许，希望......），一种只是对你的数据数据库进行子集化并在客户端上复制它的方法。问题是，datomic 的实体 ID 不能共享到数据脚本，特别是 - 当您将 transact! 实体放入数据脚本时，会为每个实体发出一个新的 eid（数据脚本）。
我还没有解决所有的后果，但似乎有必要在 datascript 中存储 :datomic-id，除了 datascript 自己新发布的 :db/id，而且 ref 类型将使用数据脚本的 id，而不是数据组。这可能会使同步回 datomic 变得复杂，感觉它可能会产生很多潜在的问题，并且不像我希望的那样同构。但仍在努力。有人可以在这里分享经验吗？也许有一个解决方案...
更新：
想知道是否有解决方案是禁止在客户端上使用 datomic 的 :db/id，通过从初始加载中过滤它们来强制执行此操作；根本不将它们传递给客户。然后，任何客户端 -> 服务器通信都必须使用（服务器生成的）slug，它们在初始加载中传递。
因此，所有实体在客户端上都会有不同的 id，但我们禁止将服务器 id 传递给客户端，因此如果客户端 id 意外传递给服务器，则可能会说找不到 eid。这可能有更多问题，尚未解决。
在传递到 & 插入到客户端时，您还必须考虑实体，而不是数据，以便在那里创建正确的引用（或者可能可以插入一棵树，如果有争议）。
所以我发现 datomic/datascript 伙伴关系当然不仅仅是“序列化您的数据库的一部分”的情况 - 如果在服务器上使用 datascript 可能会起作用，这根本不是这里的用例（需要数据库持久性）。
解决方法
如果我没记错的话，Datomic 使用所有 64 位作为实体 ID，但在 JavaScript（以及 DataScript 中的扩展）中，最多只有 53 位整数。所以无论如何都需要某种翻译层，无法绕过它。
附言你可以在 DataScript 中完全指定 :db/id 为你想要的任何东西，它会使用它而不是生成它自己的。只要确保适合 53 位即可。