ドラッグ操作を「宣言」するだけで作れる新手法、D2が面倒なコードを不要に
Declarative Dragging
ドラッグ＆ドロップの実装は、幾何計算やフィードバック、アニメーションのコードが煩雑で、教育者やゲームデザイナーなど多くの人が手を出せずにいる。Declarative dragging（D2）はこの問題を逆転させ、要素をドラッグした先の未来の状態を指定するだけで、エンジンがそれらを投機的に描画して位置を抽出し、スムーズなドラッグ操作を合成する。モデル駆動で合成可能なこの手法は、SVG向けライブラリDragologyとして実装され、数学的探索やプログラミング環境Hazelのリファクタリングなどに応用されている。
単純なモデル駆動のドラッグ＆ドロップ動作を組み合わせて、より複雑な動作を作れる。さらにモディファイアで、フローティングやスナッピング、トランジションといった機能を重ねられる。
HNでの議論
93- gavinray
ドラッグ＆ドロップにまつわる面白い話がある。
最初の仕事でのこと、毎週チケットの割り当てと見積もりをする会議があった。
技術に詳しくないPMがホワイトボードに「ドラッグ＆ドロップ」と書いて、次に私の名前を書いた。
「Gavin、これどれくらいかかりそう？」
「一週間まるまる。少なくともね。もしかしたらもっとかも？」
PMは笑ったが、私が冗談を言っていないと気づいた。
「『一週間まるまる』ってどういうこと？馬鹿げてるよ、他の人に任せるべき？」
「まあ、そうしてもいいけど、早く上がるとは期待しないでね。」
彼は愕然として叫んだ。「ただのドラッグ＆ドロップだろ！」
10〜15分、部屋中のエンジニアが難しさを説明しようとしたが、彼は不機嫌そうに「わかったよ」と言って諦めた。
「ただのドラッグ＆ドロップだろ」というフレーズは、私がそこにいる間ずっと内輪ネタになった…
- btown
おお、これはとてもとてもクールで、とてもとてもタイムリーだ！
論文はこちら：https://declarative-dragging.github.io/D2.pdf
個人的に、エージェント的コーディングの残されたギャップの一つは、マルチモーダルLLMでさえインタラクティブなモーション効果の正しさや「感触」を確認するのが難しいことだと思う。例えば、いくつかのスナップショット状態のスクリーンショットを撮ることはできても、基盤となるノードが動き、（場合によっては）リフローする際の反応についてはどうか。ネストされたゾーンの文脈で手首を素早く動かす感覚をどうやってQAする？
答えは、その必要を避けることだ。状態に関係なく動作が予測可能であることを保証する（ほぼ証明可能な）正しい基盤があり、それに応じてレンダリングするだけだ。
この論文のアプローチはここが素晴らしい。複数の可能な状態を同時に楽観的にレンダリングし、ドロップゾーンと距離がどのように導出されるかに関する合成可能な代数（小さなコンビネータ言語）により、実際には非常に高レベルのインターフェースを可能にしている。すべてがキビキビと正しく感じられ、書くコードは可能な限り最小限だ。ただし論文は状態管理がやや複雑だと指摘している。しかしこれは解決可能に思える！
これがHTMLに移植されたら、現代の開発ツールキットの信じられないような一部になるだろう。これが意味することをとても楽しみにしている。
- nostrebored
我々はデータフローと計画問題を永遠に再発明し続けるだろう。どれだけ多くの基本的なソフトウェアがこのパラダイムを使っているかに驚くはずだ。
- codedokode
面白いアイデアだが、私には複雑すぎるように見える。要素をドロップできる場所が1000箇所あったらどうする？複数の要素を一度に選択してドラッグしたら？
また、このアプローチは「コンポーザブル」やDSLといった新しい複雑な概念を導入しているようだ。おそらくドラッグ＆ドロップ用のカスタムコードを書く方が、これがどう動くかを理解するより簡単だろう。ページを読んでもあまり理解できなかった。例えば、このフレーズは理解するのが難しい。「その視覚的振る舞いをすべて直接プログラムするのではなく、ドラッグ可能にしたい各要素について、それをドラッグするとアプリケーションのどの未来状態に導かれるべきかを単に言うだけでよい。」全然「単に」ではない。新しいコードを書く方が簡単だ、特にLLMを使えば。
- sourdecor
これは本当にクールなプロジェクトだと思うが、Hazel[0]の紹介もとてもありがたい。
[0]: https://hazel.org/