元スレ+ JavaScript の質問用スレッド vol.132 +
JavaScript覧 / PC版 / みんなの評価 :
102 = :
イベントハンドリングをデレゲートする、ってどういうこと?
104 = :
>>102
ある要素のイベントをその親のイベントハンドラで受け取って処理すること
子が増減するたびに新しくイベントハンドラを作らなくて良くなる
その反面documentみたいに、いろんな要素からのイベントを受け取ってしまう場合は
どの要素から発生したイベントなのかをチェックする必要があり面倒くさい
なのでdocumentで受け取るなんて普通するか？
106 = :
<input typer="button" id="name">
--
document.getElementById("name").addEventListener("click", function)
こゆこと?
これを
イベントハンドリングをdocumentでうけてデレゲートする
って表現するの?
107 = :
タイプタイパータイペストｗｗｗｗｗ
108 = :
>>106
違う
109 = :
111 = :
>>104-105
発火した要素やparentNode再帰で、idやclassNameを見て切り分けたりする
jqueryのclassNameでのハンドリングがdocumentじゃなかったっけか
当然、<button>の中に<span>が入ってたりすると複雑化したり処理が多くなるが
どっちかっていうと
バブリングを踏まえて処理組んでたり
時系列的に同時に走られるとまずかったり
バブリング停止が混ざると厄介だったり、というほうの影響が大きいと思う
>>109
<div id="p1"><button>b1</button><button>b2</button></div>
document.getElementById('p1').addEventListener( 'click', function(){
if(e.target.tagName==='button'){ /* proc */ }
}, false );
みたいな
112 = :
>>107
添付 天パ テンペスト
113 = :
また髪の話してる・・・
114 = :
プログラミング業界ではdelegateは移譲を意味する
一般的な用語でおそらくインターネットが普及する以前から使われてきた用語だけど、
今の話の文脈のdelegateはjQueryが発端なのかな？
jQueryでは1.4.2からdelegateというこのイベントを親で受け取る機能が追加された
（他にも似たようなliveというメソッドがあったがこれらはイベント関連全てを扱うonに統合された）
果たしてこのjQueryのdelegate以前から使われていたのかどうか
ちなみにjQueryだと>>111のような面倒くさいことは必要なく
$('button').on('click', function() {・・・}) だと
$(document).on('click', 'button', function() {・・・}) と書き換えるだけでいい
多くの場合イベントハンドラの中身はそのまま使える、
またdocumentの代わりにbuttonの上位要素でも良い
115 = :
>>111
なるほどー
勉強なりました。
116 = :
平日家に届く荷物
通常： 自分が家にいないと受け取れない
(再配達あるが例ということで)
デリゲート： 平日家にいる家族に自分宛荷物を受け取っといてくれと頼んどく
現実だといちいち頼まなくても家族が勝手に取っといてくれるだろうがコンピューターは融通がきかないのだ。
余計なことしないとも言う。勝手に開けられてて死亡したことあるしなｗ
117 = :
>>111のfunctionの引数指定 (e) が抜けてた
まあ上位が取って、下位にイベントを当てる、みたいな雰囲気を理解してもらえればいい
プログラミング的にはできるだけ影響を少なく直上の要素などで受けるのが健全
個別にidをつけたり個別にaddEventListenerしたり、としなくてもいい等の利点がある
といっても高尚なパターンとかじゃなくて
誰でも思いついてやってることだと思う
118 = :
なんでもdocumentで受けるのは
グローバル変数使い放題みたいな印象があるな
119 = :
それよりliが動的に足し引きされるやつとかの対応だろ
動けばいいや派はここで積む
120 = :
>>119
そりゃcreateElementするときに個別にaddEventListenerしてからappendChildすれば済む
問題が出るのは、innerHTML操作しかできないわからない層ぐらいじゃね
121 = :
書き忘れたが、今の話のdelegateがjQuery由来ではないのか？というのと
もう一つ、なんでもdocumentというのは、liveメソッドが原因じゃないのか？ということ
jQuery 1.4.2で追加されたdelegateは親要素を指定することができるのだが、
それよりも前に1.3から追加されたliveは親要素は指定できずにdocumentになっていた
（これがわかりづらいという意見があって最終的にonに統一されたのだけれども）
$( "button" ).live( "click", function() {・・・}) だと
buttonではなくdocumentで受け取るようになっていたわけだ
122 = :
>>121
その辺考えるとjqueryは
documentへの委譲を理解せず使ってバグを生み出すコーダーを量産してたとも考えられるな
123 = :
>>122
でも当時はdelegateなんて考えなかったからね
だからこそjQueryは内部の処理を隠蔽して
魔法のような機能をしてますみたいな感じだった
また移譲の認識を広めたのもjQuery 1.7から追加されたonメソッドなわけで
ウェブプログラマとDOM APIにかなりの影響を与えたライブラリだな
その数年後にDOM APIにようやくセレクタを使ったアクセスや
比較方法が追加されたわけだしね
124 = :
>>120
動的に要素いじってる奴とイベント設定したい奴が同じならそうだが…
ライブラリがやってる場合とかなかなかそうもいかない
125 = :
>>124
あー、言われてみれば確かに
ライブラリ側で受信と共に自動生成されますー、とかあるわ納得
そりゃ親に当てるやりかた思いつけなくて詰むな
126 = :
>>96
イベントバブリングを少しでも減らすためと思ってる
document.bodyにしないのは、HTMLタグの<body>が省略されてたり、2つ以上書かれてたりすると、
Javascript側のdocument.bodyが不定になるっぽいから
>>111
jQueryのon()を見た感じでは、指定された要素そのものにaddEventListener()してるっぽい
さすがにdocumentだけで全部を処理していると、targetの管理・分岐が大きくなりすぎて処理が重くなると思う
<button><img></button>
という構造の場合、<img>でイベントが発生した場合にevent.targetは<img>になるから、parentNodeをたどって、<button>に内包されてるか確認しなきゃいけない
jQueryもparentNodeをたどってる
第三者のライブラリを使うと自分で書く必要がなくなるというだけの話
127 = :
>>126
指定された要素そのものにaddEventListenerしているということは
その後に追加された同名classNameを持つ要素に対応できないということになるんだが
それとも、要素追加を監視して逐一リスナ貼り付けてるのか？
128 = :
>>126
> jQueryのon()を見た感じでは、指定された要素そのものにaddEventListener()してるっぽい
そうだよ。こっそりdocumentになっていたのは古いliveメソッドの話
だからdocumentで受け取るなら
$(document).on('click', ～
とする。
そして本来の要素は第二引数に、このように書く
$(document).on('click', 'button', ～
親要素で受け取るという考え方が広まったので、普通に親イベントで受け取る
だけど、簡単に本来受け取りたかった要素 'button' を指定するのは引数一個と簡単で、
さらにthisは本来受け取りたかった要素になっている
129 = :
>>127
classNameで指定されたらclassNameでチェックすればいいだけでしょ
130 = :
>>127
> 指定された要素そのものにaddEventListenerしているということは
> その後に追加された同名classNameを持つ要素に対応できないということになるんだが
だから普通にdocumentにon（addEventListener）するんだってばｗ
そしてonメソッドの第二引数に「指定された要素」を指定することで
まるで「指定された要素」そのものにaddEventListenerしたかのように
違いを吸収してくれている
131 = :
>>129
> classNameで指定されたらclassNameでチェックすればいいだけでしょ
単純なclassNameだけで判別できる場合ならね
132 = :
>>131
その結果がjQueryの複雑なチェック方法なのでは
133 = :
documentをリスナ追加対象にすれば重くなる
最小限の親要素をリスナ追加対象にすればその外に生じた要素に対応できない
対象を考えなきゃいけないのはjqueryなしと変わらない
どこにリスナが追加されるかを意識して使わないといけないのはjqueryなしと変わらない
なんでもかんでもdocumentに追加していては問題が生じる危険がある
いずれにしてもjqueryを使わず普通にできる
なるほど
135 = :
DOMはJavaScript初心者には難しすぎる
jQueryはJavaScript初心者にちょうどいい
136 = :
jQuery のソースコードには、IE9 なら、Android 4 ならとか、数十の分岐処理がある
JS で作る人は、これらの分岐処理でバグるから、正常に動作させるのに、10年以上掛かる
例えば、素のJSでは、要素の削除も、一旦その要素の親を取得してから、
親から見て、子供を削除する
var elem = document.getElementById('abc');
elem.parentNode.removeChild(elem);
こういうように書かないと、IE11 では動かない。
だから一々、どのブラウザでは動かないとか、頭を抱える
素のJSで作っている奴は、調べものばっかりして、頭を抱えているけど、
バグの多い製品しか作れないw
基本、調べものばかりしている奴は、コーディングの練習にもならないし、
時間を浪費して、上達しないから最悪
137 = :
グローバル変数相当に名前空間とクロージャそれぞれどういう長所短所ある？
前者はその都度MyApp.つけなくてはならず
ここの皆はどっち使ってる？
138 = :
どっちかしか使わないなんてない
名前空間といっても要するに1つのオブジェクトに押し込めるかどうかだけだし
139 = :
>>136
今時趣味で作るならモダンブラウザオンリーで十分だと思うよ
仮に仕事でIE対応が必要だとしても、考え方が反対だと思う
やっぱり、対応方法はわかってるけど、自作するのは面倒くさい
そこで効果を理解してるライブラリを使うというのが正常だと思う
jQueryを何の為かどういう仕組みか分からず使ってる状態っていうのは
絶対に困る場面が出るし、jQueryの良さを引き出せないよ
140 = :
今の時代は便利なものをどれだけ使いこなすかのほうが重要になっている
141 = :
jQueryあにき今日も全開っすね( ´∀｀)bｸﾞｯ!
142 = :
LSの機能使いたいけど、非対応ブラウザにも対応させたいけど、自分で書くのめんどい！人限定ライブラリ
143 = :
>>140
なんか言うことが営業っぽい
144 = :
>>132
> その結果がjQueryの複雑なチェック方法なのでは
何が複雑なの？
145 = :
>>138
どう使い分けてる？
146 = :
>>145
使い分けという時点でなんか違う気がしないでもないんだけど
・どう使いたいか・あとから変更したいかどう変更したいか
・状態を持たせたいか持たせるときどんな感じで使うのか
・1個だけあればいいか複数複製したいかnewしたいのかコンストラクタ次第で色々変えたいか
とか色々ある、んだけど
でも手法全体は変えないで後から変更調整を
したいときでもわりとどうにでもなるよね
147 = :
>>142
それはただのポリフィル
jQueryはあくまでjQueryワールドを提供するだけ
148 :
グローバル変数を1つ宣言するのと
関数を1つ宣言するのとでは
グローバルの汚染度は変わらないですよね？
149 = :
>>148
console.log(globalOsen?'汚染されてる！':'汚染されてない');
var globalOsen = 'キャラメル';
と
console.log(globalOsen?'汚染されてる！':'汚染されてない');
function globalOsen() {
return 'キャラメル';
}
比べてみなよ。
console.log(globalOsen?'汚染されてる！':'汚染されてない');
var globalOsen = function() {
return 'キャラメル';
};
なら変わらないけど。
150 = :
なんで汚染だけローマ字なんだよ
グローバルもローマ字にしろや
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
トップメニューへ / →のくす牧場書庫について