銀の弾丸

プログラミングに関して、いろいろ書き残していければと思っております。

mouseenterとmouseoverの違いなどDOMイベントの発生状況を可視化して調べてみたよ

f:id:takamints:20180507065734p:plain

HTML5のDOMイベントに、mouseentermouseoverという、よく似たマウスイベントがあります。ここには、その違いについて調べたことを書いておきます。

どちらもマウスポインターが要素の上に入ってきた時に発生するイベントで、それぞれに対応する「マウスポインタ―が要素から外れた」時のイベントとして mouseleavemouseout もありますね(mouseenter には mouseleavemouseover には mouseout が対応します)。

この2種類のイベント間には、発生要因や伝播(バブリング/プロパゲーション)に関する違いがあります。

私は最近まで、この違いを意識しておらず「歴史的理由による別名?」かと思っていて、その場で適当に思いついた方を使っていました。 先日ふと疑問に思ってMDNで調べてみたら、どうやら上記のように明確な違いがあると知ったのですが、はっきりイメージがつかみきれなかったので確認用に作ってみたのが以下のものです。

マウスイベントを可視化する

以下、4つのDOM要素が入れ子になっていて、各要素が拾ったマウスイベントを表示します(前述の4つのイベントだけ調べるつもりでしたが、せっかくなので他のイベントもListenしました)。要素の上でマウスを動かせば各インジケータがビカビカします(ちょっとうるさいですが目立つと思って)。

各要素には、preventDefaultstopPropagationというチェックボックスがあります。 それぞれチェックを付けると、その要素のイベント処理で event.preventDefault()event.stopPropagation() を実行します。 例えば、‘#Div4‘の上でマウスを動かすとmousemoveが全要素に発生しますが、stopPropagationにチェックを入れた要素の親へは伝播しません (preventDefaultはこれらのイベントに関して変化がなさそうなのですが、とりあえず残しています)。

マウスポインタが要素の「外側から内側」へ移動するとき

全てのstopPropagationのチェックを外した状態で、#Div1の左右または下の外側から*1#Div4の内側までマウスポインタ―を動かしていったとき、以下のことが観察されます(実際にやってみてください)。

*1 - マウスポインターが各要素の上側を通過すると情報を表示している要素の境目でイベントが発生してしまうので避けるべき。

マウスポインタが要素の「内側から外側」へ移動するとき

次に、#Div4 の内側から、左右または下に向かって、#Div1 の外側までマウスポインタ―を動かすと、以下のことが観察できます(全てのstopPropagationのチェックは外したままです)。

各イベントの伝播を確認

上と同じく、全てのstopPropagationのチェックを外したままで、各イベントが発生した場合、

  • mouseovermouseout は親要素へ伝播しますが、
  • mouseentermouseleave は伝播しません。

そして、伝播を抑制するには、イベントハンドラーの中で event.stopPropagation() を呼び出します。

MDNに書いてあること

MDNのmouseenterには、以下のように書かれています。

With deep hierarchies, the amount of mouseenter events sent can be quite huge and cause significant performance problems. In such cases, it is better to listen for mouseover events.

翻訳すると「深い階層では、送信される mouseenter イベントが大量になる可能性があり、重大なパフォーマンスの問題の原因になり得る。その場合は mouseoverイベントを使うといい」とのことですが、これって上で見たことと少し雰囲気が違ってないか?と。 mouseover が全ての親に伝播していて、たくさん発生しているように見えましたけど?

「逆じゃないの?」って、かなりMDNを疑ってみたのですが、しかし、これはこれでどうやら間違いではないみたい。 すべての要素でイベントをListenしているので、大量の mouseover が発生していましたが、通常そんなことはしませんね。 イベントはaddEventListenerしている要素に発生して後は親要素に向かって伝播するだけ。 イベントを処理すべき要素だけにハンドラを設定しておけばなんら問題がないはず。

一方「mouseenterが大量に発生して」という部分はよくわかりません。 そのようなケースが今のところ想定できないのですが。 mouseenterは、そもそも親要素に伝播しないし、論理的な自要素の領域内にあればmouseleaveは発生しないので、必要なところでListenしておけば問題ないような気がするし、そもそも用途が違うんじゃないのか?と。

ちょっとモヤモヤしてますが、とりあえず・・・。

リンク

Heroku CLI 7.0.2? のエラーを修正

f:id:takamints:20180422144244p:plain

Git for Windowsから最新版の Heroku CLI を起動するとエラーが発生。バージョンは下に書いてますけど、そもそもエラーが出るので確認できない。Power Shellからなら大丈夫。32ビット版でも64ビット版でも同様ですね。未確認ですが、MSYS とか Cygwinでも同じ現象が起きるんじゃないかなと思います。

とりあえずはインストールされたシェルスクリプトに1文字追加すれば治ります。

直接的な原因が分かったところでGitHubにはIssueを上げてひと安心。「さてIssueも上げたしForkしてCommitしてプルリクしてどや顔するかな相手は天下のセールスフォースドットコム・・・」と、ヤケに日曜朝から心拍数を上げたのですが(おちつけ自分)、結局どこを直せばよいのかわからなくてWatchだけして、そっとGitHubを閉じました。 が、なんと4時間後にはこの問題が改修されててIssueもClose。素早い対応ありがとうございますー。

クラウド開発徹底攻略 (WEB+DB PRESS plus)
菅原 元気 磯辺 和彦 山口 与力 澤登 亨彦 内田 誠悟 小林 明大 石村 真吾 相澤 歩 柴田 博志 伊藤 直也 登尾 徳誠
技術評論社
売り上げランキング: 88,620

インストール直後にエラー

Windows用Heroku CLIの最新版をインストールしてGit Bashから実行すると以下のエラーが発生しました。

$ heroku
sed: -e expression #1, char 7: unterminated `s' command
/c/Program Files/heroku/bin/heroku: line 4: ./../client/bin/heroku.cmd: No such file or directory

sedのsコマンドが終わってない」と言っている。

原因究明

コマンドはC:\Program Files\heroku\bin\herokuという名のシェルスクリプトなので中身を見てみると。

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\,/,g')")

"$basedir/../client/bin/heroku.cmd" "$@"
ret=$?
exit $ret

2行目で、sedでバックスラッシュ(円記号)をスラッシュに変換しようとしているが、バックスラッシュがエスケープされていませんね。

応急対策

これエスケープするだけで動くんじゃないかね?と

f:id:takamints:20180422095556p:plain

Git Bashを管理者権限で開いてvimで編集したところ、ホントにこれだけで正しく動くようになりました。 (Program Files 以下を変更するには管理者権限が必要)

バージョンは 7.0.2、、、ん?

バージョンは以下のように7.0.2だったのですが、これってホントにリリースバージョンなんですかね。 GitHubリポジトリでは現時点でv6.16.16です。Windows用は別管理ってことはないと思うんだけど。

これ、ダウンロードページから公開しちゃいけないものを公開しちゃっているとかではないのかな。 よくわからなくなってきました。

$ heroku --version
heroku-cli/7.0.2 win32-x64 node-v9.11.1

とりあえずIssueはポスト

しかしまあ、しばしGoogle翻訳と格闘してから、とりあえずIssueをポストしておいた。

で、現在のリポジトリ内の /resources/exe/heroku が問題のスクリプトなんだけど、不思議なことに半年前に追加されたときから、きちんとエスケープされている。 ということで、どこを直せばよいのかわかりません。インストーラを作るところか動作上の問題なのか。

まあ偉い人が直してくれるんだろう。なにしろ天下のセールスフォースドットコムだし。

追記)この記事書いた時点で既にIssueがクローズされていました。早っ! 修正箇所はやっぱりresources/exe/herokuで。バックスラッシュが4つになっていましたわ。 二重にエスケープしなきゃなんなかったのかー。

関連リンク

devcenter.heroku.com

github.com

github.com

ES6に対応した「grunt-contrib-uglify-es」を使用する

grunt-contrib-uglifyのES6対応版がgrunt-contrib-uglify-esという名で別途公開されてましたというお話。

f:id:takamints:20180322202444p:plain

速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター! 速習シリーズ
WINGSプロジェクト (2015-08-28)
売り上げランキング: 1,828

JavaScriptのタスクランナーGruntからUglify-Jsを使用してスクリプトを圧縮・難読化する grunt-contrib-uglify なんですが、ES6に対応していなくて困ってました。 ES6の「アロー関数」や「 letによるブロックスコープの変数宣言」は、うっかりミスの防止に役立ちますから今後なるべく使いたい。 この手のバグは見つけにくいので手を焼きますから。

「しかし uglify でコケるから・・・」ってのはまさに本末転倒。ということで、本腰入れて「どうにかならんか?」と調べてみたら Stack Overflow に、

「grunt-contrib-uglify の harmony ブランチが使えるぜ!」という情報がありました。 このブランチで(その名の通り)ES6対応しているようです(完全ではないとも書いてありますが)。 で、GitHub から特定ブランチをnpmでインストールするには以下のようにすれば良いらしい。

$ npm install git://github.com/gruntjs/grunt-contrib-uglify.git#harmony --save-dev

これを実行すると grunt-contrib-uglify-es というモジュールがインストールされたので、まさかと思って npm で grunt-contrib-uglify-es を検索すると、なんとそのものズバリが公開されているじゃありませんか。てことで、GitHubから取ってこなくても、以下の普通なnpmでよかったみたい。

$ npm install grunt-contrib-uglify-es --save-dev

加えてモジュール名が変わったので、 Gruntfile.js のタスクロード部分も書き換えが必要ですね。

Gruntfile.js

    ~
    grunt.loadNpmTasks('grunt-contrib-uglify-es');
    ~

これでめでたくアロー関数とletが使えるようになりました。

元々入ってた grunt-contrib-uglify は、残しておいても問題なさそうですが、 まあ、使わないならアンインストールしておくべきでしょう。

参考サイト