>>770
そうすれば、ターゲットがクリックされたことを機会に、ターゲットをフリーズさせて、
その間にドラッグするためのモジュールを読み込んでそこから再開するというようなことができる
ただ厳密に言うと、async-await、observable的に書いたりフレームワーク使うと
そのイベントの直接のハンドラ呼び出しから同期的に処理が続くとは限らない、
例えばasync関数を呼び出すとそれは次回のジョブキューに登録され、おそらくブラウザだと次回のイベントループ時に処理される

それが組み合わさってくると、クリックされたことを契機に、それからの別のイベントを把握しようと考えても
その一瞬以下の間に１つ２つ取りこぼすロジック上の可能性を残してしまう
そしてこれが発生すると迷惑な事象、つまりバグ挙動になることが多い
ドラッグくらいじゃそんなに大したことにはならないと思うが、メッセージングとかだと０に近い可能性でも駄目なので
確実性を出すためにメッセージにidを振るだとか、再送要求を設計するとか面倒くさい気遣いがかかってしまう

結局はモバイルの音出しの問題のようにasyncな世界を外れたフックが必要になるんだけど、
そこを愚直に書くと汚らしくなるので、今のジョブキューや今のイベントループといった状態を得るためのAPIが要るんじゃないかと思う
ちょっと違うが、ECMAにZoneという、これまたまあまあ違うがNodeの昔のdomain的雰囲気を持ったAPIが提案されてるが
そういうのがいいのかもしれない