Declarative Dragging：让拖拽交互更简单
拖拽交互本该让数字世界触手可及，但繁琐的几何计算和动画代码却劝退了许多开发者。Declarative Dragging 颠覆了这一传统模式：你只需声明拖拽后的目标状态，系统便会自动推演并渲染出流畅的交互体验。这项由 Andrew Blinn 和 Joshua Horowitz 提出的模型驱动技术，通过 Dragology 库实现，让教育者、游戏设计师和工具构建者能专注于业务逻辑，而非底层实现。从数学可视化的 Twisted Trees 到编程环境 Hazel 的重构，Declarative Dragging 正将抽象规则转化为直观的触觉体验，让复杂系统的并行表示在拖拽中实时联动。
Declarative Dragging 将问题反转：你不再直接编程所有视觉行为，只需为每个可拖拽元素声明拖拽后应达成的应用未来状态。
HN 评论区
93- gavinray
关于拖放（drag-and-drop）的一个有趣故事：
在我第一份工作中，我们每周开会分配任务并估算工时。
我们的非技术产品经理在白板上写了“拖放”，然后写下了我的名字。
“Gavin，你觉得这需要多久？”
“至少一周。也许还要更久？”
PM 笑了，随后意识到我并不是在开玩笑。
“你什么意思‘一周’？这太荒谬了，难道我得找别人来做？”
“嗯，你可以找人，但别指望能更快搞定。”
他震惊地喊道：“这不过是拖放而已！”
在房间里的一群工程师花了 10 到 15 分钟试图解释其中的难度后，他只好不高兴地放弃了：“行吧。”
从此，“这不过是拖放而已”成了我在那儿工作期间的内部笑话……
- btown
哦，这非常、非常酷，而且非常、非常及时！
论文在这里：https://declarative-dragging.github.io/D2.pdf
在我看来，代理式编程（agentic coding）剩下的一个缺口是：即使是多模态 LLM 也很难检查交互运动效果的正确性和“手感”。当然，它们可以截取几个静态状态的截图，但在底层节点移动和（可能）重新布局时，事物的反应如何呢？你如何测试在嵌套区域中快速挥动手腕的“手感”？
答案是避免这种需求：你拥有一个（近乎可证明）正确的基础，确保无论状态如何，行为都是可预测的，只需相应渲染即可。
该论文的方法在这里令人惊叹：同时乐观渲染多种可能的状态，以及一种可组合的代数（一种小型组合器语言），用于推导放置区域和距离——在实践中允许极其高级的接口。一切感觉都很流畅且正确，你编写的代码也尽可能精简——尽管论文指出状态管理有些复杂。但这似乎是可解决的！
一旦移植到 HTML，它将成为现代开发工具包中极其重要的一部分。我对这意味着什么感到非常兴奋。
- codedokode
很有趣的想法，但对我来说看起来太复杂了。如果一个元素有 1000 个可放置的位置怎么办？如果我们要同时选择并拖拽多个元素怎么办？
此外，这种方法似乎引入了新的复杂概念，比如“可组合组件（composables）”，甚至是一种 DSL。可能为拖放编写自定义代码比弄清楚这个如何运作要容易得多。我读了页面，没太看懂。例如，这句话很难理解：“与其直接编程所有这些视觉行为，你只需为每个想要可拖拽的元素说明，拖拽它应该导致应用程序的哪些未来状态。”这一点也不“简单”。编写新代码会更容易，尤其是有了 LLM。
- sourdecor
我觉得这是一个非常酷的项目，但我也非常欣赏对 Hazel[0] 的介绍。
[0]: https://hazel.org/
- nostrebored
我们将不断重新发明数据流和规划问题，直到时间的尽头；你会惊讶地发现，有多少基础软件组件使用了这种范式。