元スレ+ JavaScript の質問用スレッド vol.135 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

351 = :

この件は良く知らんのだけど
・>>337いわく1.9.1の時点からそういう挙動
・scriptのasyncはHTML5から
・jq 1.9.1リリース　2013年02月04日
・HTML5勧告　　　　　2014年10月28日
順番おかしくね

352 = :

>>351
jQのpromise的動作とjsタグのasync的動作はまったく別物

353 = :

間違ったscriptタグね、まぁ何でもいいや

354 = :

>>352
>>346
JQueryの良く分からん挙動がscriptのasyncと関係ないということになると
>>342-343の大長編レスの前提が崩れるんじゃないか？

355 = :

同期、非同期ぐらい勉強しろよ

356 = :

>>351
> ・>>337いわく1.9.1の時点からそういう挙動

どこにも1.9.1の時点からなんて書いてない。
少なくとも1.9.1ではそういう挙動だったってだけ。
おそらく最初からそうだろう

357 = :

>>352
何を持って別物と言ってるのかは知らないが、
PromiseオブジェクトにはPromise.resolve()とPromise.reject()という
メソッドがあって、それぞれ解決済み、リジェクト済みのオブジェクトを返す。

このオブジェクトにあとからthenメソッドでコールバック関数を
くっつけてもちゃんとコールバックが呼ばれるんだよ。

358 = :

> jQのpromise的動作とjsタグのasync的動作はまったく別物

jsタグってなに？HTMLタグっていいたいの？
HTMLタグのasyncはJavaScriptの実行を遅らせることで
見た目上のパフォーマンスを上げる技術で

その弊害として、DOMContentLoadedが先に呼ばれてしまうから
JavaScriptの発動が起きないってものなんだけど

jQueryはそのことも考慮されてるから、普通に書くだけで
非同期でJavaScriptが読み込まれても大丈夫って話をしてるんだよ

Promise的動作っていうのは、コールバックを後から追加しても
発動するって話。あんた全く別物の話をしてるよ

359 = :

>>351
http://tokkono.cute.coocan.jp/blog/slow/index.php/xhtmlcss/script-defer-async-attribute-of-major-browsers/

async対応はChrome8（2010年12月）、Firefox 3.6（2010年1月）から

360 = :

もう少し詳細なリストが有った。
http://stackoverflow.com/questions/1834077/which-browsers-support-script-async-async

361 = :

>asyncはJavaScriptの実行を遅らせることで

遅らせてるのか？
htmlの解析処理と当該jsファイルのダウンロード・実行処理とを
切り離して並行処理させることで、htmlのパース・文章や画像の配置等が妨げられないようにしているだけでは？

DOMContentLoadedより後に処理が開始されるのではなく
DOMContentLoadedの前に終わるとは限らないというだけの話では？

362 = :

> DOMContentLoadedより後に処理が開始されるのではなく
> DOMContentLoadedの前に終わるとは限らないというだけの話では？

今はそういう細かい話はどうでも良くて、
需要なのはscriptタグのasyncを使われてると、DOMContentLoadedが
先に発生してしまうことがあるってことですよ

他にもRequireJSのような非同期でJavaScriptモジュールを読み込む仕組みを
使ったときにも発生しましたね。

363 = :

たとえ細かい話でも虚偽が含まれてる人の話は信用できないからなあ

364 = :

はは、信用出来ないっていうだけで、間違ってるとは言えない
あわれよのうｗ

365 = :

まあ間違ってるわけじゃないからね。信用出来ないってだけ

366 = :

>>354 >>357 >>358
ごめん訂正するね
言葉足らずだった
「別物」ではなく「実装箇所が別物」
動作としては似たようなものだ
一番最初の気持ちとしてただ>>351の言ってることが的外れだったので意図としてはそれを訂正したかった

367 = :

window.addEventListener('load', ... )ではどうしてもダメなケースを聞きたい
>>330のような無能サンプルコードは除外するものとする

368 = :

（たぶんダメなケースなんて）ないです

369 = :

>>367
ページ内にある画像全てが読み込まれないと
JavaScriptが動かないのでダメ

370 = :

>>368
操作性悪くなって遅くても動くからダメじゃないんですって主張は禁止なｗ
その理屈だと電気がなくても生きていけるって回答になる。

371 = :

画像を減らそう！

372 = :

ゼロに。ゼロがいい。ゼロにしよう。

373 = :

asyncで読ませたい
どうしても早いタイミングDOMContentLoadedで動かしたい
asyncするとDOMContentLoadedに間に合わないリスクが怖い・・・
jQueryなら専用のコード書かなくてもすぐに実現！！　←今ココ

ざっくり書くとこんな感じかね？
DOM APIでもできないわけではないし
jQueryならといっても最初からそれを狙った実装ではないようだが
現実として便利に転用できますよ、という具合

374 = :

>>370
どっちにしてもwindow.onloadだとロードイベントに一個しか関数を紐付けできないから不便極まるんだよなぁ
一個だけしか使わないってんなら関係ないけどさぁ…

375 :

>>308
遅レスだが、今時の技術者とは思えん発言だな
彼の中では、大部分のCSS3(草案)が枯れてない＝不安定で使えないということになるのか

378 = :

そんなことよりお前らremoveEventListenerとか使ったことある？
使う機会がまったくないよなアレ

379 = :

>>378
そもそも今この瞬間までそいつの存在すら知らなかったぞ

380 = :

>>378
使ったことはないが
disableにできない類のもののイベントリスナを切りたいとか
起動する関数を切り替えたいとか
使える機会はいろいろ思いつくぞ

呼び出される関数側でチェックして即returnとかの別手段でだいたい十分だけど

381 = :

>>380
> 呼び出される関数側でチェックして即returnとかの別手段でだいたい十分だけど

そういうのはクラス名で制御すべきだよ。

例えばこんな感じにしてると、spanのクラスが
それぞれmode1 or mode2 の場合のみ、該当のものだけ発動してくれる

$('span.mode1').click(function() { alert('click1'); })
$('span.mode2').click(function() { alert('click2'); })

382 = :

>>378
unload,remove時の後始末

383 = :

>>378
普通に使うけどなあ
来れなかったら、addしたイベントをどうやって剥がしたら良いのかわからん

384 = :

addしたイベントを剥がす機会がないということでは？

385 = :

要素が増減するならばデリゲート使って親要素でイベントを捉えれば良いし
その方が効率なわけで、わざわざイベントハンドラを外すことはないね

386 = :

>>384
なるほどー
>>385
増減しない時は？

387 = :

>>386
増減しないならつけっぱなしでいいやん

388 = :

>>387
つけっぱなしで良いこともあるし外さにゃならんこともあるな
この辺は経験というか、やったことあるかどうかの差だからしゃーないわな

389 = :

だからその外さなきゃならない場合ってのが無いんだっていう話をしてるんだが
経験があるというのなら、その経験を語れよ

390 = :

webページ作るのに外さないといけないユースケースは確かにめったに無さそうだ。
実はコンソールで色々いじくって実験する用なんじゃないのか。console.logみたいに

391 = :

使った経験は無いが、想像するに一つのボタンに複数の機能を持たせるときには使えそう

392 = :

>>391

>>381を見てね
ロジックで処理を分けるのは古いやり方だよ。今は状態ごとの処理を定義する。
こうすることがバグも減らせるんだよ。ちゃんと外せたか？二重に登録してないか？
なんて考える必要がない。

こういうものこそ経験っていうんだけどな

393 = :

>>392
ますますremoveEventListenerの使い道ないじゃないか…（憤慨）

394 = :

>>389
色々あるけどなあ
フレームワークっぽいもの作ってたときとかよく使ったよ

395 = :

一個のサイト作る場合ではなく
複数のサイトで汎用的に使うコンポーネントなんかを作るケースだと
CSSまで自由に出来なくてJSでやらにゃならんこともあって
そんな時には必要になるなあ

みんなも自分のサイトに組み込んでるフレームワークやライブラリのコードをのぞいてみると
案外使われてるのに遭遇すると思うよ

396 = :

いちいち重複イベントチェックなんて面倒だ
まとめてごっそり総入れ替えだ

397 = :

リフレクションAPIやプロキシーAPIと同じでフレームワークとか作る人用か。使うだけの人には洋ナシ体型

398 = :

経験の差が出ましたなｗ

399 = :

まあ無いよね。

400 :

くだらん喧嘩は他所でやれｗ
ツイッターとか