- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
771 ：デフォルトの名無しさん[sage]：2018/02/02(金) 00:57:19.53 ID:sA1ck48z - >>770
上で挙がってたjQueryのreadyはDOMContentLoaded過ぎても効くし、
DOMCLには対応するdocument.readyStateがあるよねってこと
例えばじゃあ今からマウスの位置に何かを表示しますってしようとしても
そこからマウスが動かなくていつまで経ってもmousemoveイベントが起きないといつまでも表示されないし、
もちろんそれで致命的な何かが起きるわけではないけれど、
今Webでもリッチなアプリが作れるようになってきてる訳でそういう細かいデザインも気になってくる
かと言ってあまり複雑なことはしたくないということ
だからdocument.readyのように
documentレイヤーだけでいいからlastEvent.mousemoveみたいなのがあったら結構楽になる
でも一々イベント履歴をチェックするのも面倒だから、できればaddEventListenerで取りたいけど、
実際無制限にするわけには行かないから、一つの落とし所としてはここからイベントを貯めるという指定ができるようにすること
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
773 ：デフォルトの名無しさん[sage]：2018/02/02(金) 01:01:39.79 ID:sA1ck48z - >>770
そうすれば、ターゲットがクリックされたことを機会に、ターゲットをフリーズさせて、
その間にドラッグするためのモジュールを読み込んでそこから再開するというようなことができる
ただ厳密に言うと、async-await、observable的に書いたりフレームワーク使うと
そのイベントの直接のハンドラ呼び出しから同期的に処理が続くとは限らない、
例えばasync関数を呼び出すとそれは次回のジョブキューに登録され、おそらくブラウザだと次回のイベントループ時に処理される
それが組み合わさってくると、クリックされたことを契機に、それからの別のイベントを把握しようと考えても
その一瞬以下の間に１つ２つ取りこぼすロジック上の可能性を残してしまう
そしてこれが発生すると迷惑な事象、つまりバグ挙動になることが多い
ドラッグくらいじゃそんなに大したことにはならないと思うが、メッセージングとかだと０に近い可能性でも駄目なので
確実性を出すためにメッセージにidを振るだとか、再送要求を設計するとか面倒くさい気遣いがかかってしまう
結局はモバイルの音出しの問題のようにasyncな世界を外れたフックが必要になるんだけど、
そこを愚直に書くと汚らしくなるので、今のジョブキューや今のイベントループといった状態を得るためのAPIが要るんじゃないかと思う
ちょっと違うが、ECMAにZoneという、これまたまあまあ違うがNodeの昔のdomain的雰囲気を持ったAPIが提案されてるが
そういうのがいいのかもしれない
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
776 ：デフォルトの名無しさん[sage]：2018/02/02(金) 01:05:23.52 ID:sA1ck48z - >>772
要するに、asyncな世界でイベントハンドリングを確実に綺麗に上手くできやすくするための
なんらかの、そして幾つかの標準による補助機能が必要という話
たとえばaddEventListnerの第三引数のオプションの指定を増やす
抜本的な改革はその方向じゃ難しいかも知れないが、
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
778 ：デフォルトの名無しさん[sage]：2018/02/02(金) 01:15:47.94 ID:sA1ck48z - >>774
話が噛み合っていないね
ここから先と指定できればいいが、ずっと貯めておくのは非現実的だし、
ならそういう標準的な補助の話を一旦抜きとしても一般的な話をしてもやっぱり
マウスダウンが起きた、ではここから先のマウス移動を見よう、としてもasyncな世界だと
onmousedown=e=>onmousemove=
みたいな同期的なロジックではないのだから、
クリックが起きてから、マウスの移動を検知し始めるまでに１つイベントが走ってしまうかもしてない
つまり、マウスダウンされた瞬間超人的なスピードでマウスが動いた場合、取りこぼすということ
ドラッグの話の場合大げさなことかもしれないが、
それでも同期的に書いてた頃はイベントループという仕組みでこういうケースも保護されていた
でもそれが無くなると、本当に様々な心配事が出てきて、それは実際起きうることだったりもするという話
その一つの解決策は、onmousedown=に直接フックして、同期的に>>775の処理だけでもしとくことだが、
そうするとせっかくの抽象化async世界が壊れる
それなら最初から同期的に昔からの書き方で書いとけばいいということになる
そういう問題
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
780 ：デフォルトの名無しさん[sage]：2018/02/02(金) 01:35:18.66 ID:sA1ck48z - >>779
最後のイベントだけでは有効なケースはより限られるという話はした
ただそれでもDOMC.L.みたいなケースには有効
だからそういうのもあるけど、もしくはここから先イベントを貯めると言うことができればいいかもという話もして、
それも完璧じゃないけど、改善作は欲しいよねという話になってる
だけどここまで考えてやっぱりObservableAPIが良いのかなと思い始めた
つまりdragstart = mousedown.flatMap(() =>mousemove
とかした際にそのフレームワークがしっかり可同期的に設計されていれば
とりあえず、mousedownからmousemoveまでの間の取りこぼしはなくなる
もちろんfor await dragとかをしてもそこは非同期だから
そのドラッグから次に何かをするまでの間は気をつけないといけないけれど、
こういうようにイベントを組み合わせて１つのイベントとして固めておくと言うことができればかなりの問題緩和策になる
問題はObservableが標準に入ったとき、async generatorとかあるのに対し内部的に同期で回せる設計でやってくるのかということだな
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
782 ：デフォルトの名無しさん[sage]：2018/02/02(金) 01:57:53.92 ID:sA1ck48z - >>781
だから例えば、ドラッグ＝マウスダウン→flatmap:マウスムーブ→until:マウスアップ、と設計するように
あるイベントが発生してそれから先また別のイベントを補足したいってことはよくあるけど
同期的に書いてそのイベントループ中にイベントの補足を開始できればいいけど
async関数使ってると原理的にそこが保証されないコードになることがあるよね
それを簡単に改善できる方法ってないのかなって話だよ
イベント発生時点でやれば良いって言っても
async関数でイベントをawaitしてるとイベントが起きたループとは実際処理が走るのはずれるのよ
つまり
new Promise((_ok)=>{ok=_ok}).then(e=>console.log('P'))
のとき
onclick=e=>{
ok(e)
console.log('C')
}
とすると、C→Pの順番で呼ばれるでしょ？
Promiseってのか解決と同時にコールバックが走るわけじゃないんだから、
そこで隙間が開いてしまって、積み重なるとタイミングバグの元になるのよ
それを確実に回避するためにはイベントハンドラを使って同期的に処理を書き連ねていかないといけないから
async世界と相性悪いねって話だよ
|