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

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

401 = :

別ページから要素(今回はDL)部分を引き抜きたいです。
その別HTMLを同じ階層に置けば、下記でできるのはわかりました。

$(document).ready(function(){
$("#TARGET_ID").load("test.html #yomikomi-block dl");
});

このtest.htmlは別階層にありこれは同じ場所に移動させることができません。

../sample/test.html

と指定すると、test.htmlは読み込んでくれません。

ここはどのようにすればよいのでしょうか？

Firefox, Chrome, Sneipnirで試してどれも同じ結果です。
ググると、Firefox特有でそうなるっていう場合もあるようですが、
今回は他のブラウザでも指定できません。

よろしくお願いします。

402 = :

>>397
クロージャで参照を持っている場合は参照が切れない

404 = :

とりあえず全て===で書いていますが
==でいい場合は==の方がいいですか？
判別が面倒なので全部===にしています

405 = :

>>404
> ==でいい場合は==の方がいいですか？
どんな判断基準で「いい」のですか？
とりあえず、=== の方が高速です。

型の自動変換を亜為に入れてあり、自動変換処理を期待するいる場合は == しか選択肢がありません。
型の自動変換を期待しないなら === を選択します。
…という当たり前の回答しか出来ません。

406 = :

>>402
ということはremoveChildする前に参照しているノードにnullを設定してあげればいいってことかな

407 = :

==も===も型が同じ場合踏むステップは同じだからES6まではどちらが原理的に高速だとかはない
個人的にはどちらかというと===を使うのに凝る方がハマりやすいから、==がオススメ
あとはES7でValue Objectsと演算子オーバーロードが入ることを考慮する時期になってきた
別クラスや別参照同値のValue Objectsは===だとfalseになってしまうだろう

例えば良く特に0と等価評価するときは===を使えというが
function isZero(n) {return n === 0}だと
isZero(0L)のように別型の数値を渡した時、今の流れの仕様だと
typeof 0L === "int64" よりfalseになってしまうようになりそうなのでマズイかもしれない

関数に渡される範囲を把握してるつもりでも、
例えばuse ～が他所のスクリプトによってグローバルトップで使われた時
Float32Arrayがnumberではなくfloatを返すようになったりもろもろあるかもしれない

今はそういう流れ、一応誤解無いように言うと
将来も動くスクリプトであるためそうした方がいいというのではなく、
今早そうだから、みたいなのより
もっと将来に渡って通用しそうな感覚の方がいいでしょって感じ

409 = :

>>407
なぜ型が同じ場合に限定して話をするのだろうか
型が違うなら厳密等価演算子が高速なのは明白だろう

"0" == 1; // false
"0" === 1; // false

当然ながら === の方が高速だ。
== は型変換処理が発生するが、=== は型変換しないので速い。

"0" == 0; // true
"0" === 0; // false

=== が高速だが、結果が異なる。
型が異なる場合に true を返して欲しいから == がいいとあなたは判断するが、逆の結果を期待する人は === が望ましい。
ようするに、等価演算子に型変換を期待するか、によって使用する演算子を選択すればいいだけの話。

個人的には変数に格納される型を限定した方が安全性が増すから ==== しか使わない。
必要なら事前に型変換しておくから typeof 演算子をほとんど使わない、というのもある。

410 = :

>>387
引数でいくつか検索したんですがどれも要領を得ないというか
わざわざ難しく説明してあるので理解できませんでした

>>388
http://jsbin.com/wajelale/1/edit
これが完成版です。これなら>>383の質問もわかりやすくなるでしょうか？

411 = :

>>410
呼び出し元で実引数に 0, 1, 2 を指定しているからとしか言いようがない。
timeoutID は>>388で説明した。

412 = :

>>410
たぶん難しく考えすぎてるだけだと思う

timer = setTimeout( fn , interval ); // 開始
clearTimeout( timer ); // 終了

これはわかってるんでしょ？
問題のコードでは、3つのタイマーを動かして止めるから

var timer1;
var timer2;
var timer3;

でも別に構わんのよ。ただこれを書いた人は
止めるボタン、タイマーID、数字を表示する要素をセットにするのに
引数nを使うって方針を建てたため、変数timerも配列になったってだけ

オブジェクトにすればいいのにね

413 = :

>>412
> オブジェクトにすればいいのにね
いや、クロージャなんだから変数は一つでいいと思うんだが…
このコードを書いた人はクロージャを理解してないとしか思えない
それから、timeoutID を使わないなら変数を使用する必要もないし、使用するなら clearTimeout しないと意味ないし、改善点がいろいろある

414 = :

>>383
>timers = []; の役割が全然わからないです。
timers = [];は配列の初期化

>なぜtimers[n]と書いているのかnは何の役割になっているのか
nは配列の添字
3つのスロットの情報を配列に格納して引数のnでどのスロットかを判別してる


>>413
>>410の完成版だとclearTimeoutしてる

415 = :

>>412
その部分は引数を除けばわかります
全体の流れや個別の部品の意味はわかるのですが引数の部分が何をやってるのかがわかりません


>>414
timers = []; と書くと配列（中身は未定だが）の中身は今の時点では空
というような使い方ができるということですか？

＞3つのスロットの情報を配列に格納して引数のnでどのスロットかを判別してる
これです。その意味がわからなかったんです
参考書を見ても引数を指定することで具体的にどう動くのかがわかりません

引数は必要個数分書く（個数より少なくてもエラーにはならない）と覚えたのですが
このスクリプトではスロット分を書いているわけではなく、ただのnの1つだけです
これだけで、なぜ自動で振り分けられるのでしょうか？そういう機能だと言われればそれまでですが
この辺の仕組みがどう調べてもわからないです
関数を海水を真水に変える装置と考えると引数は海水という例えは間違っているのでしょうか？

検索しても、どなたの情報が合っているのかわからず、とても詳しそうな方の情報を見ても
わかりにくい言葉を使って論文のような書き方をしていることが多く、私の頭では理解できていません

このスロットにおける引数の動きを馬鹿にでもわかるような言葉で教えていただける方はいないでしょうか？

416 = :

>>415

runSlot(0); // runSlot の最初の引数 = 0 の状態で runSlot を実行しますよ～
runSlot(1); // runSlot の最初の引数 = 1 の状態で runSlot を実行しますよ～
runSlot(2); // runSlot の最初の引数 = 2 の状態で runSlot を実行しますよ～

function runSlot( n
/*
「runSlot の最初の引数」なんていちいち書くのはとても面倒だから
この関数の中ではそれを n という名前で呼ぶことにしますよ～
*/
){

}

ということが知りたかった？

418 = :

>>415

これを

function runSlot (n) {
　　document.getElementById("num"+n).innerHTML = Math.floor(Math.random() * 10);
　　timers[n] = setTimeout(function () {
　　　　runSlot(n);
　　}, 50);
}

こうしてしまったら

function runSlot (n) {
　　document.getElementById("num"+n).innerHTML = Math.floor(Math.random() * 10);
　　timers = setTimeout(function () {
　　　　runSlot(n);
　　}, 50);
}

区別できなくなっちゃうじゃん

419 :

>>410
いつものようにjQueryになおしてあげようと思ったけど、
単にそれだけではつまらないので、jQueryを使わずに書きなおしてあげたよ

http://jsbin.com/wajelale/3/edit

420 = :

>>419
循環参照してる

422 = :

すいません、自分で辿りつけた所の参照コードは下記のような物です

<script>
var kimonoAPI = "http://www.kimonolabs.com/api/XXXXXX?apikey=XXXXXX&callback=?";
$.getJSON(kimonoAPI,
{
// 全てが対象
},
function(data){
alert ( data.results.collection1 );
});
</script>

このテストコードを実行すると、「object Object」が戻り値として表示されます

他にも
alert ( data.name );
alert ( data.results );

等は参照出来るのですが、

alert ( data.results.collection1.TagetImage.src );

とするとUndefinedになってしまう...

423 = :

横から失礼
「バブリングするclickを3回も定義してる」の意味がわかりません
リスナー内で定義せず外で定義しておけってことですか？

424 = :

>>422
collection1は配列だから最初の要素を取り出すならこうなる
data.results.collection1[0].TagetImage.src

425 = :

>>423
バブリングするイベントは上位ノードでイベントを検知することが出来る。
>>419であれば、document.body 以上であればclickイベントを拾える。
http://www.tagindex.com/kakolog/q4bbs/1601/1871.html

426 = :

>>424

出来ました！！！ありがとうございます！！！

配列の基礎からじっくり学びたいと思いますが、
これで今まで手動でやってた更新が完全に自動化出来る喜びにふるえてます！

感謝感激です。424さんに明日良いことがありますように。

427 :

>>420-421
元々書いてあったところの指摘は
全部元の人に言ってくれよｗ

428 = 427 :

まあ一応指摘しておくか

>>421
> ・nums[0] == nums[1] を2回評価してる
この例の場合は、コードの量が少なすぎるので、2回評価する方法を1回で評価が終わる方法に変えても意味が無い。

意味が無いというのは、
・速度の点で意味が無い。誤差レベルでマイクロ秒単位の違いしか生まれない。書き方によっては遅くなる。
・コードの記述量の点で意味が無い。無駄か無駄でないかは、速度よりもこっちのほうが重要だが
この例の場合では、1回の評価で済む方法を使ったらコードの記述量が増える。
・複雑さの点で意味が無い。評価が1回ですませて、なおかつ速度が落ちない方法を書こうとすると
コードが複雑になる。記述量よりも重要な点。

よってこの程度で「2回の評価」を問題にして、書きなおすことは逆に多くの無駄を作ることになる。
評価の方法を1回で済む方法に変えました。でもその為の準備処理で遅くなったり、コードが複雑になりました。
じゃ、それこそ無駄だからね。わからなければ書いてみればわかると思うよ。

429 = :

便乗質問なんだけど
スロットが3個なら一個いっこみてけばいいけど
スロットがn個だった場合、m個合致しました
ってのはどうしたら良いのん？

431 = 427 :

>>429
いい指摘だね。>>419では（手間もコード量も大差ないから）
ボタンの数は変えやすいように書きなおしているが、
その点は一致した数の判定方法はそのまま残すという判断をした時に考えた。

まずどう書くかではなく「スロットがn個だった場合、m個合致しました 」
というのが間違いなんだ。

何が間違いかというと、4個だった場合[1][1][2][2]ということがあり得る。
この場合、「2個合致した」ではなく「2個合致したものが、2組ありました」となる。
つまり「n個だった場合、m個」という表現では足りないわけだよ。

そこはもう仕様の問題であり、それが決まらないのに4個以上に対応するのは無駄。
だから3個限定のコードのまま残した。3個限定であればあの書き方が一番
コード記述量が短くシンプルだろう。
なんでも重複を省いたり比較の回数を減らせばいいってもんじゃないんだよ。

ということで>429、どうしたら良いの？という問いに答えるには、
まずどうしたいの？という質問に答えてもらわないといけない。

まあ一番汎用的（どんな仕様にも耐えやすい）のは、ボタンの種類は有限だから
1がn個、2がm個・・・というハッシュをあらかじめ作っておくことかな。
それはボタンの数だけループしてその数を計上すればいい。

そうしておけば、仕様に最適化したコードにはならないが、そのあとの処理が楽になると思う。

434 = :

>>431
すまぬ。合致した組み合わせのうち最大の数を返せばいいと思ってた

> 1がn個、2がm個・・・というハッシュをあらかじめ作っておくことかな。
> それはボタンの数だけループしてその数を計上すればいい

これもなんとなくそうすればいいのかと思ってたけど
もっとスマートな方法があるのかにゃー、と聞いてみました

437 = :

>>428
どうして意味がないのさ
1回だけ評価するほうが論理的にわかりやすいと思うけどね
2回同じ評価をするほうがわかりづらい

438 = :

今はこれから更に改良されてて循環参照で特に気をつけなくてもいいと思うけど
http://steps.dodgson.org/b/2012/12/19/dom-and-gc-or-what-happend-at-eden/

439 = :

ID:N3YK+MBc が偉そうなのが癇に障るな
突っ込みどころは多々あるが、思い込みの激しい反論されるのは目に見えてるからどうしようもない

440 = :

>>430
バブリングだけの為になぜjQueryを使う必要があるの？
普通に書けばいいじゃない

441 = :

nodeListはindexOf使えないのか

442 = :

>>427
「修正してあげた」にしては未修正部分が多すぎるから指摘を受けるんじゃない？
君は他人を怒らせる書き方しかしてないから気をつけたほうがいいよ

443 = :

>>438
循環参照を避けるべき理由は実装がメモリリークのバグを生み出しやすいためといわれる
今はバグがないかもしれないが、将来的にバグが発生する可能性を踏まえるなら避けたほうがいい

444 = :

>>>430
全然複雑じゃないぞ
偉そうな割にはいうことがいちいち的外れすぎなんだが

document.addEventLIstener('click', function (event) {
　var target = event.target;
　
　if (target.className === 'stop') {
　　// 処理
　}
}, false);

445 = :

うん。
途中で止まるかもしれないし、
Nodeが開放されてもリスナが溶けないので絶対にやめた方がいいねそれ。
凝る割にメリットがあるのはごく一部のケースのときだけ。しかも今回ではない。
カッコつけないで素直が一番よ。

446 = :

>>445
> 途中で止まるかもしれないし、
止まる理由がないし、「止まるかもしれない」って止まる理由をお前は説明できるのか？

> Nodeが開放されてもリスナが溶けないので絶対にやめた方がいいねそれ。
unload 時に removeEventListner する処理を入れれば済む話だと思うが
ただ、グローバルコードには循環参照は発生しないはずなんだが

447 = :

自分の知らない書き方を「複雑」で「普通じゃない」として一蹴する人がいるようだけど、勉強の機会を逃していてとても勿体ないと思うのです

448 = :

>>425
ありがとう
前から点と線が繋がらない感覚だったけど理解できた気がする
event.currentTargetの使いかたがわかったよ

ところで
var trg = event.target;
if (trg === event.currentTarget) {
処理
}
というのと
var trg = event.currentTarget;
if (trg) {
処理
}
という風に書いてるのを見るんだけど違いってあるのかな

449 = :

オブジェクトがプロパティを持っていないときに
新たに値を指定してそのプロパティを持たせることを考えています

var obj = {key1:true , key2:false , key3:true}

obj.key4 || obj.key4 = true;
obj.key4 = obj.key4 || true;
obj.key4 ? null : obj.key4 = true;
のようにして存在しないプロパティなら意図通りにできるのですが
obj.key2 || obj.key2 = true;
のように既に存在していて値がfalseなプロパティも引っ掛かってしまいます

obj.key2 === undefined ? obj.key2 = true : null;
として今はやっているのですが、どう書くのがベストなんでしょうか

450 = :

>>432
HTMLを代入してるわけじゃないから、textContentが適切ってことでは

>>441
仕様上は可能だから、polyfillってことでprototype拡張しちゃっても問題ないと思う

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ

類似してるかもしれないスレッド

• + JavaScript の質問用スレッド vol.113 + (1001) - [100%] - 2014/1/25 12:46
• + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
• + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
• + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
• + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
• + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
• + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
• + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
• + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
• + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
• + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
• + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
• + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
• + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
• + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
• + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
• + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15