+ JavaScript の質問用スレッド vol.122 +©2ch.net

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
　1レスに収まらないならコード投稿サイトを利用してください。
　http://jsdo.it/　http://jsbin.com/　http://jsfiddle.net/　http://ideone.com/

■前スレ
+ JavaScript の質問用スレッド vol.121 +©2ch.net
http://peace.2ch.net/test/read.cgi/hp/1415213701/

■過去スレ全集
http://www2.atpages.jp/mirror/2ch/javascript/
http://usamimi.info/~mirrorhenkan/2ch/javascript/ (閲覧のみ)

■テンプレ案
http://fiddle.jshell.net/fH4cC/39/show/light/

■関連スレ
ECMAScript デス 4
http://peace.2ch.net/test/read.cgi/tech/1325448978/
JavaScript ライブラリ総合質問所 vol.4
http://peace.2ch.net/test/read.cgi/hp/1400834117/
Webサイト制作初心者用質問スレ part241
http://peace.2ch.net/test/read.cgi/hp/1408512894/
CSS初心者スレッド＝12th＝
http://peace.2ch.net/test/read.cgi/hp/1343429848/
Canvasについて語ろう
http://peace.2ch.net/test/read.cgi/hp/1305093769/

■主要FAQ (全部は http://fiddle.jshell.net/vSqKr/33/show/ )
Q1. 別窓・フレーム内容やローカルファイルを読み書きしたいのですが…
A1. 別サーバのページやファイルの内容はセキュリティ制約でアクセス不可です。
Q2. document.write()でページ内容を追加したいのですが…
A2. 一度表示完了後にwriteするとページ内容が消去されます。DOM等別手段を。
Q3. table内容のinnerHTMLやDOMでの変更がうまく行かないのですが…
A3. IEではtable/tbody/trのinnerHTML書き換え不可です。DOMを使いますが、
　　DOMの場合tableの直下にはtbody要素が(作らなくても)あることに注意。
Q4. フォーム部品名を変数にした「...myform.変数名.value」が動きません…
A4. 「document.forms.myform.elements[変数名].value」でどぞ。
　 JavaScriptでは一般に「obj.x」と「obj['x']」は同じ意味です。
　 グローバル変数はwindowのプロパティなので「x」と「window['x']」も。
Q5. CSSで設定した背景色がe.style.backgroundColorで取得できないのですが…
A5. 取得には document.defaultView.getComputedStyle() を使う必要あり。
　　IEでは要素オブジェクトのプロパティcurrentStyleを使う。
Q6. setAttribute("class","foo")、setAttribute("onclick","bar()")が動きません…
A6. IEではそれは不可。「obj.className="foo"」「obj.onclick=bar」でどぞ。
Q7. タイマーやイベントハンドラに設定するコードにthisを含めたいのですが
　　「"...this..."」とか「function(){...this...}」ではうまく行きません。
A7. 実行時にthisが別のものを指してしまってる。以下のようにthisを束縛保存。
　　「function(x){return function(){...x...};}(this)」
Q8. input type="file"の値を設定(参照)できないのですが…
A8. セキュリティ制約のため設定は絶対に不可。参照はブラウザにより不可。
Q9. getElementById('ID名')や$('ID名')で要素が取れないのですが…
A9. コード実行時点でHTMLがそこまで読まれてない。window.onload 中でやるとか。

■各種仕様 ( http://fiddle.jshell.net/vSqKr/33/show/#Link も参照 )
◆ Standard ECMA-262
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/ （ECMAScript 3 和訳）
http://www.ecma-international.org/ecma-262/5.1/ （ECMAScript 5.1 HTML版）
http://people.mozilla.org/~jorendorff/es6-draft.html （ECMAScript 6 有志HTML版）
http://kangax.github.io/es5-compat-table/ （ECMAScript 5 compatibility table）
http://kangax.github.io/es5-compat-table/es6/ （ECMAScript 6 compatibility table）
◆ HTML Standard (HTML5)
http://www.whatwg.org/specs/web-apps/current-work/multipage/
http://momdo.s35.xrea.com/web-html-test/spec/WD-html51-20130528/Overview.html （HTML5.1 部分訳）
http://www.hcn.zaq.ne.jp/___/WEB/WebStorage-ja.html （Web Storage 和訳）
◆ Document Object Model (DOM) / CSS Object Model (CSSOM)
http://www.hcn.zaq.ne.jp/___/WEB/DOM4-ja.html （DOM Standard (DOM4) 和訳）
http://www.w3.org/TR/DOM-Level-3-Events/ （DOM3 Events）
http://www.w3.org/TR/uievents/ （UI Events）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-ja.html （CSSOM 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-view-ja.html （CSSOM View Module 和訳）
◆ その他のWeb関連仕様
http://domparsing.spec.whatwg.org/ （DOM Parsing and Serialization - innerHTML等）
http://www.hcn.zaq.ne.jp/___/WEB/XHR-ja.html （XMLHttpRequest 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/File_API-ja.html （File API 和訳）
http://www.whatwg.org/specs/ （WHATWGの仕様一覧）
◆ MDN (Netscape/Mozilla)
https://developer.mozilla.org/ja/docs
◆ JavaScript Garden (ja)
http://bonsaiden.github.com/JavaScript-Garden/ja/
◆ JSON (JavaScript Object Notation)
http://www.json.org/json-ja.html
◆ MSDN Library
http://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://msdn.microsoft.com/ja-jp/library/cc427807.aspx (JScript)
http://msdn.microsoft.com/ja-jp/library/cc409712.aspx (DHTML)

■諸注意
vol.115でlodashを不必要に推奨して啓蒙する行為が多く確認されており、ライブラリ系の質問はvol.116から禁止されました。
vol.115,116ではライブラリ禁止する発言が見られた直後にライブラリを許可する意図で次スレを立てる行為が確認されています。
本スレッドでライブラリ許可を求める発言が確認された場合は不要な争いを避ける為、スルーすることを推奨します。
ライブラリの質問はライブラリスレへ誘導し、誘導行為への反論はスルーしてください。

こちらは重複です

+ JavaScript の質問用スレッド vol.122 +(c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1420095379/

>>1
乙です

jshintの仕様についてもライブラリの質問と同じじゃね

Math.random()って偏りがあるの？

もう一個のスレの人曰くないらしいけど

こっち？

+ JavaScript の質問用スレッド vol.121 +
http://peace.2ch.net/test/read.cgi/hp/1410603104/

そこはあきらめた模様

そっちで回答して誘導しようとして恥かいちゃったもんな

何でこんなに乱立してんだよ

テンプレが気に入らない荒らしがテンプレを外したスレ（>>6>>11）を立ててるだけ
いつも通りテンプレのあるとこだけ使ってれば無問題

今回から荒らしが建てたスレは使わないようにしたのか
板ルール的にはどうなんだろ

ム板のスレをシカトに関しては以前から

tableで枠線を普通の線にするにはどうすればいいですか

JSから変更する方法はいくつかあるけど
>>18が知りたいのはCSSだろうからそっちの質問スレで聞くといいよ

どっちが現行スレなんだよ！
荒らしがどうとか後からきた人にはわかんないんだし
あるスレを順番にうめてほしいわ

こんにちわ

tableとtdの背景色を変えることでなんとかなりました

table{
border-collapse:collapse;
}

>>20
>>15の言うとおり>>1にテンプレあるのが真っ当なスレ
こうなった経緯が知りたいなら昨年夏くらいからログ漁ってみ

もう年明けてるから一昨年の夏やな

質問です
ページA→www.hoge/a.html
ページB→www.hoge/b.html
ページAでローカルストレージやクッキーのようなページAとBで共有できるものを更新した瞬間
ページBでpushみたいな形で確認できるようにする方法ってありますか？

ありまーす

マジですか！
Javascriptの何を使えばいいんでしょうか
更新した瞬間関数実行とかもできますか？

StorageEventでググれ

>>29
ありがとうございます！
これですこれを求めてました！

CSSでのプロパティー名とjavascriptのプロパティー名の対応表ってどっかにありますでしょうか

>>31

var obj = document.createElement('div');
console.log(obj.style);

ハイフンでつながった単語はキャメルケースに置き換えて読めば対応表として読める

CSSでの名称からjavascriptでの名称はすぐ出ますでしょうか

>>32-33で充分じゃないならもっと質問を具体的に

CSSで、-(ハイフン)があればそれを削除して、
次の文字を大文字に変える

マウスの座標が左上から50px×50pxのエリアに入ると関数を実行するみたいなの作りたいんですが
50pxのdiv要素をfixedで左上に設置してそれにhoverしたらとやるしかないんでしょうか？
jQueryでもなんでもいいので

それでいいんじゃないの？

mousemoveで座標が一定範囲内なら実行

透過canvasからイベント

>>40
それdiv要素と変わりなくね

エフェクトをつけれる

documentにリスナを登録して、関数内でマウス座標を取得して判定すればいいのでは

mousemoveなんて膨大なイベントが発生するするし、debounceとかで制御すると厳密にエリア判定できなくなる
座標取得の必然性がなければ避けるべき

常に発生してるもんにフックつけてるんじゃね

要素作る→常に一番上にしなきゃなので邪魔
document.mousemove→重い

クリック判定のない要素が作れればmouseoverで一発なんだけどなぁ

mouseoverだけの為に特に無意味な要素をz-indexMAXでしかもfixedで表示しとくとか絶対に嫌だわ
visibility:hiddenでも邪魔すぎてドラッグとかコピペ動作がクソになる

>>31
http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties

クリック時じゃなくてマウスカーソルが乗った時に実行する処理ってどんなのだろう

そのエリアに名前が付けられるかどうかだな。
名前が付けられるなら見えない要素にするのがいいだろう。

そうすれば、$('.mienai-aria').on('mouseenter')で
そのエリアにマウスが入ってきたかどうか分かる。
（mouseoverは毎回イベントが走るので、mouseenterの方が良い）

そうすれば、50px×50pxにこだわることはなく、
そのエリアを広げたり、場所を変えたり、複数作成できたりできる。
左上にこだわることなく、そういうエリアとして考えることが出来るわけ。

いやでもz-indexの一番上の階層にその透明なだけの要素が表示されてるってもうそれバグみたいなものだろう
コピペガードみたいなもんじゃないか綺麗なやり方じゃない
絶対document.onmousemoveがいいって

divの要素の位置とサイズを取得して
setIntervalで100ぐらいでまわして座標がdivに重なってるか判定すればとけば別にそこまで重くない

>>52
透明だと考えるから理解できないんだよ。
そこが赤くて赤い所に乗せたら反応って考えればわかるだろ。

documentを使うと、上に何かが乗っててイベントを
キャンセルされる可能性があるから適切じゃない。

それを考えると、documentの上に透明なレイヤーを
画面全体に置くことも考えられるけどね。
それするぐらいなら透明な50px×50pxを置いたほうが軽くて済む

>>53
> setIntervalで100ぐらいでまわして座標がdivに重なってるか判定すればとけば別にそこまで重くない

$('.mienai-aria').on('mouseenter')の方が簡単。
無理に難しくすることもない

質問者がいないようだが、左上50x50に他の要素がない前提でいいのか？
透明の要素を設置すると、その下の文字が触れないぞ

addeventlistener(〜、〜、true)

透明要素ブラクラ

いいことおもいついた

scroll イベントハンドラをwindow にあてがっています。

このハンドラの中で
resize 操作に伴うリフローで生じた scroll イベントと、
resize なしの普通の scroll （スクロールバー操作その他）
で生じた scroll イベントとを区別する方法はないですか？

http://peace.2ch.net/test/read.cgi/hp/1410603104/471n- に纏わるハッシュ定義についての質問となります。
個人的には下記の理由でこのコードはハッシュではないと考えています。
- データから一定の手順でハッシュ値を生成していない
- 故に同じデータと関連付けられたら複数のハッシュ値を生成できる(衝突できる)
- ハッシュ値の並びに規則性がある
そもそも、16進数の数値添字配列がハッシュなら通常(10進数)の数値添字配列もハッシュに含まれますが、[1, 1, 2, 3] もハッシュなのでしょうか。

マルチ乙

>>60
resizeイベントで判定出来そうだと思ったけど、iOS Safari だとscrollしただけでresizeイベントが発生するとかあって難しいな

>>60
１．windowを最大化で開く
２．開いたウィンドウのサイズを取得
３．元のウィンドウのサイズをチェック
４．　２と３のサイズを比較して２が小さかったらresizeされている

あみだくじが確実に当たる驚異のアルゴリズム
http://jsdo.it/jagarikin/hKGF

>>62
何か誤解かあるようですが、私が質問したのはここが初めてです。
あちらのスレでは荒らしが酷くて質問する気になれませんでした。

Blade RushっぽいアクションJavaScriptで作ろうと思うんだけどああいうモーションの絵って何枚用意したらいいの？

歩く・走る・通常攻撃・ダメージを受ける・とりあえずこの四パターンで教えて

ごめんスレ間違えた

リフローで思い出したけどさ、リフローまたはリペイントを
強制的に発動させる標準的な方法ってないよね？

おそらくブラウザのバグで表示がおかくなることが有る。
フォーカスを変えたり開発者ツールで要素を参照するだけで
表示がなおる。

なので今は、なるべく軽そうなものとしてbodyのstyleのpositionに
positionの値を入れている（つまり何も変えていない）

sessionStorageのkeyに使える文字の一覧をおしえてください
w3cみたけどさっぱりわかりません

知らんけどエスケープとイコールカンマセミコロン使わなければだいたいおｋ

質問失礼。
出力ファイルの名称と拡張子を指定するにはどうすればいいでしょうか？
環境は、IE最新verです。
よろしくお願いします。

>>72
下げます

var x=5;
if(
x.match(/\d/)
)
{
alert("数字")
}

これだと動かないけど
var x="5";
にすると動きます

matchって数値の変数には対応してないんですか？

数値はmatch関数を持ってないからね
文字列.match()で動くのは文字列のプロパティにmatch関数があるから

0から9までの一桁の数字をランダムで5000くらい書いて
そのなかで同じ数字が5回以上連続してる部分を抜き出すようにしたいんですが
「同じ数字が5回以上連続してる」というのをどうやって書いたらいいでしょうか

forでMath.randomから文字列に5000回+=して正規表現かな

ひっかかる都度質問してたらプログラム完成しないよ？

>>76
00000+|11111+|...|99999+
かね

ループ中にカウントしていく

書いたけど出来なかったからやめた
var a = [];
var t;
var c = 0;
var d = 0;
var r;
for (var i=0; i<50; i++){
r = Math.floor(Math.random()*10);
if (r === t){
c++;
} else {
t = r;
if (c > 1){
d++;
c = 0;
}
}

a.push(r);
}
console.log(a.join(''));
console.log(d);

完成させればO(N)で済む

str.match( /(\d)\1{4}/g )

正規表現っての使ってやるのがミソなんですね
ありがとうございました

>>75
ネットで知識を付け足して行く学習方法の自分にはよくわからないけどありがとうございます

ちなみに>>74と>>76は別人です・・・

特定の文字のバックだけ色をつけるのはどうやるんですか

横並びdiv

spanかfontでよくね？

a = [1,2,3]
a = a.map(function(b){
return b * 2;
})
配列の値を二倍するコードですが、このmapの中で配列のインデックスにアクセスする方法ありませんか？

[1,2,3].map(function(value,index,array){
return value*2;
});

とりあえずMDN見る癖付けとくといいぞ

MDNってwww.mdn.co.jpですか？何処のページ見たらいいですか？

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/map

var a = {
b: 1,
c:2
}

この変数から値を削除したり代入したり追加したり出来ないようにする方法をおしえてください

以下のことも含めて全部できないようにしたい
a.d = 1;
a.b = 1;
delete a;
delete a.b;

>>93
IE9以上なら
Object.defineProperty(window, "a", {
value: { b:1, c:2 }
, enumerable: true
, configurable: false
, writable: false
});
Object.freeze(a);

configurable:falseとwritable:falseで、a = null や delete a での a 自体の変更を防ぐ
(初期値を明示しているだけなので省略してもいい)
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty

Object.freeze(a)で、a.d = 1 や a.b = 1 やdelete a.b での中身の追加・削除・変更を防ぐ
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

IE8対応でお願いします。

それは無理です

何をやりたいのかによるな。

単にプライベート変数を作りたいだけなら
普通にできるし。

データの編集などを行っていて、
ブラウザの戻るボタンが押された時に前のページの内容が変更前のデータのまま表示されてしまうので
戻るボタンが押されたら、前のページへ"進む"ようにしようと思いますが、
どのようにしたらいいでしょうか？
それとももっと最適な方法はありますか？

>>94
ありがとうございます。

>>98
history.js?

>>98
前提

まず正しいページの作り方の常識として

「戻る」と「進む」はブラウザのみが使って良い機能。
ウェブページには、戻ると進むというリンクは存在してはならない。
リンクは全て、どこかのページに移動するもの
（history.back()は単にブラウザの機能を呼び出しているだけ）

前提終了

で、ブラウザの戻るを押された時は戻ったのだから
前の情報が表示されて当然のはずだが？

その常識を変えてまで、戻った時に、違う内容を表示させたいのなら
そのページをキャッシュさせないように、適切なhttpヘッダをつければ良い。
毎回ページを読みに行くからレスポンスは悪くなるがね。

JavaScriptであれこれやろうとする話じゃない。

>>101
httpヘッダでは無理でした
前開いたページをそのまま表示してしまうので困っています
一度戻ってリロードを押せば、もちろん最新の情報になります
また、前のページへのリンクから辿ればこちらも最新の情報になります
つまり、戻るボタンを押して表示されるページはサーバーに問い合わせてレスポンスを参照するようにしたいです

> httpヘッダでは無理でした
使い方が間違ってるだけです。

どなたか別の方、解答をお願いします

何でそういうことがしたいのかを説明してもらわないと答えにくい
普通はそういうことはしないもんだが

無いよ。

>>104
ページをキャッシュさせたくない場合にどうするか？
という問題にたいして作られた機能が
キャッシュさせないためのヘッダなのだから
それ以外有るわけがない。

まあページごとにセッションを割り振って
setIntervalでセッションを監視して、セッションが異なってたら通信させるとかいろいろできるけどな

>>108
それだと一瞬前の画面が表示されるだろう。

Expires と Cache-Controlはどう設定したの？
キャッシュが無効ならonloadイベントが必ず発火すると俺も思うけど

なんでそこでonload？
キャッシュが無効なら必然的に新しいページを要求するわけで
正しくhttpヘッダを設定するだけで十分の話だろう。
JavaScript関係ないし。

xmlhttprequestの方もキャッシュされるから気をつけないとね

多分メモリたくさん積んでる人にはわかりませんがmeiq.vector.co.jpやっぱりここChromeで見ると重いんですが
重い原因がJavaScriptのどのコードが影響しているか調べる方法ありませんか？

正しくヘッダ設定するだけで終わりの話じゃん。
ぐだぐだいってないで、こいつにやらせろ。

>>112
?12345

>>115
間違い。

67890正解

お前馬鹿じゃないのか？

日本語でおｋ

ExpiresやCache-Controlでキャッシュさせないように設定しても
「ブラウザの戻るボタン」では前のページがそのまま表示されてしまいます
前のページへ戻るリンクなら最新のデータが表示されます

いろいろと調べてみたところ、
history.back()で戻れるのはわかりました。
ブラウザの戻るボタンのイベントを取ってこれを実行すれば良いのではと思いますが、
どうやればいいですか？

他にも、「前のページへ戻ったら強制reload()する」といった方法もありました
これはスマートじゃないと思うので、これ以外に方法があれば教えてください

[入力画面]---(A)-->[確認画面]

(A)でサーバー側に仮保存した入力データを入力画面のロード時に
復元したいという要望かと思っていたが違うの？

データをセットしてるのはどちら側？

>>118

>>108

>>118
だから何故そうしたいのか聞いてるんだけど

何かものすごい勘違いしてる気がする

>>118
> ExpiresやCache-Controlでキャッシュさせないように設定しても
> 「ブラウザの戻るボタン」では前のページがそのまま表示されてしまいます

だから、表示されないって言ってるだろ。
お前の使い方が間違ってんの。

人の話ちゃんと聞けよ。

ヘッダを正しく設定する。というスマートな方法が出てるのに
頑なにそれ以外の方法を探すのってなんでなんだろうね。

自分が間違っているって認めたくないから？

流れそうなのでお願いします

>>125
デベロッパーツール

>>119
すみません、違います
こういう状況です


[情報ページ]---(サーバーへ保存)--->[編集完了ページ]
データ A表示　　　データ B送信　　　　　　　　　|
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|---(リンクから元へ辿る)--->[情報ページ]
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|　　　　　　　　　　　　　　　　　　データ B表示
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|---(ブラウザ戻るボタン)--->[情報ページ]
　　　　　　　　　　　　　　　　　　　　　　　　　　　　|　　　　　　　　　　　　　　　　　　　データ A表示　　← 最新のBにしたい



質問を上手く伝えられず申し訳ないです

これもデベロッパーツールだね

キャッシュクリアした？
レスポンスヘッダの内容確認した？

>>127
それならヘッダでキャッシュさせないようにすればいいよ。

もちろんどのページでヘッダを出すかはわかってるよな？

答えてみて。

戻るを押した時に、キャッシュされたページがでるなら
明らかにキャッシュの問題なんだから、
（キャッシュ以外前の情報を持っているところがない）
キャッシュさせないようにすればいいだけじゃん。
JavaScript関係ないし。

違うところで質問します

>>131
違う所で同じ回答をします

勘違いしたまま逆切れしたみたいだな

荒らしだからもう構うな

デベロッパーツールでどうやって発見するのかおしえてください

chromeの開発ツールの場合

・件のページでデベロッパーツール開く
・Networkのところ開く、Disable cacheをオンに
・ページをリロード
・ロード完了を待ってTimeのところをクリックで降順に
・どこで時間が掛かってるかわかる

それはロード時間でJavaScriptの処理時間じゃねーから

んじゃその次にやるのはProfilesのところだな

化石スペックでIE9,Fx, Chromeで確認してみたがたしかにChromeだと重く感じる

デベロッパーツールにPageSpeedを組み込んで分析すると結構色々な所を指摘してくれる

あとはコンサルにでも頼んで

サイトもあるでよ
https://developers.google.com/speed/pagespeed/insights/?hl=ja

ここで指摘される事の多くはオライリーの
「ハイパフォーマンスWebサイト」「続ハイパフォーマンスWebサイト」
あたりを読めば解ると思う

ボトルネックがJavaScriptにあると思うなら
「ハイパフォーマンスJavaScript」とか読むといいかもね

上記の本に被る部分も多いけど

最近書き込みできない

alert出してる間はsetIntervalが止まるのは何故ですか？

alertがモーダルであり、１つのページにスレッドが１つしか割り当てられてないからかと

デバッグ目的ならalertよりもconsole.log使いましょう

confirmで処理を止めてyes noを聞けるのは便利

JavaScriptでalertやconfirmと同じ仕様の関数を作ることは出来ない。

○ か × か？

xhrとかonloadの同期みたいなこと？

>>146
jQueryUIのダイアログみたいな擬似的なものは出来ても厳密なのは無理かもね

△

全く同じ仕様にできるのは絶滅寸前のshowModalDialogくらいじゃね
仕様は全然違うが HTML5.1のdialog要素は今後使えそう

ES6のmoduleって名前空間と何か違うんですか？
ES4の名前空間は二度と考慮しないって言うのはどうなるんですか？

画像のアドレスを<img src="アドレス">にしたいのですが、どうやっても1番最初のアドレスしか取得できません。
全部の置換のしかた教えてください。
<tr>
<td class="img">http://aaa.jpg</td>
</tr>
<tr>
<td class="img">http://xyz.jpg</td>
</tr>
<tr>
<td class="img">http://h0y.jpg</td>
</tr>

>>146
×
そもそも、同じ仕様なら alert, confirm を使えばいいだけ
使えないというなら同じ仕様にした時点で使えなくなるからこの質問が無意味
人を試す質問は止めてくれないものかね

>>151
肝心のjavascriptのコードが無いんじゃ何も言えないと思うけど･･･
全部他の人にやってもらうつもり？

>>151
こういうことか？

$('.img').html(function() {
return $('<img>', {src: $(this).text()});
});

80文字超えなかったから、一行でいいか。

$('.img').html(function() { return $('<img>', {src: $(this).text()}); });

>>152
> そもそも、同じ仕様なら alert, confirm を使えばいいだけ

alert, confirm は見た目がダサい。
だから同じ関数の仕様でデザインが違う関数を作りたい。

それは可能か？ 不可能か？

>>149に挙がってるけどwindow.showModalDialog使えばいける

jQueryって無断で使っていいほど知名度高いのか？
今や、クロスブラウザやコード短縮のために使用推奨、みたいな風潮だったりするの？？？

>>157
Chromeなどブラウザによっては使えないのとFirefoxでも若干の差異があったりする

>>158
> jQueryって無断で使っていいほど知名度高いのか？
高い。わかり易い例で言えばマイクロソフトが公式サポートとして
Visual Studioにバンドルされており、ASP.NETを使うと必然的にjQueryを使うことになる。
マイクロソフトは自社で開発を進めていた ASP.NET Ajax Library を中止してjQueryに置き換えた

DOM APIを使うぐらいならjQueryを使った方がいい。
一番の理由はコードが短くなって生産性が上がるから

今は昔と違ってブラウザ間の互換性は高くなっているが、
もちろんクロスブラウザ対応ももちろんある

最新版ではSafari 8, 7.1 のquerySelectorのバグに対応したね。少なくなったとはいえ皆無ではない。
http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/

jQueryを使わない選択肢があるとしたら、
AngularJSのようなDOM操作そのものが
不要なフレームワークを使っている場合のみ

クロスブラウザのためのコードは
jQuery 2.1.3のソースコードから"Support:"と
書いてある所を検索すればわかる。

かなりある。IEだけではなくiOSやAndroid、
はてはBlackBerryまである。

もしjQueryを使わないならば、
特定のブラウザだけでなぜか動かないということに
なりえるわけで。

っていうかjavascriptの仕様にjQueryを取り込むべきだと思うけど。

>>156
だから不可能だといってるだろう？
そもそも、デザインが違うなら厳密には同じ仕様とはいえない
何の仕様が同じかをいえばもっと早くに違った回答を期待出来たかもしれない
初めから目的を明らかにして欲しいものだ

>>163
あなた以外の人には、ちゃんと話が通じているけどねｗ

いや、俺も単なる興味で書いたのなら不毛だなと思った

こうかもしれない、ああかもしれないと無駄に考えさせるのは悪い質問
面倒くさいから口に出さないだけで「無駄な質問するな」と思ってる人はいるだろうな

>>151
- querySelectorAll
- getElementsByTagName, className or classList

>>158
jQueryを啓蒙しようとしている人が必死になってjQueryコードを書いてるだけ
反応すれば荒れるから無視するが吉
ここはライブラリ質問禁止だから、まともな人はライブラリの回答をしない

今更啓蒙とか

啓蒙するならES6にして欲しい

>>167
そうそう。だまって無視していて。
いちいち絡んでこなくていいよ。

俺はjQueryを使ったシンプルな回答を見せてるだけ。
文句言われるために書き込んでないから。

>>151
querySelectorAll は IE8以上
classList はIE10以上、Safari 5以上、Android 3以上だから気をつけて

jQueryならIE6以上から対応している

>>162
> っていうかjavascriptの仕様にjQueryを取り込むべきだと思うけど。

いくつかの仕様はjQueryから来たと思われる。
例えばquerySelectorAllなんてのは、まんま$(セレクタ)だし
classListのメソッドもjQueryのaddClass、removeClass、toggleClass、hasClass
相当のメソッドが定義されている。

HTMLで作ったサイト上で、テキストファイルを読み込んで
javascriptでその中身を編集するところまではできているのですが
その加工済みのファイルの中身をサイトに組み込む(鯖のファイルを編集する)
ことはできないでしょうか？

>>171
getElementsByTagName, className で問題ない

>>171
jQuery の場合、jQuery 2.x は IE8- をサポートしない
IE6+ に対応するなら jQuery 1.x を使うしかない

classlistって IE8+ 対応だったと記憶していたけど、調べたら IE10+ だった
Polyfill 書けば IE8+ 対応になるからいいけど
http://caniuse.com/#feat=classlist
https://developer.mozilla.org/en-US/docs/Web/API/Element.classList

Polyfull書くとIE8になるっていうのは具体的にどういうふうに書くのかおしえてください

>>173
HTML上ではできないね
鯖側で編集したファイルを受け取る仕組みが必要だよ

>>177
IE8 には DOM Interface Object の Element が存在するので Element.prototype.classList を拡張する
アルゴリズムは DOM Standard (HTML Living Standard派生)
の仕様書に載っているので参考に
https://dom.spec.whatwg.org/#interface-domtokenlist

IE8 から Object.defineProperty を使用出来るので protype 汚染を気にせず多くの拡張が出来る
Array#foEach等の ES5 定義のメソッドもPolyfillを書けばほとんとが利用出来るだろう

>>173
サーバのファイルはサーバサイドでしか編集出来ない
サーバサイドスクリプトでファイルを受け取り、受け取ったデータに書き換える仕組みが必要

>>175
> jQuery の場合、jQuery 2.x は IE8- をサポートしない
> IE6+ に対応するなら jQuery 1.x を使うしかない

うん。そのとおりだけど、最新版の2系が使えないのかーって
悲観する必要はない。

なぜなら、2.xと1.xのAPIは完全に同じ。
全く同じ機能が使える。

1.x系はもう更新しないで2.xのみに新機能を搭載して徐々にAPIが
変わっていく予定でこういうバージョンにしたのだろうと思うけど、
たぶんそこまでする理由もなくて考えなおしたんじゃないかな。

なので、次のメジャーバージョンはモダンブラウザのみ対応の3.0と
古いブラウザも対応する3.0 Compatになる。

今後しばらくはIE8以上でも、IE6以上でも同じ機能が使えると思っていいだろう。

>>174
classNameだとクラス名がスペース区切りで複数入っている場合を考慮すると
正しく扱うために追加のコードが必要になるね。

MDNにshimがあったけど、IE7以下では動かないって書いてある。
https://developer.mozilla.org/ja/docs/DOM/element.classList

>>179
> Array#foEach等の ES5 定義のメソッドもPolyfillを書けばほとんとが利用出来るだろう

有名所のPolyfillはこれかな。
https://github.com/es-shims/es5-shim

こういうのはすでに用意されているものだから
ライブラリを読み込むだけでES5のメソッドを追加してくれる。
わざわざ独自に書く必要はないよ。

ただね。これ検討したんだけどリンク先にも書いてあるとおり
Object.createとか完全に同じ動作を実現できないものもある。

だから本当に古いブラウザでも同じように動くのか？って考えると不安が残る。
なので結局古いブラウザに対応する必要があるときはlodashを使うことにした。
https://lodash.com/

古いブラウザで実現不可能なことは、lodashに実装されてないので
lodashを使う限り同じ動作であることが期待できる。
それにlodashの方がES5よりも機能多いしね。

古いブラウザ対応が必要 = PC（スマホではない）なので、lodashを読み込んでも
重くなったりする可能性は低い。スマホ専用とかならもちろん普通にES5を使っているよ。

なるほど、そういう考えでライブラリを使うのもありだな

>>182
> classNameだとクラス名がスペース区切りで複数入っている場合を考慮すると
> 正しく扱うために追加のコードが必要になるね。
クラス名の両端にスペースを付与するだけで良い
昔からこの手法はよく使われたものだが、最近の若い人は知らないのだろうか

if ((' ' + element.className + ' ').indexOf(' img ') !== -1) {
// 処理
}

>>181
jQuery だけバージョン間の差異に触れず、ブラウザのバージョン差異問題だけに触れていて、恣意的にjQueryを持ち上げているように見えたから
何も知らない質問者がjQuery 2.xを使う可能性もあるのだから、そこまでいうならjQueryのバージョンにも触れるべき
jQueryのpluginには特定のバージョンで動かないものもある
1.xと2.xは区別されるべき

最後に対象ブラウザを決めるのは質問者
事実だけを伝えて恣意的なお勧めは控えるべきだと思うね

>>183
> Object.createとか完全に同じ動作を実現できないものもある。
自分て書くからこそ「どこまで対応出来て、どこまで対応不可能か」が正確に把握できる
そして、バグは他人の書いたコードよりも自分の書いたコードの方が明らかに早く見つけられる

> だから本当に古いブラウザでも同じように動くのか？って考えると不安が残る。
それは仕様を実装する段階で把握しておくべきことだ
ES5仕様をES3仕様の範囲内で実装しようとすれば、その段階でES3仕様の限界に気がつくはずだ
後は各ブラウザの仕様書からES3仕様との差異を突き詰めれは良い
特にIEに関しては多くの仕様がMSDNに載っている

>>183
> Object.createとか完全に同じ動作を実現できないものもある
古いブラウザを気にするということは lodash.compat.js の方だよね
Lo-Dash 2.4.1 (Custom Build) も Object.create を内部的に利用してるよ
今時のライブラリで ES5 の Polyfill を書かないものはほとんどない

結局、それがブラウザ間の互換性を取れているかどうか、は「コードを読む力」「仕様を読む力」にかかっている
どのライブラリを使うかはたいした問題じゃない
そのライブラリのコードを読んで、理解できるか、できないかだよ

「クロスブラウザはライブラリに任せるから考える必要はない」と考える人は「ライブラリに使われている人」
ES, DOM 等の標準仕様を理解し、ブラウザの仕様を理解し、ライブラリのコードを読んでライブラリの使用を理解し、「ライブラリを使いこなせる人」になるのが一番いいと思うな
そこまでいくと、ライブラリを使わなくてもクロスブラウザ出来るようになる
ライブラリを使う事も使わない事も出来るから、様々なコードを書けるようになるだろうね

function a(){
略
b()
略
}

function b(){
略
a()
略
}

function c(){
a();
}

c()からa()を呼ぶんですが、条件によってはa()からb()を呼び、b()からa()を呼ぶこともあります
こういうケースだとjshintで
'b' was used before it was defined.って警告が出るんでこういう警告がでないような書き方にしたいんですがアドバイスください

var Class1 = function Class1(){
}
Class1.prototype.setName = function(name){
this.name = name;
}
Class1.prototype.getName = function(){
return this.name;
}
こうかくとnew Class1を変数に代入する毎にsetNameとgetNameも作られると思うのでメモリの無駄のような気がするんですが
こういものですか？

>>190
setName, getName は new 演算子で呼び出される度に生成されないが、nameプロパティは外部から参照可能なので両メソッドが無駄
プロトタイプチェーンを勉強すればわかると思う

違うインスタンスでも同じ関数を参照していることは、以下のコードからも分かる
参考までに
var a = new Class1;
var b = new Class1;
console.log( a.setName === b.setName );

>>189
> 'b' was used before it was defined.って警告が出るんでこういう警告がでないような書き方にしたいんですがアドバイスください
掲示された下記コードを http://jshint.com/ でテストしたが、現象を再現できない(error, warningが発生しない)

function a () { b(); }
function b () { a(); }
function c () { a(); }

「略」とあるが、このコードで再現確認してないだろう？
質問前に>>1の(6)を読んで欲しい

これはlatedefが trueがじゃいと警告でないです

>>193
jshint導入してないのかよ

>>187
> 自分て書くからこそ「どこまで対応出来て、どこまで対応不可能か」が正確に把握できる

え？ あんた一人で開発してるの？

自分で書くことが出来るのは、書いた人が開発して
それ以外の人がいない場合しかありえないけど。

書いた人以外の人の多くの人は他人が書いたコードを使うわけで、
それが社内の人か、全世界で使われている有名な人かの違いでしょう？
なら後者を取るよね。

>>186
> jQueryのpluginには特定のバージョンで動かないものもある
> 1.xと2.xは区別されるべき

なんかグダグダ言ってるんだけど、
2.xで動かなければ、1.xに変えるだけで
終わりだよね。

>>189

おそらく、以下の様な形にできる。

function x1() {}
function x2() {}

function a(){
略
x1()
略
}

function b(){
略
x2()
略
}

function c(){
a();
}

循環した参照は普通やらないものだし、やるべきではないもの（だからこそ警告が出てる）
だけど具体的なコードがないからわからないから答えようがない。

もっとも本当にそうすべき（循環参照すべき）問題もわずかにはある。
本当にそうするべき問題ならコードのほうを歪ませるほうがよくない。
だから警告を無視させればよい。jshintにはそのための機能がある。
こんなの　/*jshint -エラー番号 */

>>188
> 「クロスブラウザはライブラリに任せるから考える必要はない」と考える人は「ライブラリに使われている人」

「クロスブラウザはライブラリに任せるから考える必要はない」と考えなければいい。

クロスブラウザを考える必要はあるが、ライブラリでやれることは
ライブラリに任せる。と考えればいい。

出来のいい執事みたいなものだよ。

自分でやるべきことは、本質的な所。
そして誰がやっても同じ結果になるところは他人に任せる。
任せるのであって、考えていないわけじゃない。
考えた上で、任せて十分だと思うから任せる。

世界中で使われてるライブラリと、自分が作ったり自社で作ったりしたもの。
どちらが任せて十分だと思えるか？ 当然前者だよね。

でも自分で考えてないわけじゃないよ。考えた上での結論。

そりゃ、時間が無限にあるのなら、全部自分でやるがね？

仕事全般に言えることでもあるけどね。
自分一人で仕事を抱え込まない。
他人にやらせられる所は他人にやらせる。

そうしないと生産性は上がらないから。
一人で全部やると時間はいくらあっても足りない。

おや？ なんで>>199はIDがついたのだろう？

たった今からsageをメール欄に入れていてもIDがつくようになったんだと思って
消したら>>200はつかなかった。

この板でもID強制になって欲しいんだけどね。
そうすれば嵐とかわかりやすいのに。

なお、この書き込みは連続書き込み過ぎだと言われたので
自分でIDを変えました。

addEventListerでclickイベントが設定されているか確認する方法ってありませんか？

コンソールであれば getEventListeners() を使えばいいけど、そうでないなら不可能

var A = (function(){
function A(age){
this.age = age;
}
A.prototype.getAge = function(){
return this.age;
}
return A;
})();

var a = new A(10);
console.log(a.age);

10って表示されます。
ageをprivateにしたいのでa.ageで取得したりa.age=2で再代入させたくないのですがどうやればいいかおしえてください

残念ながらjavascriptにprivateはありません

検索すればクロージャでそれっぽいものが出来るといった解説も見つかるかもしれませんが
面倒なだけなんでしなくていいでしょう

this.__ageのように直接参照すると気持ち悪いコードになるよう仕向ける事である程度
防止にはなるでしょう

Pythonなども似たような事情なんでLL言語はそういうものだと思ってください

>>204
function A (age) {
this.getAge = function () { return age; };
}

>>150
は質問のしかたが悪いのか
ES6に興味のある人がいないのかどっちですかね

>>207
質問の仕方が悪いんじゃない？
ESに名前空間なんて概念はないし

privateにすると、それを参照するメソッドをprototypeに記述できなくなるんだよな
悩みどころ。

privateにする場合の書き方を教えt

何でprivateにするとprototypeだめなの！？
なんでsageなのにぼくのIDでてるの！？

>>211
>>206

>>206のは引数をそのまま返してるのでprivateでも何でもない気がしますが

>>208
そんな気はしていました
後の人のために調べたことを書いておくと
ecmascript4ではnamespaceが提案されましたがecmascript4ごとなかったことになりました
とはいえグローバル汚染を回避するハックやライブラリが必要とされ作られたのでecmascript6でmoduleという機能が言語自体に備わるようです
namespaceと同じくグローバル汚染を回避するためにありますが必要となる関数だけをimport,exportする方式ですのでnamespaceとは違う代物のようです

スコープチェーンやプロトタイプチェーンの話はわかりにくいよね

>>213
クロージャでprivateになってることに気が付いてない？
ちなみに private property はない

Chromeで使うJavascript構文のブックマークレットで、
何か音を出すことってできませんでしょうか？(beep音とかでいいのですが)
今はAlertを表示してるところを、もっと簡単に音を出すだけにしたいんですが…

あと、そのブックマークレットから外部プログラムにデータを渡す方法って無いでしょうか？
クリップボードに吐き出したりは今はできないんですよね
そのようなことができると、自分のスキル内でもいろいろ応用ができるのですが…
(音を出す、ということも可能になる)

プログラミングに関して初心者に毛が生えたレベルなので、的外れな事書いてるかもですがご容赦下さい

音を出すにはたったこれだけ
new Audio(音のURL).play();

ＦＭ音源で波を重ねてた頃の苦労はどこへ行ってしまったのだろうか？

ジジイは音を出すのにも苦労していたのかよｗｗｗ
能力低いんじゃね？ｗｗｗ

>>220
意味が分からずに煽っても恥かしいだけだぞ

>>221
俺らは、たったnew Audio(音のURL).play(); これだけで音を鳴らす。

ジジイは、正弦波がーとか矩形波がーとか意味不明なことを言って
鳴らすだけで四苦八苦

能力の違いだなｗｗｗ

>>222
> ジジイは、正弦波がーとか矩形波がーとか意味不明なことを言って
だから意味が分からずに煽っても恥かしいだけだぞ

>>222
お前には↓この言葉を捧げよう
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

>>223
分かってるが？
なんでわかってないと思ったんだｗｗｗ

ああ、やっぱり分かってないんだ

さすがにコレは見苦しい

>>219は Audio API がなかった頃の話では？
>>222は「意味不明」といっているわけで、理解不能を自認してる

>>228
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

>ＦＭ音源で波を重ねてた頃

ここに刻み込まれた意味を今の若者は正しく読み取ることはできないだろう

ん？ ピアノの鍵盤を叩いて
音楽を演奏するみたいなことだろ？
鍵盤のキーに音が一つ一つあって
それを合わせるだけ

ピアノの鍵盤をたたいた時に発生する波の形を計算で作るんだよ。
だから合成音。サンプリングじゃない。

ＦＭ音源で波を重ね　だと厳密には

×計算から正弦波にFM変調をかける
○用意したFM音源を加算合成する

になるね

Web Audio API使えば音楽ファイル無しでも音だせるね

http://webaudioplayground.appspot.com/
http://www.peko-step.com/tool/soundeffect/

むしろ一昔前は<bgsound>要素で音楽ファイルから再生してたよな

>>229
>>222に笑う要素が一つもないけど、とこがネタなの？

お前が笑われてる

>>236
ネタバレすると
わかっている人がわかってない人のふりをして
書き込んでいることに、
君が気づいていないから笑われている。
本当に知らない人はああいうレスをしない。

テンプレートで
<% %>
の間に記述されたJavaScriptコードが実行されるっていうやつがありますが
なんで実行されるんですか？

>>238
陰湿な人だね
そういう後ろ暗い感情は理解出来なくていいや

ES6ではプライベート変数を作ることはできる？

あとさES6の各ブラウザの対応状況って何処で見れるか教えて

>>242
http://www.bing.com/

>>242
>>4

>>241
ES6のClassでってこと？それなら不可能
でも"private"自体はstrict modeで予約後だから、将来実装されるかもね。
なんちゃってprivateは>>206を参照

chromeの右上になんか名前が出るようになりました
これ何ですか？

もはやJavaScript関係ねえ・・・

>>218
音を出すことができました！
ありがとうございました〜

よくbindするといいますが、
具体的にどういう処理をbindと言っているのですか？

>>249
bindは束縛の意しかないので文脈によって変わる

var a = 100;

これはaに100をbindしていますか？

それは代入っていうんじゃないのかね、きみ

綺麗なお姉さまにbindしてほしい・・・

そう、代入と大差ない気がするんですよ
どのへんがバインドになってるのか良く分かりません

たとえばFunction.prototype.bind()はthisに相当するオブジェクトを指定できますが
これって代入と同じですよね？
何がbindぞ

100というNumber型オブジェクトと変数aをバインドしてると言えなくも無いけど
一般的には代入だあな

var a = 100;
var b = a;
console.log(a === b); //true
a = null;
console.log(b); //100

thisという特別な変数にオブジェクトを代入するので、
その特別感をbindという変わった表現で表しているということでしょうか

オブジェクトとオブジェクトを関連付けする、という意味合いを強調するために
よく使われる気がするね

たとえばイベントソースとイベントハンドラのバインド、とか

http://e-words.jp/w/E38390E382A4E383B3E38389.html

>>255
デフォルトのthis値を上書きして束縛するからbind
Function#bind の前では addEventListener も new 演算子も無意味

bindってcallの発火前の関数が帰ってくるバージョンみたいなもん？

単に関数呼び出しする時、thisになるものを
.の左のオブジェクトじゃなくて
明示的に指定するだけ。

thisになるものを指定して呼び出すだけと思えば良い。

>>261
func.call( obj , arg1 , arg2 ); // objをthisとしてfunc実行しちゃう
func.bind( obj , arg1 , arg2 ); // objをthisとしたfunc帰ってくる

てことだよね？
apply版はないのか…

>>259
試せば分かるけど、Function#bindはnew演算子のthisはbindしないよ
ただし引数は固定できる

メソッド名がbindなのにbindしないって意味わからん
しないわけないだろ

>>263
申し訳ない
確かに new 演算子による呼び出しでは bind されなかった

function Hoge () { console.log(this.value); }
var Hoge2 = Hoge.bind({value: 'Hello, World!'});
Hoge2(); // Hello, World!
new Hoge2(); // undefined

そういうことか
newにbindするなんて発想がなかった

>>262
func.bind.apply

遉ｾ蜀?逕ｨ邂｡逅?繧ｵ繧､繝医〒MOUSEMOVE縺ｮ險倬鹸繧偵い繧ｯ繧ｻ繧ｹ繝ｭ繧ｰ縺ｫ譖ｸ縺榊刈縺医※髢ｲ隕ｧ閠?繧呈耳螳壹＠縺滉ｺ九?ｯ縺ゅｋ縲?
JS遲峨′蠕玲э縺ｧ縺ｪ縺?髢ｲ隕ｧ閠?縺ｯ蜈ｨ縺乗ｰ嶺ｻ倥°縺ｪ縺?縲?
隱､隱咲┌縺励?ｮ100%蠖薙◆縺｣縺溘?ｮ縺ｧ諠?豕∬ｨｼ諡�莉･荳翫?ｮ諠?豕∬ｨｼ諡�縺ｫ縺ｪ縺｣縺溘�?

中国人か

MV*
の読み方を教えて下さい
エムブイアスタリスク
なのか
エムブイ
なのか

>>270
スレ違いです

確かModel-View-Whateverだけど
エムブイアスタでいい気がする

気になるなら講演会の動画とか見てネイティブの発音確認してみれば？

>>271
MV*はJavaScript特有なのでスレ違いではありませんが？
>>272
ありがとうございます
動画で確かめてみようと思います

>>273
AngularJS開発者が提唱するデザインパターンの一種でしょ
JavaScriptは本質的に無関係

>>273
ttps://www.youtube.com/watch?v=KKb9Qhlnemo

これ見てみたけど早口で聞き取れない・・・
アステリスクと略さず発音してる気がする

>>274
angularに限らずJavaScriptのフレームワークはMV*にならざるを得ないのです
当然ながらJavaScriptと本質的に関係があります
>>275
俺も動画を見てみましたが聴き取れませんでした
http://stackoverflow.com/questions/13329485/mvw-what-does-it-stand-for
MVW / MV* - Model-View-Whatever
とあるのでwhateverで良さそうです

>>276
デザインパターンなんだから AngularJS を使わなくても MV* を採用できるでしょ
MV*は AngularJS 専用ってわけじゃあない

> angularに限らずJavaScriptのフレームワークはMV*にならざるを得ないのです

違う。そもそもMV*はSmalltalkの頃に作られたもので、
主にGUIを作るときに使われるパターン。

JavaScript = フロントエンド
つまり多くはDOMを操作するのに使われるわけで、
DOM、すなわちGUIだからフロントエンドJavaScriptは
規模が大きくなってくるとMV*を導入するという話になるだけ。

もちろん規模が大きなGUIを作るならば
どの言語であってもMV*がでてくる。

規模が小さいならば、jQueryだけでも十分だけど、
jQueryは単にDOMの操作を楽にしてくれるだけで
ブラウザに搭載されているDOM APIと変わらない。

規模が大きいGUIをもっと効率よく作ろうとしたら
MV*のいずれかを使うことになる。

MV*というのは、アスタリスク＝何にでも当てはまるという意味で
MVC、MVVM、MVP、Model-View-Whateverの総称

MV* = Model-View-Whatever ではない

>>279
MVWのWは一つとは限らないんじゃないの？
stackoverflowの書き方だとMV*=MVWという意味にしか読めないが？

>>278
違わないじゃん
JavaScriptで作るものがGUIなんだから当然MV*になる
しょうもない屁理屈を抜かすな

>>277
俺に言われても知らんがな

モデルとビューと、あと何か

>>281
> JavaScriptで作るものがGUIなんだから

その前提が間違いなんだから。
結論も間違いなんだよ。

>>280
> stackoverflowの書き方だとMV*=MVWという意味にしか読めないが？

stackoverflowってアメリカの2ちゃんねるよ？
素人の一意見でしか無い。
それが正しいという保障もない

まあ、StackOverflowはだいたい正しいよね。なんでかしらないけど荒れることも少ないし。
「自分は英語がわからないから、そこに書いてあることは2ch並みに信用ならん」みたいな人もいないし。

>>282
あなたが言い出したことでしょ
自分の発言に責任を持ちなさい

自分は英語がわかるから、そこに書いてあることは2ch並みに信用ならん

hoge.html
hoge/a.html
hoge/b.html
の三つをブラウザで開いてて
hoge.htmlのスクリプトでa.htmlとb.htmlに｢この関数実行しろ｣って命令する事できますか？

>>289
a.htmlとb.htmlがhoge.htmlに開かれたのであれば

>>289
shared worker

shared worker はIEとSafariとスマホ版ブラウザが全滅か

一番は>>290
それ以外の「条件だとローカルストレージの更新を利用する手もある

lodash 3.0 リリース間近！

https://github.com/lodash/lodash
3.0-preから-preが外れました！


スレが多すぎてどこに書けばいいかわからないので
関連スレすべてにマルチポストしています。m(__)m

>>294
テンプレも読まない、無知を装った宣伝お疲れ様

>>295
宣伝したのは本当ですが、スレが多いのは事実ではないでしょうか？
みんながどこを見ているのかわからないので、
気づいてもらえるように、マナー違反だとは思いながらも宣伝しました！

>>295
忘れていました。

お気遣いありがとうございますm(__)m

>>296
> 宣伝したのは本当ですが、スレが多いのは事実ではないでしょうか？
それは宣伝する言い訳にならない

> 気づいてもらえるように、マナー違反だとは思いながらも宣伝しました！
つまり、マナーよりも自己都合を優先した故意犯でしょ
自覚症状があるんだから性質が悪い

いろんな質問スレにマルチポストしているようだが、質問スレで宣伝NGなことは考えればすぐわかる
「スレが多すぎてどこに書けばいいかわからない」が真っ赤な嘘である事は明確だな

>>298
> それは宣伝する言い訳にならない

いいわけじゃないです。
何も言い訳してませんよ。

私は悪いことをしました。
わかっていて宣伝しました。

>>294
> スレが多すぎてどこに書けばいいかわからないので
わからなかったら普通は事前調査するよな
例えば、「何のスマートフォンを買っていいか分からないから全機種買いました」なんて富裕層でなければしない
分からないんじゃなくて何も調べていないだけだろ
>>299も合わせると「何も考えず、何も調べない」
最低だな

>>301
いいえ。調べた上で全部に書いちゃえと
思ったので書きました。

>>302
> いいえ。調べた上で全部に書いちゃえと思ったので書きました。
だから>>294の「スレが多すぎてどこに書けばいいかわからない」は嘘だろ
分かった上で書いたんだろ
日本語を読めないのか？

クソレスが多いな
気に入らなかったら何か言うんじゃなくて黙ってろ
クソレスなんて百害あって一利なしなんだから

とりあえず、2箇所では反応あったみたいだね

宣伝って、何か利益になるの？

知らんけど単に「へー、そうなんだ」って思っておけばいいだろ
ボケが

悪意よりも、歪んだ正義感の方が、より厄介だ。

https://twitter.com/kai_ri_no/status/558449951332519936/photo/1
通信はajaxなんだけど、
HTTP応答のイベントがあったら呼び出される関数は、ここに追加するの？

lodash使おうと思ったけどキモいのでやめました

>>309
Twitter APIを使うのが一般的だけど、サイト解析して独自実装するの？
サイトの仕様が変わる度に解析して追従するのはどう考えても現実的ではないし、俺は仕様が変わる度に動かなくなるプログラムを使いたいとは思わないけど
ちなみにJavaScriptからTwitter APIを使うと API Key, API Secret ガ駄々漏れだから誰も使わない
あと、マルチポスト四過ぎで気持ち悪い、マルチポスト先ぐらい書きなよ
http://syncer.jp/twitter-api-create-application
http://syncer.jp/twitter-api-blocks-create
http://syncer.jp/twitter-api-blocks-destroy

>>310
lodashを使いなさい

> (9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。

ライブラリ関連は禁止　というよりは
どっかの誰かが個人的に作った関数の仕様の話題はスレチ　が正しいかな

ライブラリ禁止はlodash厨が登場してから

backbone使いはじめたから個人的にはlodashへのこだわりはあまりない
アンスコとの互換性が重要なので

backboneには、lodashの元になった
underscoreが入っていたんだったね。

underscoreをより良くしたのがlodash。
早く3.0正式リリースしないかな。

サイトに表示されているのがv2.4.1だから
正式リリースはまだだと思っている。

　　　　　 , -,＿＿＿＿
　　 /ﾚ／;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;｀'-,__
　i!､i;;;;;;; ;;; ;; ;;; ;; ;; ;;;;; ;; ;; ;;; ;;;;;;､
　>;;;;;;;;;;;;;;; ;;; ;;; ;; ;; ;;;;; ;;; ;;; ;;;;;;;;;
／〉,､;;/ / ! ￣￣￣￣`ヽ !;;;;;;;;;;i
　/( !;;| ノ=-　　　 -=＝＼|;;;;;;;;;;;l
　　　`! ,.--、　　　 ,---、 },;;;__;;;!
　　　 ,i.i ●_i　　　 !_● _!　ﾘ',　i|　　　　＿＿＿＿＿＿＿＿＿＿＿
　　　 .l| ￣ ノ　　　　￣　 　 i　l!　　　／
　　　　!　　l,_　　　　　　　　,__/! 　　＜　でもライブラリ禁止する人も悪いんですよ
　　　　i　　 ======　　　 /〉;;/　　 　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　ヽ　　　　　　　　／ ﾙi!､
　　　　／/`ー───'　.／/lllll＼
　＿／llllll!､　　　　　　／　/|||||||||
'||||||||||||||l　＼_ /ニ￣　 ./|||||||||||
||||||||||||||||i, く;;;;;;;;;;|＼　./|||||||||||||
|||||||||||||||||!　〉;;;;;;/　 ｰ/||||||||||||||

俺もlodash好きだから、株を落とすようなことはしないでくれよな

backboneとかangulerjsとかのフレームワークスレたてていい？

いいんじゃね？ 使ってる人いないから
全然レス無いと思うけど。

は？俺は使ってるが？使ってない奴レベル低すぎワロタw

>>320
立てるときにスペル間違えるなよ

>>322
それって「使ってる俺はレベルが高い」と言っているようにみえるね。
実際は、使う使わないは、選択するかどうかの違いであって、
レベルとは無関係なんだが。

まあそういう所がお前のレベルの低さを感じるね。

>>324
レベルひっくww

こんな過疎板で個別スレあまり需要なさそう・・・

詳しい人はム板に集まる傾向あるけどWeb系はこっちに池って言われるから
ここしかないんだろうけど

>>325
言っていることの意味がわからなかったのかな？
使えるのは当たり前って話をしているんだよ。
使えるのは当たり前だが、意味が無いから使わないって話をしてる。

３つ立ってるｗｗｗ

立てました。

テンプレ適当すぎｗｗｗ

これで誰も使ってないことが明らかになるだろう。
盛り上げるために、使ってる人がTIPSでも書き込めや。
そうすりゃそのスレにも存在価値が生まれるだろうさ。

このスレから信者が消えて、信者はあっちのスレで自分の空間に閉じこもる
WinWinだな！

自称レベルの高い人が立てたにしては丸投げ感が酷い
結局は他人頼みか

>>311
ローカルファイルをブラウザで見ててコンシューマーキーやアプリケーションキーがなぜ漏れるの？

なお書くのは個別スレでもいいしこのスレでもいいです
このスレは何でもいいスレなので

>>311
> >>309
> Twitter APIを使うのが一般的だけど、サイト解析して独自実装するの？
ＲＥＳＴ ＡＰＩを用いる。ＨＴＭＬ分析はしない。
https://dev.twitter.com/rest/public
を使ってることが画像の中のＵＲＬにも書いてると思う。

全て見たら分かるように質問してるのにねぇ・・。

>>311
> >>309
> ちなみにJavaScriptからTwitter APIを使うと API Key, API Secret ガ駄々漏れだから誰も使わない

サーバーに置くのではなく、file://　をブラウザで見る。 API Key, API Secreがどのように誰に漏れるの？

>>311
このＵＲＬで使う。E:\だったりするけど、なにかが誰かに漏れるの？

>>338
> >>311
> このＵＲＬで使う。E:\だったりするけど、なにかが誰かに漏れるの？
https://twitter.com/kai_ri_no/status/554013377450631168/photo/1

backbone専用スレが立ってたわ

【JavaScript】backbone専用スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1422023660/

backboneを使っているハイレベルプログラマーよ、集え

あれ先に誰かが立ててくれたようだ

>>335
>>5

>>342
それはスレをたてた奴が勝手に決めたこと。

>>343
そのテンプレは以前からあったもの
守らなくてもいいし、何を話してもいいと思うのはあなたの個人的な考えにすぎない

>>344
以前からっていつから？
最初にはなかったよ。

ES5ってほとんどメジャーな環境では動作するのでそろそろ使っても問題ないんですね

http://kangax.github.io/compat-table/es5/のparseInt() ignores leading zerosってなんですか？

Object.createでwritableとかreadableとかvalueとかconfigurableっていうプロパティ一覧ってmsdnとmdnのどこのページに載ってますか？

>>346
以前は parseInt("011") は8進数とみなして 9 を返すことがあった
ES5に従えば、10進数とみなして 11 を返す必要がある
それに対応しているかどうかじゃないかな

あとオブジェクトを作成する時はObject.createとObject.definePropertiesはどっち使っても同じですか？

>>348
なるほど、そういうことだったんですね

>>346
メジャーな環境じゃわからん。
IE9以上って言えばいいじゃないか。

ちなみにうちの会社（中小企業向けウェブサービス）には
ついこの間IE8で対応していない機能に対して
動かないんですけどっていう電話が来たよ。
XPを使っているらしい。XPはIE8までしかアップデート出来ない

> ignores leading zerosってなんですか？
かつては、0100は8進数で、10進数になおすと64だったのです。

ES5の機能を使いたいならlodashを使ったほうがいいよ。

スマホ専用とか、古いブラウザを本当に切り捨てていいならば、
ES5を使えばいいが、切り捨てたくない場合は大変だろ。

lodashなら確実にIE6でも動くことが保証されているし、
本当にやりたい事は何だい？ ES5を使うことではなくて
動くアプリを使うことでしょ？

ES5よりもlodashの方がはるかに機能が多いしね。

× 動くアプリを使うことでしょ？
○ 動くアプリを作ることでしょ？

あれなんですよ、JavaScript自体を学びたい年頃でして。
言語を知ってからlodashも検討します

学びたいなら、そろそろ使っても問題ないか？
なんて考える必要ないじゃないか？

俺だって、アロー関数が使えない時期から
アロー関数を学んでいたぞ。

もちろんユーザーが使用しているブラウザのことを考えて
今も実務ではアロー関数は使わないが。

>>345
vol.116辺りからってテンプレ見れば分かるでしょ？

> vol.116辺りからってテンプレ見れば分かるでしょ？

つい最近じゃねーかｗ
そんなの前からとは言わない

しかも所々、元に戻ってるし。
元々にテンプレに戻せよ。

しゃーねーな。

じゃあ次は俺が元のテンプレに戻しておくよ。

アロー関数とジェネレータを早く使いたくてウズウズしちゃう

>>357
変えた理由を読んでからものをいえ
前々のテンプレから変更出来ないなら一生テンプレなんて変えられないだろうが

JavaScriptの下らねぇ質問はID出して書き込みやがれ vol.123

>>360
変えるなって意見も多かったが？
一部の強行派が勝手に変えただけ。

テンプレが嫌ですスレが別になかったっけ

>>363
それ、ココｗ

>>362
それはlodash信者でしょ
君はlodash信者が書き込みしていいと思うわけだね

>>364
ここはテンプレが違う
テンプレ自由型は下記スレ

+ JavaScript の質問用スレッド vol.122 + [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1418395948/
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1422084185/

>>365
> 君はlodash信者が書き込みしていいと思うわけだね

禁止したって書き込むじゃないか？

一部の信者のために、その他の人の書き込みを禁止するほうが
悪いことだよ。

テロに屈したのと一緒だしｗ

うわまたフライングで立ててやがる

一般のライブラリ質問も増えてきたし、住み分けするのはいいことだと思うがね
ライブラリ許容派は荒らしが勝手にスレを建ててくれるから>>366に行けばいいだろう

>>367
書き込むのは荒らしだけ
おまえのやってるのは荒らしを受け入れているに等しい
そんなに嫌なら>>366へ行け

>>370
ライブラリに関する質問をするのは嵐じゃないだろ。

ライブラリの質問だけでなく、普通の質問にもライブラリを絡めて回答しようとするからな
厄介だ

ライブラリの質問をここでやってもいいとは思うけどそのためにはテンプレを作るべきである
ライブラリやバージョン名を書かないで質問して、あとからそれを指摘されて無駄にスレを消費するのが目に見えている

とはいえ、ライブラリの話題は専用スレに分けたほうが読みやすいというのもある

vol.115ではlodashの話題ばかりで他の質問が流される問題があった
ライブラリの質問量が多いなら分化するのは自然な対策

これ前の荒らしと同じやつだろ
少し前にもjQueryでlodashの頃と同じ荒らしと自演質問やってたし

>>371
何でもかんでもライブラリを勧める奴(信者)は荒らし
そういう奴を締め出すのが目的だったはず

お前らが必死に守ろうとしてるのは何なのだ？ｗ

勧める奴とか認識が甘すぎる
lodash啓蒙活動と称してここで質問と解答を自分で繰り返して
食いついてきたレスがあればひたすら煽って荒らしてたんだよ
後は御存知の通りスレ立てまくったりライブラリスレも荒らしたり

んで前からテンプレ作ってた人が避難先に建てたのがプログラム板のスレ
一方で荒らしがスレを乱立してもガン無視して進行するようにしたのがこのスレ

vol.123は荒らし以外の何者でもないな…

ム板は板トップでJS禁止にしてるのに避難先ってのもどうなんだろうね

自分が知らないことの話題に我慢できない幼稚な奴が何人かいるだけのこと

backbone.jsのソースコードにこんなコードがありました

this._events = void 0;

void 0ってどういう意味ですか？
こういうコードははじめて見ました

iavascript void でググレば出てくるのに何で質問するの？

>>383
undefinedと書く代わりだよ。
今はundefinedとそのまま書いたほうがわかりやすいわけだけど
（void 0だと分かりにくいからそのような質問が出るわけで）

古いブラウザだとundefinedはただの変数で
中身を書き換えられる可能性があるからといって
用心のためにそうかくバッドノウハウが普及した。
backboneの場合は単にタイプ数を減らすためだけかもしれないけどね。

今はundefinedは書き換えできないし、
そもそもundefinedを書き換えるようなコードは
jshintで検出するべきことだから普通にundefinedを使って良い。

汎用的なライブラリを作る時は用心のために
やるのもありだけど

メモを兼ねているので。
2chに書いておけば「この疑問は以前質問したような？」という記憶のインデックスになるのです

>>385
undefined問題に対する解決だったんですね
なかなかいい解決法だと思うので真似しようと思います
ありがとうございました

lodash厨は荒らし。
なぜ、lodashなのか？よくわからん

Underscore.js ならわかるけど。
作者は、CoffeeScriptも作った、Jeremy Ashkenas

Underscore.jsよりもlodashの方が
互換性あって機能が上だからじゃないですかね。

underscoreの作者がbackboneを作ったんだよね
coffee scriptも作ったのか
すげー優秀なんだな

それぐらいなら俺でもできるけど？

お前が作れるのはuncoとbakaboneだろプゲラ

あっちこっちに手を出して、宣伝しまくってるけど、全然普及しないゴミソフト作っている人か・・・
哀れだね。

lodashがスレに湧いてきた時期をTwitterで検索すりゃあ誰だか特定できそうだな

>>394
無関係のやつを巻き込むのはやめろよ？
俺はTwitterではlodashの話なんかしてないからな。
Twitterでは

たぶんライブラリの話題を出したいだけでそれが何なのかはそいつはなんだもいいんだとおも

どんな発想だよw
現実を捏造しすぎ
お前が思いたいものが現実じゃねーんだよ
お前絶対ネトウヨだろ

>>5にも書いてあるけどlodash啓蒙荒らしはスルーが一番マシ
煽り合いを楽しむような相手に何を言っても無駄だ

質問が気に入らないなら黙っとけって何回も言ってるんだが
幼稚な連中はそれが出来ないんだよな

質問はどうでもいいんだが、ライブラリを使った回答の方は迷惑かな
せめて、使ってない回答が出てからにしなさいよ

迷惑かどうかは質問者が決めればいい
第三者が迷惑がる意味が分からんわw

でも、質問者から良い反応返ってきた?

触んじゃね

>>402
はい。返って来ましたよ。
ライブラリを使う方法があることに気づいていない人が
多いですからね。目からうろこって感じなのでしょう。

>>402
当たり障りのない答えを返すか、スルーしてるか、とちらかしか見たことないなあ

>>401
第三者的には他の質問、回答が流れるのが嫌
例のライブラリ推しの人は無駄に長くて内容がない意見をだらだらと続ける
まあ、無視以外に対策はないんだが

やめろと言われると意固地になってかえって…ってのはわからんでもない

そもそも回答でライブラリ押しなんて見たことないんだが

>>154とか>>160とか

前スレだと
http://peace.2ch.net/test/read.cgi/hp/1415213701/53-56
http://peace.2ch.net/test/read.cgi/hp/1415213701/434-442
http://peace.2ch.net/test/read.cgi/hp/1415213701/552-555
いずれも質問者からはあまり良い反応を得られていない

カードを、Shuffleしたい時に、ただその1つの関数のために、
わざわざ、Underscore.jsをロードするのも、考えものだなあ

そうかと言って、自分で作れば、バグが出るし、
ライブラリからその関数だけをコピペするのも、
ライブラリが修正された時に、困りそうだし

それは別にライブラリ押しとは思わないな
色んな回答の中にライブラリを使ってるものがあってもいいじゃん
どれを参考にするかは自由だし
むしろライブラリの話を絶対するなと言わんがごとき連中の方が理解できん

一部のライブラリ狂信者のおかげで、ライブラリの回答自体が印象が悪くなっている感はあるな
ライブラリに任せる方が適切な場合も多々あるのは事実

ここ最近は必要ないのにライブラリのコートを紹介しているようにしか見えないからなあ

>>411
> そうかと言って、自分で作れば、バグが出るし、
自分のコートでバグがでるのは自分の能力が足りないのが原因だろう
もっと、たくさんのコートを自分で書いて能力を磨けば良い

> ライブラリからその関数だけをコピペするのも、
> ライブラリが修正された時に、困りそうだし
コードの内容を理解せずにコピペするからそうなる
そもそも、ライセンスを確認してる？

能力を磨くために書くのと、
ライブラリを使うのは目的が違うからなぁ。

能力が高くても、ライブラリを使うのは、
知識を共有できるから。

例えば入社してきたばかりの人でもjQueryを知っているなら
jQueryを使ってコードを書ける。

jQueryと同等のものを自分で作ってライブラリにしたとして、
入社してきた人が、その独自のライブラリを知っているわけがない。

ここですでに開発工数に差が生まれるんだよね。

>>411
> カードを、Shuffleしたい時に、ただその1つの関数のために、
> わざわざ、Underscore.jsをロードするのも、考えものだなあ

カードをシャッフルするだけのプログラムは書かないからね。
たいていはいろんな処理をするわけで、Underscore、lodashを使う機会は多くなる。

ここで小さなサンプルで、ただ一つの関数の話しかしてないからといって
それはたかがサンプルにすぎない。最小限のコードにすぎないので、
”たかが一つ” だとどうして勘違いした？ と言われるだけなわけで。

でも質問者が何のライブラリを使ってるかなんて、回答する側には分からないよね

>>416
バグかでるかでないかの話をしているのにどこから開発工数が出てくるのか
バグが生まれるのは自己責任
やり方の問題ではなく、>>411に問題がある

>>418
そりゃ、ライブラリの存在自体を知らないかもしれないからね。
だから、その状態で冗長なコードを書いている時、
こういうライブラリが有るよって教えてあげると
そんなの短く書くことが出来るのか！って勉強になる。

だからライブラリを使っていなくても、ライブラリを使った回答には意味がある。
もちろん、知っているけどライブラリを使わないで書きたいと言えば
話は別だよ。

>>419
ライブラリを使ったほうがバグが減るよね。
そのライブラリのコードを見ると、時々特定のブラウザ向けの
ワークララウンドが書かれていることがある。

そういうのは特定のブラウザで実行してみないとわからないので
見逃しやすい。問題が有るのは古いIEだけじゃないし。
新しいSafariのみで問題が起きる場合などもある。

>>421
ライブラリを使うことでバグは減らないし、>411の問題からかけ離れてる

> ライブラリを使うことでバグは減らないし

減るかどうかは時間次第。

同じ時間であれば、十分にテストされた
ライブラリを使ったほうがバグは減る。

lodash 3.0 ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

>>423
ライブラリを使おうが時間は変わらない

>>424みたいなlodashのマルチポスト宣伝してるのって、同一人物だよな？
何人もいたらそれはそれで恐ろしいが

lodash3.0が来たんだな、って思っておけばいいだろ
いちいち文句言う奴が一番うざい

そりゃ質問スレで宣伝は場違いだから不快に思われるのは仕方ない

荒らしに餌やんのもやめようぜ

lodashの何が優れてるのかが理解できない
別に使わなくても一緒だし

lodashはunderscoreよりも速いというのがウリ

使う必要性が皆無

しらんがなww
お前は使わなきゃいいだろ
お前が使わなくても世界中で使われてるし誰も困らねーよ

losashはie6以上で動いて、EcmaScript5、6の多くの機能と
それ以上の豊富な、メソッドが嬉しいね

lodash3はレガシーブラウザ切り捨てたんじゃないの？

>>435
最初はそういうロードマップだったんだけど、
途中から変えたみたいね。レガシーブラウザも対応してる。

前は2.5.0とかあったんだけど、wikiの歴史書き換えられてるみたいで
ここぐらいしか痕跡見つからなかった。
https://github.com/lodash/lodash/blob/653aee8b073755682ed7fcefc804c9192e7ed8ea/README.md

https://github.com/lodash/lodash/wiki/Roadmap/_history
22 May 2012 からいきなり、Initial Commitというメッセージで
24 days agoに飛んでる。

そうなんだ
じゃあ気にせずunderscoreの代替にも使えそうだね
ありがとう

<script>
$(document).ready(function(){
$(':text[name="fuga"]').each(function(){
$(window).load(hoge(this));
$(this).bind('keyup', hoge(this));
});

function hoge(elm){
var v, old = elm.value;
return function(){
if(old != (v=elm.value)){
old = v;
str = $(this).val();
$(':text[name="peke"]').val(str);
}
}
}
});
</script>

<input type="text" name="fuga" value="さいたま">
<input type="text" name="peke" value="">

現在、上記の状態です。
「fuga」にはページの読み込み時から「さいたま」が入っていますが、「fuga」に入っておらず、
「fuga」に何か文字を打ち込んだ時（キーボードを上げた時）に初めて「peke」に反映されます。
最初から「fuga」に入ってる文字を「peke」に反映させるにはどのようにしたらよいでしょう？

>>438
無駄にループしてるよに見えるけど、fugaとpekeはそれぞれ1個ずつしか無いの？

動かしてないけど俺ならこう書くかな。
ただこれだと要素が複数あった時に対応できないんだけどね。

<script>
$(function() {
　　$(window).on('load', function() {
　　　　$(':text[name="fuga"]').data('oldValue', function() {
　　　　　　return $(this).val();
　　　　}).triggerHandler('keyup');
　　});

　　$(':text[name="fuga"]').on('keyup', function() {
　　　　var oldValue = $(this).data('oldValue');
　　　　var value = $(this).val();
　　　　if (oldValue !== value)) {
　　　　　　$(':text[name="peke"]').val(value);
　　　　　　$(this).data('oldValue', value);
　　　　}
　　}
});
</script>

よく考えたら、最初の初期値代入要らないか

<script>
$(function() {
　　$(window).on('load', function() {
　　　　$(':text[name="fuga"]').triggerHandler('keyup');
　　});

　　$(':text[name="fuga"]').on('keyup', function() {
　　　　var oldValue = $(this).data('oldValue');
　　　　var value = $(this).val();
　　　　if (oldValue !== value)) {
　　　　　　$(':text[name="peke"]').val(value);
　　　　　　$(this).data('oldValue', value);
　　　　}
　　}
});
</script>

いやいやonloadも要らない気がするｗ

<script>
$(function() {
　　$(':text[name="fuga"]').on('keyup', function() {
　　　　var oldValue = $(this).data('oldValue');
　　　　var value = $(this).val();
　　　　if (oldValue !== value)) {
　　　　　　$(':text[name="peke"]').val(value);
　　　　　　$(this).data('oldValue', value);
　　　　}
　　}).triggerHandler('keyup');
});
</script>

keyup とか hoge の役割が不明だが、値をコピーするならこれでOK
$(document).ready(function(){
$(':text[name="peke"]')[0].value = $(':text[name="fuga"]')[0].value;
});

これでいけました
ありがとうございます

<script>
$(document).ready(function(){
$(':text[name="peke"]')[0].value = $(':text[name="fuga"]')[0].value;
$(':text[name="fuga"]').change(function () {
var str = "";
str = $(this).val();
$(':text[name="peke"]').val(str);
}).change();
});
</script>

<input type="text" name="fuga" value="さいたま">
<input type="text" name="peke" value="">

ド素人ですみません。

<INPUT TYPE="TEXT" NAME="hoge">
<INPUT TYPE="SUBMIT" VALUE="送信">

上記のフォームがあるのですが、「送信」ボタンをマウスオーバーした際にhogeに「メール送信します」の文字列を表示したいのですが、
jqueryでやるにはどうしたらよいでしょうか？
Jqueryのバージョンはv1.8.2です。

オブジェクトの一覧のようなものを見る方法ってありますか？

デバガ

>>445
わざわざマウスオーバーしないと何を送信するのかわからないようなデザインなら、はじめから「メール送信」と書いておけ。

それでも質問のやり方にこだわるなら、ちょっと前の質問の on('keyup'..の要領で onmouseover ってのがあるから、それを真似ればよし。

>>444
changeはフォーカスが外れないと変わらないはずだが、
まあそれでいいならそれでいいけどね。

>>444
> $(':text[name="peke"]')[0].value = $(':text[name="fuga"]')[0].value;
[0]に限定している意味があるのかしら無いが普通はこう書くよ。

$(':text[name="peke"]').val($(':text[name="fuga"]').val());

jQueryでは、要素を一個一個処理するという考え方はしない。
セレクタに一致する0個以上の要素に対して処理するという考え方をする。

> var str = "";
> str = $(this).val();

あとこれはやめた方がいい。
変数の中身はなるべく書き換えないようするのが今のトレンド
一旦""を代入する意味もないし、このように書いたほうが良い。

var str = $(this).val();

>>450

$(':text[name="fuga"]').val()

これって fuga にマッチする要素が複数あった場合って何が返ってくるの？
複数なくても $(':text[name="fuga"]') 自体が中身が一個の配列だから、その配列に対し .val() を呼べるの？
peke と fuga の数が違う場合はどうなるの？とか。

質問ばっかで申し訳ないけど。

指定した要素に対してイベントリスナを登録できないようにする方法を教えてください

要素を削除する

そんな方法あるわけないやん

大きな画像を小さめに表示すると、
IEでジャギーが発生するのですが
対策はどうすればよいですか？

IEを使わない
線形補間してcanvasでも使う

画像に以下のスタイルを指定すればおk
-ms-interpolation-mode: bicubic;

つまりインターバルで定期的に要素を削除して作りなおせばいいってことですか？
たとえばadblockの拡張機能を入れてるとページが表示されないサイトがあるじゃないですか
そういうサイトで目隠ししている要素を削除しても何度も目隠しが復活するので、イベントリスナを規制しているものだと思いました

>>450
var str = "";
str = $(this).val();

こうやって初期値に、空文字列を入れておけば、
if "" == str でチェックできるが、


var str = $(this).val();
この書き方だと、チェックする書き方に困る？

>>451
> これって fuga にマッチする要素が複数あった場合って何が返ってくるの？
取得するときは最初に見つかったものが返ってくると
ドキュメントにちゃんと書いてあるよ。だから[0]と一緒

ただし見つからない場合は、undefinedが返ってくる。
それに対して[0]だとエラーが発生する。

また$(':text[name="peke"]').val(1);の場合はセレクタに一致するもの全てに
値が入るのは当然のことセレクタに一致するものがなくてもエラーにはならない。
つまり、if ($(':text[name="peke"]').length) $(':text[name="peke"]').val(1);
みたいな存在チェックをしなくて良いわけ

本来あるべきものが無いのに、実行してもエラーにならないとは何事だ。
という考え方も無いわけじゃないんだけど、jQueryの場合は0個以上の
要素に適用するという考え方をすることによって条件分岐が少ない
シンプルなコードをかけるようになっている。

>>459
> var str = "";
> str = $(this).val();
>
> こうやって初期値に、空文字列を入れておけば、
> if "" == str でチェックできるが、

ん？ 1行目で代入した"" はその次の行で完全に置き換わるじゃん。
strに最初どんな値を言えれていたとしてもそれは完全に捨てられるから
何を入れても意味はなくなくなる。

>>459
空の場合にval()が何を返すか調べとかないとダメ

>>460
丁寧にありがとうございます！

荒らしが居ないと良スレになるなｗ

呼び寄せるなよw

正直いつもの湧いてから自分でライブラリ使った質問するパターンそっくりだったから
変な書き方してるコード見るまで警戒したわ

俺は今回と同様にいつもライブラリを使った回答を
しているだけなんだが。

で、lodashだけどバグが見つかってるから、すぐに3.0.1がでそうだね。
https://github.com/lodash/lodash/issues/890
今回はメジャーアップデートだから、俺的には想定内

>>468
さすがに質問スレと無関係な告知だ
調子に乗るなよ

調子には載っていない。平常運転である

>>468
そうなんだ

ライブラリの質問だけでなく、ライブラリの話題全般を禁止にすべきなんじゃないか

ライブラリ持ち出す前からスレに居座って荒らしてたんだから焼け石に水だよ
スルーしかない

>>472
情報を得て得することはありこそすれ損することはないのに何故かこんな頓珍漢なことを言い出す人間がいる
お前みたいな奴が一番不必要

Ajaxで取得した画像情報をbase64に変換して
Imgタグのソースに埋め込みたいんですが
うまく表示できません
こういうのってAjaxでは不可能なんでしょうか？

window.btoa() を使えば行けた気がする
無理ならサーバー側で base64 に変換することやね

>>474
lodashくんはスレを乱立させてJavaScriptスレをカオスにさせているという重罪があるから

荒らしに触るやつも似たようなもんだぞ

>>473
荒らしに対しては無駄だろうが、荒らし以外で意思統一ぐらいはしていいと思うんだが
ここを見る人にある程度の案内はしておかないと実際に質問する人が困るだろう

そんな無意味な意思統一いらねーから
ライブラリの話を除外する必要もない

荒らしを除外すれば、そこそこ平和に話し合いが出来るものなんだな

このスレは、ライブラリ禁止にすべきだ。
唯一の純粋JSスレで、まともな人限定

そして事情を知らない人には、その都度説明する

すべきだっつーか元からそうだし
普通の質問者だったら誘導するなりすればいいだけだよ

ライブラリの話をするなと数人のキチガイが喚いてるだけだから気にしなくていい
ライブラリの話ももちろんウェルカム

この荒らしは深夜帯は常駐してるから話し合うなら昼間が妥当だろうな

何を話し合うんだよ
キチガイ会議わろた

ライブラリ禁止の流れで安心した

このスレでlodash宣伝してる奴がうざい
リアルで使ってる奴見つけたらぶん殴ってやるわ

私のことを嫌いになっても、lodashのことを嫌いにならないでください！

>>489
ぶん殴っていいですか？

>>490
これがネットでよかったなｗ
本当にぶん殴ったらお前は傷害罪で捕まるところだ。

わざわざ教えてくれてるのに叩いてる奴あほじゃないのか
「その情報が誰かにとって役に立つか立たないか」を問題にしろ
お前にとって役に立たなくても他人にとって役に立つならその書き込みには価値があるんだよ
簡単なことだから理解しろ

持ち上げてるようで悪い印象しか与えてない気がするがｗ

try~catch~finallyってありますが、finallyって使う意味あるのでしょうか？
catchの下に続けて書くのと何か違いますか？

>>494
finally 節は return や break で後述処理をスキップしても必ず実行する

(function () {
try {
throw new Error;
return;
} finally {
console.log('finally'); // 実行される
}

console.log('end'); // 実行されない
})();

>>495
何とそんな違いが…！
ありがとうございます！

昔読んだ本にscriptタグはheadに書けと書かれていた気がするのですが
今読んでる本ではbodyの中に書いています
常識が変わったのでしょうか？

キチンと理由があります、調べましょう。

ブラウザで対応してないapiを使う時どっちの書き方がいいですか
if ("a" in window) {alert("未対応");}
と
if (!"a" in window) {alert("未対応"):}

もしくはこれこれ以外で良い方法を教えてください

>>497
うん。かわった。
今は　</body>の直前に入れるのが多い。

実行タイミングの問題だよなｗ

<head>
</head>

<body>
</body>

<foot>
</foot>

↑これを作るべきだった

>>499
状況に応じて typeof 演算子と Object.prototype.hasOwnProperty を使い分けてください。

> if (!"a" in window) {alert("未対応"):}
これは false in window と同義であり、期待通りに動作しません。

追記。
それがオブジェクトであるならば、Object.prototype.toString.call で [[Class]] 判定する事も検討して下さい。
それが配列であるならば、Array.isArray を使用して下さい。
それが関数であるならば、それ自身を call する事によって関数以外で TypeError の例外を返すことを検討して下さい。

>>497
script要素の読み込み中はDOM構築が停止する為、DOM構築速度を上げる為にscript要素をbody直前に持って行く事があります。
勿論、head要素までの読み込みで実行可能なタイミングであればhead要素内で完結すべきですが。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0006

例外として script[defer], script[async] を使用すれば、head要素内にscript要素を置いてもDOM構築を妨げません。
これらは対応ブラウザの制限がある為、対象ブラウザを踏まえて使用を検討する必要があります。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0008
http://caniuse.com/#feat=script-defer
http://caniuse.com/#feat=script-async

ありがとうございました
headに書いたものはbodyより前に読み込まれるので
bodyを表示してから実行したいものはbodyの後ろに書け、ということのようですね
するとheadに書けでもbodyに書けでもなく、必要に応じて分けて書けが正解でしょうか？

>>505
見逃していました
詳しくありがとうございます

>>506

<bod>の前でも後ろでもなくて、
</body>の直前な。

<body> 〜ながい本文〜 <script></script></body> こうな。

</body>の後ろにはscript書けねーから

タグの話のどこがJavaScript？
関係ない話をするなら別スレに行けよ

ネタで言ってるんだよな？

>>510
ECMAScriptの仕様書のどこに
タグのことが書いてある？

このスレで質問していいのは
ECMAScriptの仕様書の範囲内だけだ

ネタで言ってるんだよな？

勝手に決めるな

>>511
ここはJavaScriptスレ
ESの話題に限定したいなら>>2のECMAScriptスレに行ったら？

>>511
さすがにうざすぎる
お前が失せろ

Web制作板で何を言ってるんだって感じだな。

lodash 3.0.1リリースされたね

ES6 の Map って便利だね
Iterator の仕様が難読だけど、どこかに日本語資料ってないのかな

>>518
自分で実装すればいいだけなんだから
そんなのいらんだろ。

lodashを使えばいいだけじゃね？

lodashってes6のMapもあったのか
優秀だな

>>519
実装するためにはES6の仕様書を読む必要がある
今、読んでいるけど英語が不得手で解読に時間がかかってる

ECMAScript6に対応してないブラウザ向けに
Mapを提供するライブラリっていくつか有るみたいだけど
どれが一番優秀？
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#ecmascript-6-harmony

>>520
lodash-3.0.1.js を読んでみたけど、ES6 の Map の Polyfill コードは見つからなかった
_.map() もドキュメントを読む限りでは、それではないように見えるけど該当コードはどこ？
一応、いっておくけど欲しいのは「仕様」だから「仕様書通りの互換コード」でないと意味がないよ
https://lodash.com/docs#map

>>523
ありがとう
"es6-shim by Paul Miller" は比較的、仕様書通りの実装だったから参考にしてたけど、他は知らなかった
コードの優劣は>>4の仕様書とコードを見比べるといいと思うよ

<iframe id="fm"></iframe>

<script type="text/javascript">
var str = '<html><head><style type="text/css">*{color:red;}</style></head><body>あばば</body></html>';
var doc = DOMパーサ(str);
var fm = document.querySelector("#fm").contentDocument;
// ?
</script>

こんな感じの疑似コードがあったとして、このあとdocの内容をiframe#fmに入れるにはどうしたらいいだろうか
fm.body = doc.body; fm.head = doc.head; なんかやってみたのだがheadが入らない
パーサ使わずにfm.write(str)するというのはナシで、どなたかご教示いただきたく・・・

"es6-shim by Paul Miller" は ToUint32 が仕様通りの実装ではなかった
全ては見てないけど、例外の返し方は仕様通りに読める
https://github.com/paulmillr/es6-shim/
"EliSnow/Blitz-Collections" は window.blitz.Map を拡張する独自実装
MapIterator の概念がないから keys, entries 諸々が存在しない
https://github.com/EliSnow/Blitz-Collections
"ES6 Map Shim by Eric Wendelin" は entries が存在せず、keys で配列を返す仕様違反(本来は MapIterator を返す)あり
ES6 の window.Map が存在する時には native code を使用し、存在しない時には自身の Polyfill に置き換える実装だけど、ES6 仕様と返り値が違いすぎて使えたものじゃない
https://github.com/eriwen/es6-map-shim

試した中ではそもそも "es6-shim by Paul Miller" しか選択肢がなかった(他は独自拡張過ぎる)
全部を精査したわけではないので参考程度に

>>525
HTMLIFrameElement#contentDocument は readonly だから代入できない
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-50708718

> パーサ使わずにfm.write(str)するというのはナシで、どなたかご教示いただきたく・・・
DOMParser を使う方法は知らないけど、DOMParser を使う必然性は何だろう？
対象ブラウザ次第だけど、data scheme では要件を満たせない？
(DOMParser は IE9+ 対応だから対象ブラウザの要件は満たしている気がする)

>>527
いやぁ別サイトをhttpRequestで取ってきてDOMでイジってiframeに書くようなことを考えてて
文字列やなんやらにまた書き出すなんて二度手間だなぁと思ってたんだが
readonlyならどうしようもないな、ﾄﾝｸｽ

文字列に書き出すのはdoc.documentElement.innerHTMLで一発じゃない？

質問させてください。

現在Google chromeの拡張機能を作成しています。
JavaScript から画面の操作を自動化しているのですが、
JavaScriptで画面に描画されたものをクリックすることが出来ず困っています。
JavaScript でグラフィックイメージをレンダリングしたものを
クリックする方法は無いでしょうか？

IE7 で getter-property を定義する方法はないものでしょうか

var obj = {};
Object.defineProperty(obj, 'length', {get: function () { return Object.keys(this).length; });

>>531
残念ながらIE7でgetterは実現できません

>>532
ありがとうございます
後出しで申し訳ないのですが、その後、IE8 の Object.defineProperty も DOM にしか適用できない制限付きであることを知りました
IE8 で>>531を実現する方法もやはり、ないものでしょうか…

javascriptってflashみたいに
｢今見てるか、そのウィンドウが有効化されてるかどうか｣
っての判別できますか？
最小化されてたりタブにあるだけだったら停止みたいなの造りたいんですが

>>534
これでどうじゃろ　http://hakuhin.jp/js/page_visibility.html

>>534
addEventListener('blur', listener, false);

>>530
そのHTMLタグに、onMouseClick とかのイベントを設定して、
その関数を直接よぶのではなく、

イベントキューにそのタグの座標を指定して、
クリックイベントをポストすれば？

【JavaScript】メモリの浪費を避けるコーディング
http://utage.headwaters.co.jp/blog/?p=1116
こちらの後半に

> elemはfuga内のelem(3行目)からスコープチェーンで参照され、fugaはaddEventListener(6行目)によってelemから参照されているため、
> fuga -> elem -> fugaという循環参照が発生しています。これを回避するためには、単純にfugaをグローバルスコープにしてあげればOKです。
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。

との記述があるのですが、自分にはどちらも循環参照に見えます。
どうか一方は循環参照ではない事の解説をお願いします。

>>538
確かにどっちも循環参照するコードだねw
しかも最近のブラウザでは問題にならないというのに、記事作成が2013年…
その記事書いたやつはnoob認定でいいよ

>>538
循環参照なんかどうでもいいよ
elemが消滅してもremoveEventListener叩いても結局全部開放されるんだから

>>538
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。
循環参照してる上に説明文も誤りですね
グローバルスコープにする必要があるのは elem ですし、グローバルスコープにしても循環参照はします
グローバルスコープにする理由は、DOMオブジェクトをグローバル変数にしておけば循環参照してもGCが期待通りにメモリを解放してくれるからです

var elem = document.getElementById('Sample');
elem.addEventListener('click', function (event) {
console.log(elem);
}, false);

また、この場合は event.currentTarget で対象の要素ノードを取得出来るので変数束縛する必要もありません
そもそも、このメモリリーグ問題は attachEvent を使う古い実装で発生したはずなので実証コードも良くないですね
IE8- の attachEvent なら event.currentTarget は存在しないので elem の変数束縛も納得できます
最も、event.target から該当ノードを検索すれば循環参照そのものを回避出来ますが
循環参照させないコード例とか、detachEvent で unload 時に明示的に参照を切る方法とか、その記事で触れられていない対策があるのも気になります

>>539, >>540, >>541
ありがとうございます。 やはり循環してましたか。
ところでみなさん、この辺の知識はどうやって仕入れてます？
見るべきサイトや本があれば教えてください。

>>535>>536
あざっす！
まさにこれです！

>>542
循環参照とメモリリークパターンは下記を参考に
https://msdn.microsoft.com/ja-jp/library/bb250448.aspx
http://d.hatena.ne.jp/babu_babu_baboo/touch/20100417/1271465430

「この辺の知識」とは具体的には？
基本的に情報は公式サイト以外は信用しない
リークパターンでいうならMSDNを検索して検索して検索する
一次情報に勝る信頼性はないからそうしてる
リークパターンは情報が少なくて信用出来る意見を個人サイトから取り入れたのもあるけど、それでも公式サイトとの正誤比較は必須と思ってる

jQueryを使うと循環参照していても
メモリリークしないのはどういう理屈でしょうか？

>>545
>>5

>>545

1. JavaScriptだけの世界においては循環参照していてもメモリリークは起きない
2. DOMはブラウザが持っているAPIで、JavaScriptで実装されたAPIではない。（今は多少状況が違っていたりする）
3. JavaScriptとDOM（JavaScriptの外）で循環参照しているのがメモリリークになる
4. 循環参照が起きやすいのが、DOMのイベントハンドラ
5. jQueryではDOMに直接イベントハンドラを設定せずに内部で独自に管理している
6. その為、イベントハンドラのJavaScriptとDOMが直接循環参照しない

>>547
有り難うございます。
わかりやすいかったです。
そういう理屈だったんですね。

>>545
jQuery でも循環参照しているが、window unload 時に detachEvent しているからメモリリークしない

>>547は真っ赤な嘘だから信用しないように
jQueryもJavaScriptで書かれたコードに過ぎないので、script-DOM間の循環参照は起きる

>>549
↓ こういうのが循環参照だから
window.addEventHandler('load', function() {
　　・・・
});

こうすればいいんだよ。↓
function onload() {・・・}
window.addEventHandler('load', onload);

クロージャーでイベントハンドラを作らないで、関数を指定すればば循環参照は起きない。

jQueryはこれに近いことをやっている。擬似コードレベルで書くと

$(window).on('load', function() {・・・});
と書いた時、jQuery内部では以下のように処理されている。

var events = {'load': []};
function on(event, handler) {
　if (events['load'].length == 0) {
　　window.addEventHandler('load', onload);
　}
　events[event].push(handler);
}
function onload() {
　for(var i = 0; i < events.length; i++) {
　　events['load'][i]();
　}
}

DOMに直接登録されているイベントハンドラは、ただのjQuery内部に定義されたただの関数であり、
クロージャーは内部でイベントハンドラリスト変数に格納される。

>>550
循環参照でメモリリークする実装用の jQuery は v1.x 系であり、v1.x系は内部で event プロパティの互換性を取る為にクロージャを形成している
この時点で循環参照が発生しているので、循環参照を回避する手段がない

↓なぜこれが循環参照になるのかというと
window.addEventHandler('load', function() {
　　・・・
});

こう解釈すればわかる
function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', function() {
　　　alert(a.length);
　　　alert(foo.name);
　});
}

本来、aはローカル変数だから、foo関数が終わったら開放されるはずだけど、
loadした時に呼ばれるクロージャーは、a.lengthを参照できるし、
foo.nameも見える。つまりaはずっと残り続けるし、foo関数自体がずっと残る。

これをonload関数に分けると
function onload() {
　// aは見えない
}
function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', onload);
}

fooを実行されたらaもfooも消えるわけ。
そもそもonloadからアクセス出来ないので。

jQueryはこのように、直接イベントハンドラに登録しているものは
ただの関数となっており、間接的にイベントを処理しているからJavaScriptとDOMの循環参照にならない。

循環参照の話、前も出てたね
テンプレに入れるとか入れないとかどうなったのかな

>>551
> event プロパティの互換性を取る為にクロージャを形成している

eventの話も追加しないといかんのかｗ

window.addEventHandler('load', function(event) {・・・});
$(window).on('load', function(event) {・・・});


一見どちらもクロージャーの中でeventを参照しているように見えるが、
jQueryのeventはDOM標準のeventではない。

DOM標準のeventに形を整えた、jQuery.Eventオブジェクトになっている。
だからeventを参照しても、JavaScriptとDOMの間に直接循環参照が形成されることがない。

window.addEventHandler('load', function(event) {・・・});
↑DOMである　　　　　　　　　　　　　　　　↑DOMである

$(window).on('load', function(event) {・・・});
↑DOMではない　　　　　　　　↑DOMではない
jQueryオブジェクト　　　　　　　jQuery.Eventオブジェクト

このように、jQueryでコードを書くと
DOMを直接参照しない。

jQueryでも、こう書けばaもfooもずっと残り続けるのでは？

function foo() {
　var a = [巨大な配列];
　$(window).on('load', function() {
　　　alert(a.length);
　　　alert(foo.name);
　});
}

>>550,552,554
理解した
便利だが、とんでもなく重たい処理だな
そこまでやるなら useCapture や handleEvent ぐらいは対応して欲しいものだが…

>>556
そうだねｗ 少し説明が足りなかった。

たしかにそう。その通り。
だけど問題は「この循環参照がメモリリークを起こすかどうか」って話。

本来あるべきなのは、>>556で書いても>>552で書いても
循環参照そのものは起きるが、メモリリークは起きてはいけないってこと。

だけど、>>552では、「循環参照が起きてるのが」「JavaScriptとDOMの間であり」
「それがブラウザの問題によって」「クロージャーが無くなってもメモリリークする」
これが正しい説明。

なぜクロージャーが無くなってもメモリリークするのかというと。
JavaScriptが「クロージャーが無くなったこと」を検出できないから。
なぜならクロージャーはJavaScriptの世界にいないDOMによって管理されているから

window.addEventHandler('load', function(event) {・・・});
↑DOM　　　　　　　　　　　　　　　　　　↑DOMの世界に連れて行かれたので
　　　　　　　　　　　　　　　　　 　　　　　イベントハンドラが消えてもそのことが
　　　　　　　　　　　　　　　　　 　　　　　JavaScriptの世界に通知されない


jQueryを使うと、クロージャ自体はまだJavaScriptの世界にいて、
そしてDOMの世界に連れて行かれるのは、jQuery内部に定義された関数だけになるので
JavaScript（のクロージャー）とDOMの間では循環参照が起きない。

何個か前のスレでも上がってたけど、循環参照でメモリリークするのって、IE6とか昔のブラウザだけだよね？

>>557
useCapture はIEのattachEventにはない機能なので
クロスブラウザにする上で実装不可能。

IEでaddEventListenerが使えるようになったのはIE9から。
jQueryは2006年8月リリース、IE7は2006年10月、IE9は2011年
シェアも考えるとuseCaptureに対応するのは現実的じゃない。

1系との互換性を保つ理由がなくなったらサポートされるかもね。
今は、古いブラウザ対応の1系とモダンブラウザ専用の2系は
API的には完全に同じで入れ替え可能だから。

>>557
handleEvent って必要かな？
例えばjQueryでこのようなコードは書けるよ

var handlerObject = (function() {
　var local = '';

　return {
　　'click', function() {},
　　'keydown', function() {},
　}
})();

$(window).on(handlerObject);

handleEvent のサンプル見ると
handleEvent関数の中でswitchで処理を分けるもの
ばっかり出てくるけどあれださくね？

こんなの。
http://lealog.hateblo.jp/entry/2013/02/14/215952

それよりも>>561の方がswitchがない分
優れてると思う。

いまいちどういう時にhandleEventを使うと
嬉しいのかよくわからない。

>>560
> useCapture はIEのattachEventにはない機能なので
> クロスブラウザにする上で実装不可能。
attachEvent になくとも、jQuery で独自管理しているなら出来るだろう？
attachEvent の実行順不定も独自管理で吸収しているわけだから実現できないとは思えない

>>562
handleEvent が便利なのは this 値を制御できるところ

function Hoge () {}
Hoge.prototype.foo = function () { };
Hoge.prototype.handleEvent = function () { this.foo(); };
document.addEventListener('click', new Hoge, false);

listener 関数内で bind される this 値を変更するために余計な処理をしなくて済む
jQuery では出来ないので Function#bind 的な処理を追加する必要がある

>>563
> attachEvent になくとも、jQuery で独自管理しているなら出来るだろう？

どうやって？ これがもしでキャプチャフェーズはあるが
バブリングフェーズがない のであれば、キャプチャフェーズで
発生したイベントを保存しておいて終わったら逆に再生することで実装可能だと思う。

だけどそもそもキャプチャフェーズがないのだから、キャプチャフェーズの
発生順番なんて取得しようがないでしょ？

あぁ、（君の考えが）わかったｗ

ならバブリングフェーズで起きたイベントをとっておいて、
それを逆に再生してキャプチャフェーズを行えばいいって思ったね？
その後で、バブリングフェーズをエミュレート（最初のバブリングフェーズは無視する）
すればいいって考えたね。

event.preventDefault() の存在を忘れてるよ。
event.preventDefault()は本物のバブリングフェーズで実行しないと
規定の動作（リンク移動など）が実行されてしまうんだ。

>>565
> ならバブリングフェーズで起きたイベントをとっておいて、
> それを逆に再生してキャプチャフェーズを行えばいいって思ったね？
その通り

> event.preventDefault()は本物のバブリングフェーズで実行しないと
> 規定の動作（リンク移動など）が実行されてしまうんだ。
jQuery は phase を認識できるのだから capturing phase では event.cancelable = false を設定して、event.preventDefault() を実行しなければいいのでは？
event も jQuery が管理するオブジェクトだとあなた自身が主張していたと思うのだが

>>566
キャンセル不可能なイベントも有るんだよ。
https://developer.mozilla.org/ja/docs/Web/API/event.preventDefault

> イベントがキャンセル可能かどうかは event.cancelable を使って確認できます。
> キャンセル不可能なイベントに対して preventDefault を呼び出しても効果はありません。

各イベントにキャンセルできるかどうか書いてあったと思うけど
ちょっと面倒だから、この説明だけ書いておくけど。

>>566
> event も jQuery が管理するオブジェクトだとあなた自身が主張していたと思うのだが

jQueryが管理しているのは、イベントハンドラ。
イベント自体はDOMで発生した順番通りに処理する。
話をごっちゃにしてるぞ。

>>564
> listener 関数内で bind される this 値を変更するために余計な処理をしなくて済む

なるほど。この違いってことだね。

//Hogeは同じ
function Hoge () {}
Hoge.prototype.foo = function () { };
Hoge.prototype.handleEvent = function () { this.foo(); };


document.addEventListener('click', new Hoge, false);
$(document).on('click', $.proxy(new Hoge, 'handleEvent'));

>>567
イベントをキャンセル不可能なら

event.preventDefault = new Function;

でキャンセル不可能になるだろう？
何を言いたいのか、さっぱりわからん

>>558
>メモリリーク
load イベントのように一度しか実行されないものは別として、
ページ内に居残り続けるイベントハンドラには関係無い話
ってことでok?

jQueryのイベントハンドラがオブジェクトの場合って
空いてると思うからhandleEventに対応するのは可能そうだね。

現状だと、こうするか>>568のようにするか、jQueryプラグインを作れば短くなるかな。

document.addEventListener('click', new Hoge, false); // オリジナル
$(document).on('click', $.proxy(new Hoge, 'handleEvent')); // 動作する
$(document).on('click', $.handle(new Hoge)); // handleプラグイン作ってみた
$(document).on('click', new Hoge); // 理想

間違えた
キャンセルするのはイベントじゃなくてデフォルトアクションだったな
event.stopPropagation と勘違いする人がいるといけないので一応、訂正

>>569
だからね。

1. 本物のバブリングフェーズでイベントが発生（全部キャンセルする）
2. jQueryでキャプチャフェーズをエミュレート
3. jQueryでバブリングフェーズをエミュレート

これを実現するには、本物のバブリングフェーズで
ブラウザのデフォルトの動きを、
全てキャンセルしないといけないわけ。

キャンセルできないと、jQueryでキャプチャフェーズをエミュレートする前に
ブラウザのデフォルトの処理が行われてしまう。

例えば、unloadイベントはキャンセルできない。あとcancelableはreadonlyだから注意してね。
https://developer.mozilla.org/en-US/docs/Web/Events/unload
> Bubbles No
> Cancelable No
> cancelable Read only

あとバブリングしないイベントも有るって問題もあったな。

>>570
それが更にひどい話でページが移動しても
メモリに残り続ける場合もある。
ここまで酷いのはIE6の初期ぐらいだとは思うけど

実際のところ、bubbling しないイベントタイプで capturing phase を実装するのは難しいだろうが、bubbling するイベントなら独自管理できると思う

1. イベント伝播先の最終地点(document or window)に一つだけ addEventListener し、bubbling 過程でユーザ定義されたイベントを全て拾う
2. capturing phase を降順再生
3. bubbling phase を昇順再生

bubbling しないイベントタイプでは全要素にイベント定義して capturing phase を降順再生する必要があるので、全く現実的ではない

>>575
限定的なら可能かもしれないけど、そうすると
このイベントはブラウザから出て、このイベントはjQueryがエミュレートするとかで
実行順とか細かい動きの違いが出て、ハマる元になると思う。

DOMでさえ、イベント事にキャンセルできるか出来ないか
バブリングするかしないかって違いがあるのに、
さらにjQueryが絡んでくるとかさ。

jQueryはDOMを単純にすることが使命であって
DOMよりも複雑にしてしまったら本末転倒。

まあ、こんな所でごちゃごちゃ言ってるが、
キャプチャフェーズへの対応は検討されたけど
無理という理由でとっくの昔に却下された話だろうな。

こんなDOMの基本的な機能をjQuery開発者が見逃すわけ無いし、
追加で対応できるようなものならとっくにしてるだろうさ。

>>573
いいたいことはわかったし、>>575の問題点もはっきりした
であるならば、こんな方法はどうだろう？

1. document.attachEvent('onclick', listener) を一つだけ定義
2. bubbling phase で on() でユーザ定義されたイベントを検知
3. この時、"capturing event" として定義されたイベントを全て実行してしまう
4. "bubbling event" を通常通り実行

初回、イベント検知時に全ての capturing phase を実行すれば良い
これなら bubbling phase でイベントをキャンセル必要がなくなる

> unloadイベントはキャンセルできない
unload イベントは Bubbles No だから初めからイベントの実行順は自明のはず
同じDOMを参照する2つの unload があるなら予め実行順を定義する事が出来る
ただ、event.target !== event.currentTarget の状況を想定するなら確かにエミュレートできない
Bubbles No なイベントで capturing phase を実現する完全な方法は存在しないと思う

>>578の補足。

> unload イベントは Bubbles No だから初めからイベントの実行順は自明のはず
> 同じDOMを参照する2つの unload があるなら予め実行順を定義する事が出来る
"capturing event" -> "bubbling event" の実行順になる、ということ

useCapture の件とは違って handleEventに関しては
対応できないことは、思えなかったので探してきた。

結論を言うと、handleEventは3.0で対応しそうだよ。

http://bugs.jquery.com/ticket/12031
→ https://github.com/jquery/jquery/issues/1735

まだOpen状態だけど、Milestone 3.0.0 になっている

>>578

>>576で書いたように限定的になら対応可能だと思うけど
限定的でしか無いし、場合によっては複雑になる場合もある。

JavaScriptで書いたコードすべてがjQueryを使っているのなら
ましかもしれないけど、生DOMで書いてるコードがあるかも知れないし
その他のライブラリを使ってるかもしれない。

jQueryはフレームワークじゃなくて、ライブラリなのだから
混ぜて使うことも考えるべき。（だからnoConflictというのもある）

気づいていない人も多いと思うけど、jQueryのイベントハンドラって
DOMのイベントハンドラをそのまま使うことも出来るんだよ。
その為にthisはDOM要素だし、eventはDOMのeventと互換性を持たせてある。
つまりjQueryのイベントハンドラの入り口はDOMと互換性がある。
jQueryはそこまで気を使って作られてるんだよ。

できそうかどうかの話じゃなくて、それを実現した結果嬉しいかどうか。
jQueryを使うことで混乱が生じるのであれば、最悪jQueryは
使わないほうがいいってことになってしまう。

俺はjQuery開発者じゃないから、本当はどう考えているかわからないが、
俺なら、以上の理由でキャプチャフェーズへの対応は却下するよ。
（1.xがウェブから消えて互換性を切り捨てていい時代になれば話は別）

>>581
> 限定的でしか無いし、場合によっては複雑になる場合もある。
確かに自分だったら対応しないだろうな
実験的には面白そうな試みではあるが、公開しないという判断は理解できる

> その為にthisはDOM要素だし、eventはDOMのeventと互換性を持たせてある。
this は元々は独自拡張で DOM 4 が後追いで標準化されたけどな

また、jQueryのイベントは DOM 標準プロパティも使えるが、かなり拡張してある
event.delegateTarget は event.currentTarget と同値だし、
event.data というコンテナは handleEvent があれば不要になったはずのプロパティだし、
event.isDefaultPrevented(), event.result とかいうコーディングの書き方次第で不要なプロパティはあるし...etc
jQuery の event からはDOM標準も使えるけど、どんどん拡張しようとするスタンスが見え隠れしてる
今は修正されているが、古くは .attr() の仕様がプロパティ参照/属性参照の曖昧さ加減が酷いものだった
実際、jQueryコードの内容を見ても標準を使うというよりは独自路線を突き進んでいる感が強い気がする
Polyfill 的なコードより独自拡張路線のスタンスが強いように感じる

まとめると、
未来のこと。これは想像でしか無い。
過去のこと。これは昔は悪かったが今は改善された。
そういうことだろう？

>>582
> Polyfill 的なコードより独自拡張路線のスタンスが強いように感じる

jQueryがPolyfill目的だった時代は終わってるよ。
今はブラウザのバグ対策が5%で、
残りはDOM操作の生産性を上げるのが目的

useCapture、勉強したとき以来使ったことない…
普通のサイトで使うことなんてあるのかね

>>584
だからこそ「互換性を持たせて混乱しないように」という主張に疑問を感じる

>>585
useCapture を使うと Bubbles No なイベントでも capturing phase ではイベントが伝播するのが便利

>>586
> だからこそ「互換性を持たせて混乱しないように」という主張に疑問を感じる

どこに疑問を感じるの？

「俺の考えた未来ではjQueryは互換性を持たせないようになっているはずだ」
という、な〜んの根拠もない主張はいらないよ？

jQueryが使いづらい/分かりづらいと思う点

- jQuery.proxy() の名前が分かりづらい(Function#bind と名前が全く違う)
- jQuery.data() でdata-独自属性の参照規則が複雑
- var obj = {}; obj.window = obj;console.log(jQuery.isWindow(obj)); // true
- isXMLDoc() も同様。[[Class]] 判定ぐらいせよと
- テキストノード操作APIがない(DOM API を使わないとやってられない)

API名からして大分違うし、ECMAScript, DOM に慣れ親しんだ人がすぐ使えるライブラリではないよなー
「混乱上等、jQuery の世界にどっぷりつかって来てね」というメッセージを感じる
対象ブラウザの下限を上げれば、ES5, Selectors API で十分って人もいるだろう

jQueryは古くからdata()メソッドというものを持っていた。
これはDOMに関連付けられたデータを保持するメソッドであるが、
HTML5になってから、HTMLにdata-*属性という仕様が追加された。

jQueryはその標準仕様に対応し、dataメソッドでdata-*属性を
取得できるようにした。

>>588
ある程度、Interface の名前や機能に互換性を持たせて jQuery 習得コストを下げるという意味ではないのか？
jQueryの場合は、既に普及している事もあって今までに作り上げた jQuery の世界観を崩さないようにすることを重視しているように見える
DOM Interface との互換性を重視しているようには見えず、新参者が混乱してもおかしくないと思う

テキストノード関係はほんと強化して欲しい

>>590
歴史的にはわかるけど、data() で data 独自属性を参照可能にする必要はなかったような
attr() で参照可能なんだから、data() を拡張する必然性がない
一つのメソッドで複数の事が出来るのは便利だけど、わかりやすさからかけ離れてしまう面もあるよね

実際、ES5 で生産性は上がっているから jQuery を使う必然性は下がってきてはいるんだよな
Polyfill を使えば、ある程度は古いブラウザにも対応できる
Selectors API は複雑なので IE7 以下をサポートすると大変だが

>>589
> - jQuery.proxy() の名前が分かりづらい(Function#bind と名前が全く違う)

それはproxyはbindではないから。使い方が違う。
proxyは他のメソッドに処理を転送するために有る
他のメソッドに処理を転送するのが目的なので、メソッド名を
文字列で指定できたり、引数の追加などの機能がある

> - jQuery.data() でdata-独自属性の参照規則が複雑
難しくないので何を言っているのかさっぱりわからない。
念の為に言っておくと、"属性"を読み書きするのはattrであり
data()は属性ではなくHTMLに関連付けられたデータを取得するだけ（data-*はデータの初期値でしか無い）

> - var obj = {}; obj.window = obj;console.log(jQuery.isWindow(obj)); // true
完全に見分ける方法はないので、こんなこと普通やらんだろｗ というモアベターな方法でチェックしてる。

> - isXMLDoc() も同様。[[Class]] 判定ぐらいせよと
やる価値がない。そんなエッジケースに対応して遅くなる方が問題

> - テキストノード操作APIがない(DOM API を使わないとやってられない)

$('#id').contents().filter(function() {
　　return this.nodeType === 3;
}).each(function() {
　　console.log(this);
});

>>593
> 歴史的にはわかるけど、data() で data 独自属性を参照可能にする必要はなかったような
> attr() で参照可能なんだから、data() を拡張する必然性がない

attrでは面倒くさい。

<p id="id" data-a="a" data-b="b"></p>

console.log($('#id').data());
// → Object { a="a", b="b"}

HTML5 に追従するなら element.dataset で実装して欲しかった
あんな中途半端な実装なら getAttribute() 互換の attr() で十分だよ
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes:dom-dataset

>>594
> 実際、ES5 で生産性は上がっているから
ES5 では所詮ES5でやれる範囲止まりなんだよ。

だから、セレクタにマッチした複数の要素にイベントを割り当てる
$(selector).on('click', ・・・)や

複数のイベントに同じハンドラを適用するとか
$(selector).on('load, resize', ・・・)や

DOM関数の生産性は上げられない。
あくまでDOM APIからもらってきて、
それを処理するところしか生産性があがらない。

jQueryのキモは、セレクタに一致した0個以上の要素に
一括して処理できるところにあるわけで。

data() で data 独自属性の書き換えは出来ないのか
jQuery で data 独自属性を書き換えるには attr() しか選択肢がない

>>597
> HTML5 に追従するなら element.dataset で実装して欲しかった

element.datasetのどの機能に対応して欲しいの？

element.datasetと全く同じものjQueryで実装してくれよというのは、
jQueryはpolyfillライブラリじゃないんだけど？で終わる話。

jQueryは0個以上の要素を扱うライブラリなので
$(selectoer).data('name', 1) とか出来るようにするもの。
要素一個一個で操作するためのelement.datasetと
data()では全然目的が違うでしょ。

>>595
> $('#id').contents().filter(function() {
> 　　return this.nodeType === 3;
> }).each(function() {
> 　　console.log(this);
> });
生のテキストノードを参照してるようだけど...
nodeTypeプロパティも DOM 規定のもの
結局、DOM API を使わないとテキストノードを操作できない

>>600
data() で data 独自属性を参照する必要はないでしょ
あなたのいうとおり、違う機能なんだから
しかも読み取るだけで書き換え出来ないとか中途半端な仕様なら全く持って不要

>>599
> data() で data 独自属性の書き換えは出来ないのか
> jQuery で data 独自属性を書き換えるには attr() しか選択肢がない

この勘違い、やっぱりしている人がいるんだよね。
常々、この区別が頭のなかではっきりしてない人いるんだろうなって思っていたけどさ。
単純にHTML（要するにタグ）とDOMオブジェクトが持っている情報は別ってだけ。

** jQueryを使わないで ** 説明するね。

<input id="id" type="checkbox" checked="checked">

var chk = document.getElementById('id');
console.log(chk.getAttribute('checked')); // checked
chk.checked = false;
console.log(chk.getAttribute('checked')); // checked

チェックボックスのチェックは外れているけど、
二回目でも、checkedって表示されるんだよ。

これがchk.removeAttribute('checked')であれば、二回目はnullになる。

つまりね。「HTMLの属性」を書き換えるのは、どちらにしろsetAttributeなの。
DOMの状態を変えるだけでは、HTMLの属性は変わらないの。
念の為に言っておくけど、ここまでjQueryの話してないからね。


だからjQueryのdata()も（ついでにprop()も）一緒なんだよ。
DOMの状態を変えるものと、HTML属性を変えるものは最初から別のもの

>>602
> しかも読み取るだけで書き換え出来ないとか中途半端な仕様なら全く持って不要

>>603でちゃんと説明したからね。
「HTML属性」を書き換えるのはsetAttribute（jQueryではattr）でやるべきこと。

data()はDOMの状態を変えるものであって、HTML属性を **変えてはならない**
だから中途半端ではなく、意図して作られた機能

>>598
そもそも、複数の要素に同じイベントを割り当てる機会がほぼないから問題ない
上位ノードで一つ監視すれば済む
君のいう生産性は運用次第で何とかなる問題だから考慮する必要がない人もいることは覚えておいたほうがいい

>>601
> 生のテキストノードを参照してるようだけど...
> nodeTypeプロパティも DOM 規定のもの
> 結局、DOM API を使わないとテキストノードを操作できない

ん？ テキストノードの操作って他に何をやりたいの？

nodeTypeプロパティを使って、テキストノードを取得していることに
文句を言ってるだけ？ それがいやならプラグイン作ればいいだけの話だと思うけど
$('#id').textnodes() とか簡単に作れると思うよ。

>>605
> そもそも、複数の要素に同じイベントを割り当てる機会がほぼないから問題ない
> 上位ノードで一つ監視すれば済む

それを言ったら、element.addEventListenerは要らないって言っているのと同じだけど？
window.addEventListenerさえあれば十分ですよね？ｗ
あなた、DOMの仕様に文句をつけてるよ！
あと、バブリングしないイベントもありますので〜♪

それから上位ノード一つ監視するにしても、jQueryだと生産性が上がるよ。
特定のクラスだけ監視する時に書くコードはこれだけでいいからね。
いちいちフィルタリングコードを書かなくて良い。
$(document).on('click', '.klass', function() {・・・})

ということで、ES5で生産性上げるといってもやっぱり
ES5の範囲止まりで、DOMの生産性はあがりませんでしたと
さっきの私の話の続きになりましたねｗ

>>603
おまえにいわれなくともわかってるわ
おまえも主張するようにHTML属性の読み書きは attr() の役割なんだよ
data独自属性の読み取りも attr() の役割
data() でHTML属性を参照するのは役割が違うが、拡張されたのならどんな機能が実装されたか確認するだろ
すると、初回読み込み時だけ data 独自属性が合ったらそちらを参照する仕様ときたもんだ
そんな中途半端な仕様にするならdata独自属性の attr() に任せて余計な事しなければいいだろ

>>608
> おまえにいわれなくともわかってるわ

重要なのは、お前がわかってるかどうかじゃなくて
他の人がわかってるかどうかなんだよねｗ

このままだと、"他の人が" data()はHTML属性を書き換えないという
問題があると勘違いされてしまうだろ？

じゃなくて、HTML属性を変えないのは、問題ではなくて
そういう機能だって明言しただけ。

うん。お前はわかっていたんだよね。
大丈夫、 "他の人に" 言ってるだけだからｗ

> すると、初回読み込み時だけ data 独自属性が合ったらそちらを参照する仕様ときたもんだ
え？ わかってるのかな？ｗ

チェックボックスのcheckedも同じ動きするんだけど？
初回のHTML属性の値を反映するが、checkedに代入してもHTML属性の方は変わらない。

やっぱり、お前、実はわかってないだろｗ

>>607
おまえは上位ノードといったらルートノードしか思いつかないのか

通常は必要最小限の上位ノードを指定する
例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
全てのイベントでdocumentを指定する必要はない
煽るのが得意なようだが、もう少し経験を積んでから他人に指摘するほうがいいと思うぞ

>>610
> おまえは上位ノードといったらルートノードしか思いつかないのか

おまえは、
$(document).on('click', '.klass', function() {・・・})
というコードを見たら

$('#wrapper').on('click', '.klass', function() {・・・})
というコードも書けるって、思いつかないのか？


jQueryでも 通常は必要最小限の上位ノードを指定する
jQueryでも 例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
jQueryでも 全てのイベントでdocumentを指定する必要はない

煽るのが得意なようだが、もう少し経験を積んでから他人に指摘するほうがいいと思うぞ

例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
例えば、table要素内で th の時だけ click 判定したいのなら、table要素ノードを指定する

そしておもむろにこう書く！

$('table').on('click', 'th', function() {・・・})

すげーぜ、jQueryの生産性♪

しかもこれ、すべてのtableに一度にイベントハンドラつけてるんだぜ！

このjQuery信者は話すたびにボロが出てるな...

>>613
ぶっちゃけ、今日はワンサイドゲームで楽しいよｗ

>>611
あなたは趣旨を理解して話すことが出来ない人なのか？

・あなたは複数ノードにイベント定義できるのが jQuery のメリットだといった
・私は複数ノードにイベント定義する機会がほとんどないといった
・あなたはjQueryでも上位ノードで監視できるといった

で、私は何を反論する必要があるのだ？

思い込みが強くて論理的に考えられない人って怖いです

>>615
俺の言ったこと理解してないじゃんんｗ

× ・あなたは複数ノードにイベント定義できるのが jQuery のメリットだといった
○ ・あなたは複数ノードにイベント定義できるので生産性が高くなり、それが jQuery のメリットだといった

× ・私は複数ノードにイベント定義する機会がほとんどないといった
○ ・わ、私は、複数ノードにイベント定義する機会なんて、ほとんどないんだからねっ！

×・あなたはjQueryでも上位ノードで監視できるといった
○・あなたはjQueryでも上位ノードで監視でき、その場合でも生産性が高くなるといった


> で、私は何を反論する必要があるのだ？
そりゃ

1. 複数ノードにイベントを定義することが、「ほとんど」ではなく「100%ない」と断定する
（一つでもあればjQueryの方が生産性高くなるので当然ですね）

2. 上位ノードで監視して子要素を制限する例でのjQueryの生産の高さを否定する

この2つを反論しなければならないのでは？

他にも言ってないだけで、セレクタに一致する複数の要素に、特定のメソッドを適用する場合のjQueryの生産性の高さ
| 例 $('#form1 :button').prop('disable', true);
| // フォーム1以下のボタンタイプの要素（button, type=button, image, submit等)を全部無効にする
とか、山ほど反論する必要がありますが。

jQueryはDOMの生産性を上げるために作られたのだから、
jQueryの方が生産性が高いのは当たり前なんだよ。

不思議なのは、その当たり前のことに否定していること。
生産性の高さだけは素直には認めろよ。

反論する余地があると言ったら
生産性は落ちるが、今はjQueryを読み込まなくても頑張れるぐらいになった。
頑張れば、初回のjquery.js（gzip圧縮時30KB)のファイルダウンロードと、
jQuery初期化のための数ミリ秒のコストが省けるんだ。
ぐらいしかないだろ？

所でjQueryを使うことで30KB余計にファイルサイズが増えるが、
jQueryを使うと、アプリの方のコードは減るんだよね。
アプリの方のコードがどれくらいになったら、jQueryを使ったほうが
サイズが少なくなるだろうか。

lodashにstartCase()ってのが追加された。
3.0.2くるかな？

>jQueryの方が生産性が高いのは当たり前なんだよ。
>不思議なのは、その当たり前のことに否定していること。

そんな奴いるのかw
ライブラリ否定厨は頭がおかしいな

>>550-
これってremoveEventでunload時にonload()呼ばなくていいんですか？
あとこれってイベントがloadでない例えばclickとかでもクロージャー使うとだめですか？

ライブラリ信者の暴れぶりが尋常でなくて、むしろ清々しささえ感じる

などとあおっている奴よりも、よっぽど役に立ってるがなｗ

うん、さすがに>>617とか読んでて気持ち悪い

などとあおっている奴よりも、略

昨日はライブラリ否定厨がでなかったみたいだね。
これだけ長くやりとりしているのに、ほとんど荒れてない。
本当に荒らしているのは誰かよく分かる流れだ。

結構参考になるからjQueryの話はok
lodashの方はどうでもいい

でもlodashの方がJavaScript（ECMAScript）に近いんだよね。

jQuery・・・DOM APIを改善するライブラリ
lodash・・・ECMAScriptを改善するライブラリ
(lodashの元となったunderscoreも同様）

それぞれクロスブラウザ対応のためという使い方を除くと

jQuery・・・DOM操作が関数型プログラミングできる
lodash・・・ECMAScriptよりも多くの関数型プログラミングの機能が使える。

こういった特徴がある。

lodashの機能というのは、ECMAScript自体追加された関数型プログラミングの機能の代替だから
JavaScriptで関数型プログラミングは既定路線。素直に勉強した方がいいよ

参考 JavaScriptで学ぶ関数型プログラミング
http://www.oreilly.co.jp/books/9784873116600/
（この本でもunderscoreは説明されている。付録C 本書に登場するUnderscoreの関数）

lodashは単により多くの関数型プログラミング機能を提供してくれるだけだから
関数型プログラミングではないDOM APIを関数型にしてくれるjQueryよりも
そこまで重要じゃない。ECMAScript7や8になればさらに不要になるだろう。

jQueryは、DOM APIが関数型プログラミング用のAPIに大幅（というより完全に別物）に
変わらない限り、直接DOM APIを実行する代わりとして使われるだろうね。
DOMはJavaScriptだけのものじゃないから、なかなか難しいかな。

ES6のclassやthenってまだchromeやfirefoxで使えませんか？
今はメジャーな最新バージョンのブラウザならES5.1で書いても大丈夫そうですけどES6っていつ頃メジャーになりますか？

>>629
http://kangax.github.io/compat-table/es6/

EcmaScript6の対応は一番いい
IE Technical PreviewやFirefox 37でも69%だよ。

IE Technical Preview（IE12？ spartan？）移行は
自動更新になるだろうから、ネックはIE11。
そのIE11を搭載しているWindows7のサポート期間
2020年1月14日までだから、あと5年はES6使えないだろうね。

もっともWindows7からWindows10へのアップグレードは
無料になるらしいから、もっと早く移行が完了する可能性もある。

その5年の間にES6の対応も進むだろうから、
まあ普通に使えるのは5年後ぐらいじゃない？

あ、Android端末を忘れていたｗ
スマホの標準ブラウザを考えると少し厳しいかもね。
まあ5年あれば使うような人は買い換えるかな？

>>629
classは文法だから、ES6→ES5コンバーターを使わなければ対応できないけど、
then（Promise）ならPolyfillライブラリを導入するだけで対応できるだろう。

jQueryのPromiseも同じような仕様だったはず。
jQueryはどちらにしろ使うので、二重に同様のライブラリを入れるのは
CPUとメモリの無駄だから、今のところはjQueryのPromiseを使ってるよ。

>>552
これは循環参照じゃないなの？

var a = [巨大な配列];
function onload() {
}
window.addEventHandler('load', onload);

>>632
書き換えるなよｗ >>552が言っている内容と違ってるじゃん。

function onload() {
}

function foo() {
var a = [巨大な配列];
window.addEventHandler('load', onload);
}

勝手にaのスコープ（ 生存期間）を変えないように。

循環参照の話題自体が循環参照してる…
誰かガベージコレクトしてくれ

クロージャー使うとと循環参照している
→別に循環参照してもいいんだよ。
→DOMとの間で循環参照すると古いIEで問題が出るだけ。
→だから循環参照するからクロージャー使ったらだめなんでしょ？
→循環参照してもDOMとの間でなければいいんだよ。
→そう。そしてjQueryを使えばクロージャー使ってもDOMとの間で循環参照にならない。
→jQueryは開発効率がいい！

ここまでが一連の流れｗ

jQuery 使わずとも

function onload() {
...
window.removeEventHandler('load', onload);
}
としとけばいいんでない
一度しか実行されないハンドラは少数に限られるだろうから

>>633
わざわざonloadっていう関数作っても
スコープの外は参照できるんだから結局循環参照するのでは？
aは開放されるけどbは開放されない

var b = [巨大な配列];
function onload() {
}

function foo() {
var a = [巨大な配列];
window.addEventHandler('load', onload);
}

>>552
巨大な配列がDOMでなければ循環参照しないはずだが
クロージャを少なくする設計には賛成だが、循環参照は関係ない

循環参照の話を循環させるなっての

(function(){
var hello = 'hello world';
function load(){
console.log(hello);
}
window.addEventHandler('load', load);
}())

これを循環参照しないようにしたコードをおしえて

>>640
初めから循環参照してません

やはり、「IE8 で>>531を実現する方法」は存在しないのでしょうか

(function(){
var hello = 'hello world';
function load(){
var age = 10;
console.log(hello);
}
window.addEventHandler('load', load);
}())

じゃあこれは循環参照しますか？

>>643
というか、そもそも window.addEventHandler('load', load); で TypeError なんですが

Listenerで読み替えてください

scriptのsrcを書き換えただけじゃ通信が起こらないんですが
scriptを削除して挿入しなおさないかぎり通信しないですか？

>>645
循環参照しません
基本的な循環参照規則を学んでから質問してください
質問前にコードが動くことを確かめてください

じゃあなんで>>637は循環参照するのに>>643は循環参照しないんですか

>>648
>>637は循環参照しません

>>636
>>550を読めばわかる

> としとけばいいんでない
普通はやる必要がないこと。

removeEventListenerをするためには、名前を付けないといけない。
せっかくクロージャーを使って無名関数で
イベントハンドラを記述できるというのに、それは
newしたものを必ずdeleteしなければならない言語の
ようなもの。面倒くさい

> 一度しか実行されないハンドラは少数に限られるだろうから
それが昔のIEはページを移動してもメモリは解放されなかった。
だからどんどんブラウザが重くなっていった。

jQueryを使った場合は、クロージャーを使って本来あるべき姿のように
簡単に記述できていながら、メモリリークもしないようになっていた。

>>638
> クロージャを少なくする設計には賛成だが、循環参照は関係ない

クロージャを少なくする設計なんて考えていたら、
全然問題がないEcmaScriptのmapやforEach、
underscoreやlodashの関数まで
クロージャー使わないほうがいいって勘違いするぞ。

問題は生存期間が長いイベントハンドラでクロージャーを使うと、
それが呼び出されたのと同じスコープの変数も使わないものであっても
生き残ってしまうっていうのが問題だろ。
だから逆にそのスコープ内の変数の方をなくしてもいい。

>>651
要するに循環参照しない

function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', function() {　});
}

↑これを ↓こう書けばいいことは分かった

function onload() {
}
function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', onload);
}

巨大な配列は、onloadの中で参照しないからいいけど、
だけどonloadの中で参照したい変数があった時はどうするの？

つまり

function foo(value) {
　var a = [巨大な配列]; // これは要らないけど
　var b = value; // これは必要
　window.addEventHandler('load', onload);
}

function onload() {
　// ここでbを参照したい
}

クロージャーはこういうことが簡単にできるから
便利というめんもあるんだが

>>653
jQueryを使えば簡単に実現できるよ。
jQueryなら追加のデータをイベントハンドラに渡せる。

その場合ならこのように書くことが出来る。

function foo(value) {
　var a = [巨大な配列]; // これは要らないけど
　var b = value; // これは必要
　$(window).on('load', {b: b}, onload);
}

function onload(event) {
　// ここでbを参照したい
　console.log(event.data.b);
}

>>654
バッチリです。やっぱりjQuery便利やね

>>652
循環参照はあまり関係ない

この話を聞くと、Javaのクロージャーもどき（ラムダ）の
仕様は正解だったかもしれんな。

JavaScriptやいろんな言語のクロージャーはクロージャーの中から
aが見えてしまう。つまりイベントハンドラが生きてる間中、
イベントハンドラからaを参照しなくても、aが生き残ってしまう。

function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', function() {
　　// ここからaが見える
　});
}

でも、javaのラムダは、aが見えない。
それがラムダはクロージャーではないと言われる理由なんだが、
ラムダであればクロージャーを使った場合のこの問題が無くなる。

クロージャーはあってもいいと思うんだけど
クロージャーとラムダの両方がほしい。そして必要ないならば
ラムダの方を使うべきだろう。

>>656
循環参照ではなくて、ハンドラに使ったクロージャーは
生存期間が長いっていうのが問題だよね。

クロージャーの生存期間が短い場合は
クロージャーを使っても何の問題もない。

>>658
そうだね。

（DOMとJavaScriptの）循環参照はメモリリークを招くという
古いIEのバグに関連する話で、
それを除けば循環参照してもよい。

ただ循環参照とハンドラの生存期間が長い問題は別の話で
ハンドラにクロージャーを使用すると、クロージャーから見える
そのスコープにある変数すべてがメモリ内に残ってしまう。
これはIEの循環参照のバグとは別の話。

>>646
script要素が通信（コードを実行する）のは、
新しくscript要素を作成してdocumentに挿入したときと、srcも中身もないscript要素にsrcをセットしたとき。
https://html.spec.whatwg.org/multipage/scripting.html#the-script-element:prepare-a-script

<script src="hoge.js"></script> ← srcを変えても二度と通信しない
<script>alert(123);</script> ← 中身が書かれているので、srcを変えても通信しない
<script></script> ← srcも中身もないので、srcや中身を変えると一度だけ実行する

まあ簡単に言うと、一つのscript要素につきスクリプトは一回しか実行されないってことです。

>>656
>>552で「↓なぜこれが循環参照になるのかというと」と明言している意図は？
初めから「循環参照は関係ない」と指摘しているのにあなたは枝葉にばかり拘っている

>>661
循環参照にこだわるから、循環参照することは悪いのかって話になって
本当の問題が見えてこなくなる。

例えば、forEachでクロージャーを使っても循環参照する。だけどこれは問題ならない。
なぜならforEachのクロージャーの生存期間は凄く短いから。

本当の問題は、ハンドラであれば一般的にクロージャーの生存期間が長いことにある。
両方とも循環参照しているのに、一方は問題なくても一方は問題がある。
その理由は循環参照ではなくて、生存期間であるということに気づかないといけない。

それさえわかっていれば、クロージャーを使ってもいいことが理解できるはず。
本当の問題を理解せずに、わかりやすいからといってクロージャーは使ったらだめという
決まりを作ると、ルールだけが生き残ることになる。

>>550
これremoveEventせずにDOMオブジェクトが消滅したらどうなるの？
ハンドラは開放されず永久に残リ続ける？

>>662
そんなことは理解している
繰り返すが、>>552で「↓なぜこれが循環参照になるのかというと」と明言している意図は？

>>663
> これremoveEventせずにDOMオブジェクトが消滅したらどうなるの？

DOMを消す時に、jQuery内部のcleanDataが呼ばれる。
cleanDataではDOMに関連づいたデータを全て消去する。

>>644
> 繰り返すが、>>552で「↓なぜこれが循環参照になるのかというと」と明言している意図は？

古いIEでメモリリークする原因が、DOMとJavaScriptの間で
循環参照しているからだろ。「"DOMとJavaScriptの間で"循環参照してる」という
説明なしに、古いIEでメモリリークする理由を説明することは出来ない。

ここまでで一区切り。以下次の話として、

今の時代は古いIEは消えてしまったと考えていいものとする。
古いIEは消えてしまったのだから、循環参照しても問題ないよね？

そうは問屋が卸さない。
メモリリークの問題はなくなったが、
生存期間による不要なメモリ使用の問題は残っている。
これが今も起きてる注意すべき問題の話。

そーゆーのってどうやってチェックするの？
タスクマネージャーを随時みるの？

>>667
今はブラウザの開発者ツールに内蔵されてるよ。
昔は昔でそういうのを検出するプラグインがあった。

>>665
MutationEventのようなもので監視してるわけではないのかな？
jQuery以外のAPIを叩いたり
ブラウザが勝手にDOMオブジェクトを消滅させた時はリークする？

ダミーのデータを使ってわざと数十MB単位でメモリを使うように
すればタスクマネージャーでもわかると思う

>>669
使われていないし、俺なら使わない

Mutation Event から Mutation Observers へ
http://standards.mitsue.co.jp/archives/001538.html
> “Detect DOM changes with Mutation Observers” で紹介されているように、
> DOM4 では Mutation Observers という新しいインタフェイス群が定義されました。
> これらを用いると、DOM2 Events で定義された Mutation Event を置きかえることができます。
>
> Mutation Event は数々の問題点を抱えていることが明らかになっています
> （策定中の DOM3 Events では該当箇所に警告文が記述されているほどです）。
> 例えばパフォーマンスに関わる問題があります。

jQueryでハンドラやデータを追加したのなら、jQueryで消さないとだめ。

ブラウザが勝手にDOMオブジェクトを消滅させることはないだろう。
（ページ移動は別。ページ移動時=unload時に解放していたはず）

jQueryで操作したならjQueryが使えるわけで、
それをjQuery以外で削除しようと思うことはあまりないと思うけどね。

>>666
> 古いIEでメモリリークする原因が、DOMとJavaScriptの間で
> 循環参照しているからだろ。「
>>638で「巨大な配列がDOMでなければ循環参照しない」と指摘したはずだが、具体的に循環参照する「DOMオブジェクト」と「JavaScriptオブジェクト」は何だ？

function foo() {
　var a = [巨大な配列];
　window.addEventHandler('load', function() {
　　　alert(a.length);
　　　alert(foo.name);
　});
}

# 以下、戯言。
# 同じ内容を4回説明してようやく本題「循環参照しない」に入れたわけだが、何を答えてよいかわからない程の難問だったのかね…。

>>672
それでお前が言いたいことは何なんだよ？ｗ

>>972
> 具体的に循環参照する「DOMオブジェクト」と「JavaScriptオブジェクト」は何だ？

fooという関数（JavaScript）が
window（DOMオブジェクト）を参照していて、
そのwindow（DOMオブジェクト）に渡されたクロージャーが
ローカル変数aやfooという関数名を参照している。

foo,a（JavaScript） → window（DOMオブジェクト）→クロージャー（JavaScript）→foo, a（JavaScript）

見事に循環していますが？

>>672
addEventHandlerって何だ、と思ったら>>552が出典だからか
普段から素のJavaScriptコードを書いているなら間違えるわけがないんだが

>>675
すまんすまん。普段は書いてないよ。
jQueryの方を使うほうが楽なのでね。

>>674
> foo,a（JavaScript） → window（DOMオブジェクト）→クロージャー（JavaScript）→foo, a（JavaScript）
では、下記コードは「foo(JavaScript)→window(DOM)→クロージャ(JavaScript)」で循環参照してるといえるのか？

function onload (event) { alert(event); }
function foo () {
　window.attachEvent('onload', onload);
}

window はグローバル変数なので onload, foo のどちらからも参照可能だ
グローバル変数(DOM)を循環参照に含めるのなら全てのコードが循環参照してしまう
グローバルオブジェクト(DOM)はGCで正しくメモリを開放してくれるので考慮する必要がない事は覚えておいたほうがいい

>>677
お、気づいたかｗ

そこは間違ったなって思っていたところなんだよ。
で、お前は気づいているよな？

windowsはグローバル変数だから当てはまるけど、
var elm = document.getElementById('id'); なら
ローカル変数になるから当てはまらないということを

今更ながら訂正すると

function foo() {
　var a = [巨大な配列];
　var elm = document.getElementById('id');
　elm.addEventListener('click', function() {
　　　alert(a.length);
　　　alert(foo.name);
　}, false);
}

これは循環参照する。

>>677
> グローバルオブジェクト(DOM)はGCで正しくメモリを開放してくれるので考慮する必要がない事は覚えておいたほうがいい

古いIEの場合はそうとはいえない

>>674
> foo,a（JavaScript） → window（DOMオブジェクト）
「a(Script)→window(DOM)」は参照してないのでは？
aはただの配列であってスコープを持たない
a = [window]; なら参照するかもしれないが

>>678
> お、気づいたかw
あなたが気が付いてないだけで>>638から同じ指摘を何度もしている
対してあなたは何を勘違いしたのか、無関係な返答を繰り返すばかり
あなたは気が付くのが遅すぎる

>>679
「対象IEのバージョン」と「MSDNのソースURL」を教えてください
グローバルオブジェクト(DOM)を含む循環参照でもメモリリークするなら回避手段はないと思いますが、当時はどうしていたのでしょう？

>>680
関数１つ作ったらグローバルスコープの参照カウンタは回るのでは？
関数スコープの外はすべてクロージャなんだから

>>657
今のブラウザなら大丈夫なはず
自分で確かめてないからアレだけど、検証結果がこのスレ(の過去スレ)にも貼られていた

ただしハンドラ内でeval()を使ったりすると、そこを通るまでaが参照されるか不明なので
aは残ってしまうだろうね

>>683
その考え方が認められるのなら「a(Script)→foo(Script)」も成立するのでは？

function hoge () {
　var p = document.createElement('p');

　function foo () {
　　var div = document.createElement('div');
　}

　foo();
}

変数から上位スコープオブジェクトを参照可能とする場合、「div(DOM)→foo(Script)→p(DOM)」で循環参照が成立するが、勿論そんなことはない
ECMAScript 5 は関数スコープなので参照は関数単位で形成される
変数はスコープチェーンの過程で上位スコープを参照するだけ

ローカル変数はスコープチェーン上で始めに一番近い関数スコープから参照するのでグローバルスコープの参照は発生しえないね

a[1] == 1
このときaが配列じゃなかったら
Uncaught TypeError: Cannot read property '1' of null
ってエラーになりますが
a != null && a[1] == 1
って書くのが正解ですか？

>>607
エラーになるべきなら、エラーになっていいだろ？

それともaがnullになることが有るのですか？
そしてaがnullだったら、
aには何も入れないという"仕様"ですか？

>>607じゃなくて>>687

たとえばさjsonpで取得した時ですよ
サーバから正常にデータを取得出来た時にaは配列になるけど
ただしいデータが送られて来なかった場合はaはnullになります

>>690
正しいデータが送られてこなかった場合は、
エラーなんだから、エラーでいいじゃん？

なんで正しいデータが送られてこない時にまで
そのエラーを握りつぶして、無理やり動かすようなことをするのさ？

正しいデータが送られてこなかったら
エラーが発生しましたって表示させるか、
ログなどに表示して、そこに来る前に処理を打ち切るんだよ

本気でコード書いたらエラーチェックとエラー処理の方がコード量が多い事も普通

>>693
それは作り方が悪いな。
エラーを戻り値で返すパターンをやるとそうなる。
try-catchで捕まえてエラーをreturn -1とかするようなコードね。

例外を正しく使えばエラー処理のコードは少なくなるし、
JavaScriptの場合、window.onerrorで未知のエラーを
一括して捕まえることも出来る。

>>694
> エラーを戻り値で返すパターンをやるとそうなる。
全てのAPIでエラーコードが違う場合にはそうせざるを得ないしそれで正しい
try-catchで括るのは単に楽してるだけ

>>695
正しくねーよｗ

そういうのは、エラーコードをラップした
エラーオブジェクトを作ってthrowするもんだ。

そうすれば、エラーメッセージ等は
そのエラーオブジェクトに処理を任せられる。

そして特殊な処理をしたい場合だけcatchすればいい。

> try-catchで括るのは単に楽してるだけ
当たり前だろ。戻り値でエラーを返すやり方では面倒だから
ほぼ全ての言語に例外が搭載されたんだぞ。
楽して対応できるのだから、そっちのほうがいいだろ。

>>696
> そういうのは、エラーコードをラップした
> エラーオブジェクトを作ってthrowするもんだ。
それだったら結局同じことをやっているに過ぎない
try-catchを使えば楽になるなんて迷信だ

>>697
いや、違う。throwすることで戻り値を使わずに
コールスタックを登らせることが出来るんだよ。

一番面倒なのが「戻り値を返す関数」の中でエラーが出た場合
それをどうやって戻り値の中に混ぜ込むか、
混ぜ込んだ戻り値の中からどうやってエラーを判別するか。
そのためのコードを書くのが面倒。

例外を使えば、そのことを一切考える必要がなくなるし、
エラーをログに出力する場合でも、windowのonerrorが利用できるようになる。

だから特殊な処理をしたい時だけ対応コードを書けば良くなる。
逆に言えば、ほとんどの対応不可能なエラーに対して、
書かなければならなかったコードが大幅に減る。

>>691
正しくても正しくなくてもHTTPコードが同じでJSONを受け取るものとお考えください

>>699
正しくても正しくなくてもJSONを受け取るというのなら
そのようにコードを書いて下さい

json = fixJson(json);

>>698
> だから特殊な処理をしたい時だけ対応コードを書けば良くなる。
> 逆に言えば、ほとんどの対応不可能なエラーに対して、
> 書かなければならなかったコードが大幅に減る。
それはtry-catchの使用に関わらず一般論だ

関数内のどこでどんなエラーが発生したかを記録してエラーコードに含めて
なおかつ後処理もする事を考えると、try-catchを使わないと作りが悪くなる
本質的な理由が分からん

未知のエラーを上にぶん投げたいだけだろ

> 未知のエラーを上にぶん投げたいだけだろ

それが重要なんだって、

既知かつ対応可能なエラーは数が少ない。
それに対して未知は、未知なんだから無限にありえる。
だから未知のエラーに対応するのは不可能
（せいぜいメッセージを出してログに記録するだけ）

そんなことをしているから、
エラーチェックとエラー処理の方がコード量が多い
なんてことになるわけ

それに関数内のどこでどんなエラーが発生したかなんて
例外を使っていれば、自動的に記録される

>>700
ということでa != null && a[1] == 1とかいたんですがもっといい書き方ありますか？

>>703
a[1] == 1 こう書けばいいよ。

aにnullが入ることはない。
そのように作りなさい

そしてふりだしに戻る

たぶん、一行で書く俺頭いいって思ってるんだと思うね。

不正なJSONデータを直したいのなら先に直しておくべきで、
正常でも不正でも扱えるコードを書こうとか考えるほうがおかしい。

>>703
a && a[1] == 1 でOK

>>707
それだと、aがnullのとき、a[1]に1が入らない。

> 正しくても正しくなくてもHTTPコードが同じでJSONを受け取るものとお考えください
って書いたのをお忘れですか？

if (a === null) {
　return;
}
a[1] = 1

って書けばいいじゃん。

aにnullが入っているのに、そのまま処理を
続けようとするほうがおかしい。

>>687
JSONの仕様に対応できてないね
(a != null)は
a=trueでもa=1でもa="hoge"でも真だから不完全
try-catch使っとけばいいよ

>>708
誰が誰だかわからないけど、とにかく a に何か入ってることが確かなら a[1] == 1 だけでOK。

>>702
> それに対して未知は、未知なんだから無限にありえる。
アホかそんなわけない
考え方が根本的におかしかったんだな

>>702
> それに関数内のどこでどんなエラーが発生したかなんて
> 例外を使っていれば、自動的に記録される
デバッガ上でなくて本稼動してるのに自動で記録されるとは知らなかった
そして本稼動ではエラーを垂れ流すんだな

>>709
それ、a != null && a[1] == 1と同じ事じゃん

>>687
aの変数初期化処理でaに入りうる型が確定するのでその時点で処理すべきです

>>690
JSONパーサがデータを返す時点で分岐処理させて下さい
JSONパーサのが返しうる返り値、返り値として期待する型、[[]Class に依存します]
もし、JSONパーサの返り値で配列を期待するなら Array.isArray で配列とそれ以外を区別して下さい
そうでないなら、あなたの期待する処理を整理すべきでしょう

もうjavascriptの質問じゃないかもしれませんが
hoge.htmlを開いてなくてもブラウザさえ起動してれば動いて
hoge.htmlを開いた場合にはjavascriptの関数を実行したりする機能ってありますか？
chromeの拡張機能だけ、operaだけでしか動かないとか何でもいいので

hoge.html は自分のPCにあるの？それとも、ドメイン関係なく外部サイトの /hoge.html ?
ローカルにあるなら hoge.html に埋め込んで、onload で実行するようにできるし、後者なら greasemonkey を調べてみるといいかも。

>>714
無理やり一行で書くなって話だよ。

>>712
アホはお前だな。

プログラムっていうのはな、すべての行でエラーが
起こりえるという前提で作らないとだめ。

そんなの不可能と思っているならば、
お前が例外ではそれが可能だってことを知らないだけだ。

外部サイトのです
詳しく言うと
hoge.html/?watch=1
hoge.html/?watch=2
hoge.html/?watch=3
を開いてる時3つそれぞれfunction nanika()実行するのではなく
各ページではなくブラウザで一つのfunction nanika()を実行してwatch=1〜3に結果を届ける事が出来れば面白いなーと思いまして

>>719
tryの行やcatchの中で起こりえるエラーにはどうやって対処するの？

そもそもtry〜catchはそう言う目的で登場した訳ではないだろ、短く書けるとかは副作用

「未知のエラー」というのは調査してないからそう感じるのであって「既知のエラー」にすれば問題ない
全ての例外は仕様で規定されている為、入念な調査を行えば「既知のエラー」となる
よって、仕様を理解できれば例外が発生しないようにコーディングすることは可能
例外を catch しないと判定できない状況もありえない訳ではないが、そこまで多くはない為、try-catch を基本とする必要性は皆無

>>719
？？？
>>721と同じ事言ってるけど…

間違えた。。。
>>719
？？？
>>712と同じ事言ってるけど…

>>720
chrome　拡張機能　バックグラウンドページ

>>722
> 「未知のエラー」というのは調査してないからそう感じるのであって「既知のエラー」にすれば問題ない

未知のエラーは、どこまで調査すれば無くなる？
未知のエラーが無くなったことなんか調べようがない。
今はなくても、将来ライブラリやWEB APIの仕様で追加されるかもしれない。

だからまず、未知のエラーに対して処理する汎用的なコードを書く。
これが第一歩。

ただし、この未知のエラーに対するコードを、例外ではなく戻り値で管理すると、
戻り値はエラー専用になって、本来使いたい戻り値として使えなくなってしまう。
また、自動で上に投げられないから、手動で上の関数にreturnするコードを書かなくなってしまう。

つまり戻り値のやり方では、汎用的なエラー対策コードは書けないか
書いたらすごく大変なものになる。

戻り値でエラー処理をしようと思うから以下の様な発言になってしまうだよ。
> 本気でコード書いたらエラーチェックとエラー処理の方がコード量が多い事も普通

正しく例外を使えば、エラーチェックとエラー処理のコードは大きく減る。
対応の必要があるところだけ、対応すればいいからね。

>>726
全部込みのオブジェクト返せばいいよ
非同期対応のAPIもcallbackからオブジェクト帰ってくるじゃん

バックグラウンド機能ってクロームだけなんだろうか
あれすっげぇ便利なのに

>>726
> 未知のエラーは、どこまで調査すれば無くなる？
仕様書を見て仕様書通りに実装すればなくなる

>>726
> 今はなくても、将来ライブラリやWEB APIの仕様で追加されるかもしれない。
仕様はある時、突然勧告されるわけではない
勧告前の仕様もチェックするようにし、先行実装された実装でテストしておく
既存仕様との差異が既存コードに影響するようならそこで修正すればよい

> だからまず、未知のエラーに対して処理する汎用的なコードを書く。
どんな条件でどんなエラーが発生するかわからずして、対策コードは書けない し、時間の無駄

>>729
じゃあ、バグはどうする？
プログラムは一人で作るものじゃない。

誰かが作った部分にバグでエラーが発生した時、
バグなのだから当然仕様には明記されていない。

こういう場合にどうやって、エラーが起きたことを補足して
途中で中断するのさ？

>>730
> どんな条件でどんなエラーが発生するかわからずして、対策コードは書けない し、時間の無駄

書けるよ。簡単に。

時間の無駄だと思うのは、戻り値なんかで
エラー処理してるからだよ。

言葉じゃなんとでも言えるから、実際のコードで書いてみて欲しい

まあ、完全に答え出てるんだよね。

一方は、私のやり方ではエラー処理が大変で時間がかかって対応しきれません。って言ってる。
もう一方は、私のやり方ならエラー処理は簡単で未知も含めた全てのエラーに時間を書けずに対応できます。と言ってる。

>>726
全てを「未知のエラー」でひっくるめるようなら、それが下記のいずれかを区別出来てない事になるな

1. 仕様変更によるエラー
2. 元々、実装依存の挙動で特定の実装に依存するコードであった為のエラー
3. 特定の実装で未対応だった機能が有効化された事によるエラー

仕様を正しく理解してコードを書けば、将来的にも 2. と 3. によるエラーは発生しない
確認しなければならないのは 1. だけなので、コード修正は最小限で済む

>>733
そうだね。じゃあ書いてみようか。

関数が4つ有るとする。main()がfoo()を呼び、foo()がbar()を呼び、bar()がbaz()を呼ぶ

function main() {
　foo();
}

function foo() {
　bar();
}

function bar() {
　baz();
}

function baz() {
　・・・
}

これはエラー処理を書いていないコードだ

まず、以下の理由

> 本気でコード書いたらエラーチェックとエラー処理の方がコード量が多い事も普通

俺とっては、はぁ？ｗ だが、
まあ、例外を知らないやつはこう思っている奴が多い。

エラーをどう戻り値で返すか？ は関数によって違う。
例えば数値型を返す関数なら、nullやNaNを返すかもしれない。
内部で起こった詳細なエラーを、エラーコードで返すかもしれない。
まあ色々なわけだ。

じゃあ、戻り値でエラーを返すと、エラー処理のほうが多くなるという
実例をおみせしよう

function main() {
　if (foo() === null)
　　alert('エラーが発生しました');
　　return;
　}
}

function foo() {
　if (bar() < 0) {
　　alert('エラーが発生しました');
　　return null;
　}
}

function bar() {
　if (baz() === ERROR_CODE1) {
　　alert('エラー1が発生しました');
　　return -1;
　}
　if (baz() === ERROR_CODE2) {
　　alert('エラー2が発生しました');
　　return -2;
　}
}

function baz() {
　・・・
}

ほらね？ （戻り値でエラーを返すと）
エラー処理のほうが長くなってしまう。

まったくもってそいつのいうとおりだよ。
エラー処理のほうがこんなに長い！

しかもこれは別の問題が有る。
baz()でエラーが起きたら何度もエラーが表示されてしまう。

それを防ごうと思えば、また別の処理を入れないといけない。

そいつの言うとおり、戻り値でエラーを返すと
こんなにもエラー処理が長くなってしまう。

じゃあ、例外を使うよー？

function main() {
　try {
　　foo();
　} catch(e) {
　　alert(e.message);
　}
}

function foo() {
　bar();
}

function bar() {
　baz();
}

function baz() {
　・・・
}


はい、おしまい。

windowのerrorイベントを使えば、mainの中にも何も書かなくていいよ。

これで、bazでエラーが起きたら、ちゃんと途中で処理を中断して
一度だけメッセージを出してくれる。

もし途中で中断したくなければ、
その時だけ処理を入れれば良い。

根本的に何も理解してなかったのか…

try〜catchはそういう目的に使うものではない。発生点と捕捉点を明確に区別して、コードの質を上げるのが一番の目的だ。

以前「どの行にもエラーが起こる可能性がある」ってかいてたが、上のコードではfooやbarが発生点になるエラーが何も書かれていないから、そこで起こりえるエラーを捕捉するにはそこにも「エラーが起こる可能性がある」と考えて、追加のコーディングが必要。

さらに言うとcatch節の中にも「エラーが起こる可能性がある」訳だから、そこで起こったエラーはどうするんだ？

プログラム全体をtry で囲めばあらゆるエラーに対応できるが
そんなことをするなら不正終了させたほうがいいわなw

try〜catchは遅いから使うなとこのスレで教わりました
でもGoogleやその他大手IT企業も使ってました
否定派は3流プログラマなんでしょうね

本当のエラー処理で使ってるだけじゃね
遅いっていうのはエラー処理じゃないところで使うやり方のことじゃないの
知らんけど

全てに try-catch を使ったら native 関数の TypeError, SyntaxError...etc も catch するじゃないか
例外が発生して欲しい部分までエラーを発生させないコードなど、有り得ない

例外野郎は
エラー処理＝例外で補足するもの
と考えてることに致命的な欠陥がある

まともなプロダクションレベルのプログラム書いた事ないんだろうな…
エラー処理というのはエラーが発生した際に何らかの処理中だったら安全に中断させるとか
ユーザーにリトライを促す処理に移行させるとか、自動的にリトライを繰り返すとか
その際にリソースを適切に解放させる処理とかの事だ
糞面倒臭い事をたくさん書かなくちゃいけなくなる (出来のいいシステムにするにはだが)

try-catchで短くなる(ｷﾘｯっていったい何を言ってるんだといいたい

>>743
盲目的に使え(使うな)って覚えるのがダメなんじゃね？
「大手企業がそうしてるから自分もそうする」とか 。

なんだ、try{}catch{}で遅いループを速くするバッドノウハウも知らんのか。ショボｗIE5が出て程なく発見した俺より15年遅れている。

>>740
何もしなくてもコンソールにエラー内容が該当行と共に表示されるんだけどね
コンソールは誰でも見てる

>>731
> じゃあ、バグはどうする？
それは「自分で書いたコードのエラー」
仕様から読みとるのは「native関数のエラー」

あなたが言及した新機能APIへの対策は後者
一つの問題(後者)の話を棚に上げて、新しい問題(前者)を持ってくるべきではない

>>738
bar() でエラーを発生させるなら foo() で改めてエラーを発生させる必要はない
エラーの所在をはっきりさせないからこんなコードになる
foo, bar の要求仕様が確立されていれば、「foo で発生させるエラー」と「bar で発生させるエラー」は明確に区別されるはずだ
Array.prototype.forEach と Array.prototype.filter を組み合せた時、各メソッドで「同時に同じエラーが発生する」ことはないのと同じ

結局、このスレの総意はtry-catch使うなってことでいいの？
あと本当のエラーって抽象的な言い方じゃなく具体的なコード出して示してみろよ

全てのコードをtry-catchで囲って「はい、全てのエラーに対応したよー」っていうやり方が馬鹿だってことでしょ
try-catch自体は否定されてないように思うが

全てのコードってどういうこと？
具体的なコード示してみてよ

>>740のコードのこと。

相変わらずこのスレの馬鹿乙合戦は物凄い勉強になる

なんか反論（エラーを戻り値で返すときの素晴らしい方法）を
書いているかと思えばやっぱりソースコードを書いたのは俺だけだったね。
使えねぇな。

>>751
まず最初に修正したソースコード書いてね。

>>755
それはbuz()でどんな処理をしてるかで決まるんじゃ・・・
ちゃんと自分自身のコード出してよ
try-catch使わないコードも一緒にね

>>752
> 結局、このスレの総意はtry-catch使うなってことでいいの？

いや、なんのために、try-catchが言語仕様としてあるのかとｗ

昔、例えばC言語にはないんだよ。
それで苦労した歴史がある。

新しい言語には漏れ無く、try-catch相当の仕様が言語にある。
try-catchは何のための機能か？当然エラー処理のためだよ。

エラー処理専用の言語仕様が、新しい言語には漏れ無く付いている。
それはこの機能が極めて有効だってことを意味するんだよ。

>>759
ちゃんと書いてほしいよね。

エラーを戻り値で、つまりエラーコードで返す場合。
俺はすごく疑問なんだ。


数値を返す関数の内部でエラーが起きた時、
一体、何を返すのか？
NaN？ null？ undefined？

しかしこれではエラーコードは返せない。
詳細な理由はわからない。
さては文字列を返すのか？

しかし、今度は文字列を返す関数でエラーが起きたらどうするのか？
今度は、エラーコードを返すのか？

エラーの値が統一されていない。
関数によって、エラー処理の方法を変えるのか？

どれだけ大変なことをしているんだろう。

実際に書いているコードを見てみたいんだよね。

ちなみに、コンシューマーゲーム機のゲームはほぼ全部C++で作られてるけど
コンパイラの例外処理と実行時方情報(RTTI)はデフォオフられてる

さらにSDKの全APIは厳密にエラーコードが定義されてるが、それを戻り値で返す
例外を返すAPIは全く無いし、例外処理(try-catch)を遣ってるゲームも皆無だろう

ゲームに突然例外が発生しましたはありえない
ありとあらゆる状況で正しく動作する事が前提で、全てのSDKのAPIは
基本的に戻り値をチェックしてエラーが返ったら何らかの対処をする必要がある

>>759
＞それはbuz()でどんな処理をしてるかで決まるんじゃ・・・
あれ、>>740は汎用的なエラー処理の方法として書いたんじゃなかったのか？
buz()の処理内容次第では>>740が使えなくなるのなら、>>740はどういう意図で書いたんだ？

突然コンシューマ機の例を持ってくる馬鹿がいてワラタ
JavaScriptは特定の環境だけで動作するものなんですかねえ？

>>762
> ちなみに、コンシューマーゲーム機のゲームはほぼ全部C++で作られてるけど
> コンパイラの例外処理と実行時方情報(RTTI)はデフォオフられてる

うん。知ってる。らしいね。
理由は、究極的に速度が必要だから。

で、このスレの内容には当てはまらない
例外の話なんで、消えてくんない？

>>763
> buz()の処理内容次第では>>740が使えなくなるのなら、>>740はどういう意図で書いたんだ？

baz()の処理内容で使えなくなるのは、>>738だよ。

もしbazがが新たにエラーコードを追加した。ERROR_CODE3ね。
そしたらbarはそのままでは使えなくなる。

barを修正すればいいけど、あぁ大変だ。

さて、ERROR_CODE3を追加するだけならまだ楽だ。

もしbazの中で新たに、そうだね例えばlocalStrorageを使って
キャッシュさせる処理を実装したとしよう。そうすると、bazは例外を出すようになる。
例外を使ったコードにしていれば楽だが、今は戻り値でエラーを返す場合の話だ。

localStorageのエラーをERROR_CODE4として追加するのか？
localStorageがだすQUOTA_EXCEEDED_ERRというエラーをERROR_CODE4とし、
その他のエラーは・・・あぁ、調べるのが面倒くさい。だが戻り値で返すならば全部調べないとな！がんばれよ！

エラーコードだけならまだいい。エラーメッセージはどうしよう。
localStorageは"An attempt was made to add something to storage that exceeded the quota." という
エラーメッセージを例外オブジェクトの中に入れてくれる。

しかし、エラーを戻り値で戻すならエラーコードしか戻せない。
さてどうしよう。

baz()の処理内容次第で>>738だとどんどん悩みが増えていく。

まあさ、>>740と全く同じ動きをするコードを
戻り値で返したらどうなるかを書けば、
どれだけ、戻り値でエラーを返すコードが冗長になるかわかるよね。

>>738は>>740と全く同じコードではない。
手抜きをしたのに>>738だ。


反論したいなら、>>740と同じ動きをするコードを
例外を使わずに書いてみれば良い。

そのコードが>>740とほぼ同じ行数でかけたら感心するよ。
（もちろん行数稼ぐために;で無理やりつなぐのは無しｗ）

>>763
はやくコード出せよ

>>767
うーん言いたいことは分かったけど、それって単に>>740はエラー対応してないから短いだけじゃないの？
catchするだけcatchして、それからどうするの？って話。
むしろ個々に対応したエラー処理を省いている分、手抜きしてるのは>>740の方じゃないのか。

>>742でも指摘があるように、エラーメッセージを出すだけの目的なら、try-catchで囲まずに例外をコンソールに吐き出すのと大差ない。
エラーコードを吐く方法がいつもいいとは言わないけど、>>740が最善とはとても思えない

>>768
俺が言いたいのは、全てのエラーを>>740の方法で片付けるのがおかしいっていうこと。
万能なエラー対応方法はないから、コードの提示のしようがない。
例題を出してくれたらいくらでも答えるけど。

JavaScriptでは非同期処理が多用されるわけだけど、
それの異常系もtry/catchでなんとかなると思っているんだろうか

>>770
だから、お前の思う最善の例を出してみろって。
それが出来ないなら単なる戯言でしかないからもうレスすんな

>>772
戯言に反論できないからと言ってムキになるなよ

>>773
あーやっぱりコード出せないのか
馬鹿はもうレスしなくていいよ

>>774
馬鹿に反論できなくて悔しいのは分かった

>>775
まずお前が理解できてるか確認する為に、具体的なコードを出してみ？
そしたらいくらでも反論してやるよ
馬鹿だからどうせ出せないんだろうけど

>>776
さっきも言ったけど、>>740のような万能な対応方法はないというのが主張だから、例を挙げてもしょうがないと思うが…

document.getElementById("hoge").style.color = "red";
このコード、もし#hogeが存在しない場合、try-catchで捕捉できる。でも、いつもそれが正しいと言える？

こうしたい時だってあるはず
var elm = document.getElementById("hoge");
if(!elm){ /* #hogeが存在しないことに対する対応。#hogeを作成するなりなんなり。本当に例外にしたいならthrowする */ }
elm.style.color = "red";

あとは>>771のいうように、setTimeoutやXMLHttpRequestなど、非同期のものはtry-catchでは対応できない。

>>758
・foo, bar, baz の役割がわからん
・main() -> foo() -> bar() -> baz() と連鎖して呼び出す意図がわからん
・ERROR_CODE1, ERROR_CODE2 がどこで定義されてるかわからん
・エラー1, エラー2 では内容がさっぱりわからん
・エラー1, エラー2 で例外を発生させるべきか判断材料がなくてわからん
全くもって情報不足過ぎるが、適当に想像で補完するならこう

function main() { foo(); }
function foo() { bar(); }
function bar() {
　switch(baz()) {
　　case ERROR_CODE1:
　　　throw new Error('エラー1が発生しました');
　　case ERROR_CODE2:
　　　throw new Error('エラー1が発生しました');
　}
}
function baz() { }

あくまで想像なので適当であり、一つの例に過ぎない

「未知のエラー」はどこへいった？
>>740では「未知のエラー」に対応できてないんだが、どんなエラーでも対応できる汎用的な方法じゃなかったのか？
コンソールデバッグと何もかわらんではないか

全体をtry〜catchで囲うことへの反論は>>741>>742>>745>>746>>749にもあるぞ
スルーすんなよ

そもそも、>>738と>>740では比較対象にならない
>>738はユーザ定義のエラー処理だが、>>740はただの例外処理(ユーザ定義のエラー処理がない)
比較するなら、>>740と「>>740からtry-catchを削除したコード」だろう

>>729-730,735にも返答が欲しいところだな
将来的な仕様変更に>>740では対応できてない事だしな

>>765
速度も重要だが
> ゲームに突然例外が発生しましたはありえない
という方が重要

全てのエラーを捕捉して対処する事に意味がある
try-catchを使ったからと言って簡単になるわけではない
↓これをtry-catchで簡単にしてみて (hoge()やhage()が例外を投げる前提)
var res = hoge();
if (res >= 0) {
// 成功
} else {
// なんらかのエラー
switch (res) {
case -1:
// なんらかのエラー処理1
break;
case -2:
// なんらかのエラー処理2
break;
case -3:
// なんらかのエラー処理3
break;
default:
// 未知のエラーの為の処理
break;
}
error(); // 共通のエラー処理
return errorCode;
}
var res = hage();
// 以下同じような処理が続く

>>726
> 未知のエラーは、どこまで調査すれば無くなる？
逆に聞きますが、仕様書を読んで「既知のエラー」にする対策はとらないのですか？
しないとしたらそれはなぜですか？

最初JSONの破損チェックの話じゃなかったっけ

(o.a.b.c.d.e.f.g.h.i.j.k.l.m.n == 1)
このテストで
アホみたいに先頭から順番にif文で確認するのもいいけど

try{
　if(o.a.b.c.d.e.f.g.h.i.j.k.l.m.n == 1){
　}
}catch(){
}
全部囲めば楽だよねって話

>>785
> 最初JSONの破損チェックの話じゃなかったっけ
>>690はそんな話はしてない

>>785
それのどこが未知のエラー？
知らないなら ES5 仕様書を読んでくるといいと思うよ

>>786
そんな話と思うけど>>687

もうjavascript関係無いな、いつの時代の議論だよって感じ

try〜catchやエラーコードに関するコードを書かないのは、もう何十年も議論され尽くされててちょっと探せば沢山コードなんて見つかるのに、今更「ソースまだぁ？」とか言う勉強不足野郎に呆れてみんな書かないんじゃないの？少なくても俺はそうだ

try〜catchの誕生した背景と解決しようとした課題、そして新たに出てきた問題とか色々引っくるめて結論だけ言うと

「適材適所で使い分けろ」

だ。銀の弾丸なんで存在しない。コードが短くなるから〜とかスビードガァとか、そんな短絡的な理由でどっちが優れてる！使うべき！とか、レベル低すぎるんだよ

>>777
> document.getElementById("hoge").style.color = "red";
> このコード、もし#hogeが存在しない場合、try-catchで捕捉できる。でも、いつもそれが正しいと言える？

正しいじゃんか。

このコードは、#hogeが存在しないことはありえないってことだろ？
アプリの仕様として#hogeが存在しないことはありえないなら、
こういうコードを書いていいし、
ありえないことが起こってしまった場合（おそらくバグだろう）
それはエラーになるべきだ。

それこそが、未知のエラーよ。

こういう未知のエラーに対して汎用的なコードを用意しておけば
ユーザーのシステムエラーが起きたことを通知したりログをとったり出来る。

> こうしたい時だってあるはず
> var elm = document.getElementById("hoge");
> if(!elm){ /* #hogeが存在しないことに対する対応。#hogeを作成するなりなんなり。本当に例外にしたいならthrowする */ }

これは意味が変わってる。アプリの仕様として
#hogeが存在しない場合がありえるときにこう書く。

>>777
> あとは>>771のいうように、setTimeoutやXMLHttpRequestなど、非同期のものはtry-catchでは対応できない。

じゃあ、戻り値でエラーを返す方式なら対応できるんですかー？

非同期のものは処理が開始されるタイミングが違うだけ。
その中でtry-catchをするんだよ。
どうせ戻り値でエラーを返してもそうするだろ？

「処理が開始されるタイミングが違う」という両方とも同じことに対して
try-catchだけの問題みたいにいうな。

>>783
お前、設計がおかしい。

そもそもエラー毎に個別のエラー処理が必要になることはまず無い。
そのの処理はこうなる。

try {
　var res = hoge();
　var res = hage();
} catch(e) {
　共通のエラー処理
　throw e; // エラー再送信
}

その上で重要なのは、例外は深い階層から一気に
上の層まで処理を飛ばせること。
発生したエラーを画面にalertでだすか、
console.logにだすか、サーバー側に通知するかはアプリ次第。
どうするかは、一箇所にまとめるべき。それがonerror

もし上の処理が、foo -> bar -> baz の中の処理だった場合、戻り値でどうやって処理を中断させるのか？

もし上の処理が、foo -> bar -> baz の中の処理だった場合、戻り値でどうやって処理を中断させるのか？

function foo() {
　bar();
　// 正常時の処理
}

function bar() {
　baz();
　// 正常時の処理
}

function baz() {
　var res = hoge();
　var res = hage();
　// 正常時の処理
}


もしどこかでエラーが起きた場合、例外であればちゃんとそこで
returnしたような動きに出来る。

これを戻り値で書くとこうなる。大変だよなぁｗ

function foo() {
　if (!bar()) {
　　return;
　}
　// 正常時の処理
}

function bar() {
　if (!baz()) {
　　return;
　}
　// 正常時の処理
}

function baz() {
　var res = hoge();
　if(!res) {
　　return;
　}
　var res = hage();
　if(!res) {
　　return;
　}
　// 正常時の処理
}

ほら、戻りを使うと、もうコードが倍になっちゃうｗ

>>790
エラーのログを取るのが目的だったのか？>>740はエラーに対応する万能の方法じゃないのか？

>>792
>>792
＞そもそもエラー毎に個別のエラー処理が必要になることはまず無い。
それはお前の思い込みだ
もしこの考えを変えないのなら、お前と議論する意味はない

>>794
なぜ「例外がある⇒returnで中断すれば問題ない」という短絡的な思考になれる？

例外野郎は>>789を100回読んどけ
はっきり言ってこの言い争いは低レベルすぎるし無駄だ

>>788
何も破損してないだろう？
>>690は a が配列ではなかったら null が入るといっている
であれば、下記コードで事足りる

if (a) { }
　又は
if (Array.isArray(a)) { }

どういう処理をしたいのか知らないが、処理を停止させたいなら TypeError を発生させるのも一つの手段