+ JavaScript の質問用スレッド vol.123 + [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
+ JavaScript の質問用スレッド vol.122 +(c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1420095379/
（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです） DOM操作だけのサブセット ＝ jQueryの中から必要な物を厳選 ＝ jQueryの機能の殆ど ＝ ならQueryでいいじゃんｗ
jQueryはよく絞り込まれてるよ。どのメッソドもほしいもの。 >>641
どこがどう分かってないのか説明よろ。
>>642
それちきんとコード比でも見て言ってるの？ document.queryAll('.class').forEach(el => el.remove());
を正しく書くなら
Array.prototype.forEach.call(document.querySelectorAll('.class'), el => el.parentNode.removeChild(el));
だな
議論に参加しようと思ったら突っ込まれるところを作ってはいけない >>643
> どこがどう分かってないのか説明よろ。
せめて動くコードを書けって言ってる。
想像の中で動くであろうコードを書いて、ほら短いといっても、
それはお前の頭んなかの想像の話だろｗってことだ。 > el => el.parentNode.removeChild(el)
この書き方は現状Firefoxでしか動かないから、これが現実的なところだろうね。
Array.prototype.forEach.call(document.querySelectorAll('.class'), function(el) { el.parentNode.removeChild(el) });
この後、メソッドチェーンしたいんだけど？と言われたら（笑） >>644
話の流れ的に紛らわしかったかもしれないけど、よく見て。
NodeListを返すquerySelectorAllじゃなくて、Elementsを返すqueryAllを使った。
ElementsはArrayを継承してるからforEachが直に使えるでしょ？ >>646
メソッドチェーンしたければmapを使えばいいよ。 >>647
え？ remove()は？
もしかして、お前の想像の世界ではあるって
ことになっんの？
想像の世界の技術で反論（笑）
そんな感じで、さまざまなメソッドを
オレオレライブラリで作るんだろう？ｗ
だったらjQueryでいいじゃんってなるって
最初から言ってる。 >>648
だから動くコードを書けって言ってる。
結局書くと、ばれるのが怖いんだよ。
だから、擬似コード書いて
勝った気になってる。 $('.class').remove();
Array.prototype.forEach.call(document.querySelectorAll('.class'), el => el.parentNode.removeChild(el));
可読性が大きく違いすぎるｗ >>649
Elementはremove()を持ってるよ。 >>647
適当なこと言ってすまなかった
DOMのLS見てきたけど、今までとかなり変わってて驚いた
勉強し直してくる >>652
> オブジェクトは 'remove' プロパティまたはメソッドをサポートしていません。
説明してくれるかい？ 各ブラウザ間の互換性を取るための
ライブラリが必要だな！
jQuery（ボソッ） >>650
queryAllはまだどのブラウザにも実装されていないけど、モダンブラウザかIE11以降でエミュ可能。
removeはChromeとFirefoxで入ってるのを確認した。
ES6の構文は必要ならトランスパイラを使えばいい。
自分が問題視しているのは、学習コストとそれが古いものになることでの無駄。
もう標準が用意されるってわかった時点で、その機能はポリフィルに切り替えて行くべきだと思ってる。 いや、だからjQueryでいいでしょ？
結局お前が示したコードよりも、
さらにjQueryの方が短くて、
どのブラウザでも動くんだし。 どんなに頑張っても可読性はjQuery ＞ DOMだからねぇ。
DOMの進化が10年遅すぎた。
その10年の間にjQueryは誰もが持ってる必須の知識となってしまったし、
DOMを使った結果、jQueryより劣ることしかできないんじゃ
なんのためにDOM使うのか理由がない。
せめてこれぐらいは、DOMでも25文字ぐらいでできてもらわないとね。
$('.class').remove(); >>655
それは当然大事。
ただ、jQueryが生まれた当初と比べて、互換性がまだまだ取れないという点は未だ残っているが、
そもそも標準機能が不足してるという点は改善されてきてる。
各機能の有り様について標準が提供されているときは、それに従うべきだと思う。
そうするとライブラリというよりポリフィル的なものになる。
そういう意味ではjQueryはとりあえず使っとけと言うものでは無くなった。
特にjQueryは標準にかなり影響を与えていて、標準がjQueryを改善した、
似てるけれど少し違うものを用意しているという問題もある。
つまりjQueryのAPIは腐ってきてるということ。
ただしDOMAPIもそれほど豊富なわけではないのでまだまだDOM操作のフレームワークやライブラリは必要。
とはいえ比較的基礎的なAPIを提供するjQueryをわざわざ使う価値と、合うケースは減ってきてると思う。 $ → $ = document.queryAll.bind(document)
on → ES7を先取りしてObserableに切り替える
でいいんじゃない Observableな感じを思い浮かべるとメソッドチェーン指向ってのは正しい気がする
そういうスタイルで書くならやっぱり同期メソッドもチェーンで書きたいよね
でもObservableとjQueryを組み合わせるのは難しそう
ここを標準に期待するのは無理だから、おそらくまたどこかのいいライブラリがデファクトスタンダードになって
それを標準が追いかけるようになるんだろうね
いつまでたってもライブラリからは逃れられずに時代は繰り返される あーでもExtensible Webに則るとそういう世界であってるか もしElementsにElementのメソッドつけようと思ったらこんな感じになる？
Elements.prototype.__proto__ = new Proxy(Array.prototype, {
get(aryProto, key, elems) { return (key in aryProto) ? aryProto[key] : (...args) => elems.map(el => el[key](...args)) }
}); あまり知られてないがスムーススクロールも標準でできるようになったんだよな。
http://dev.w3.org/csswg/cssom-view/#enumdef-scrollbehavior
Chでようやく認識するようになった段階で動くのはFxくらいだが。 >>663を試そうと思ったけど、なぜか手元のFF37だと上手くいかない…。
原因を調べるとどうやらprototypeとproxyを組み合わせると上手く動かない。
var o = Object.create(new Proxy({ hoge: 1 }, {
get(){ return 2; }
}));
console.log(o.hoge); // 2
console.log(o.fuga); // なぜかundefined???
これはバグ？ >>663
標準化される前に、標準のprototypeを拡張するのはよくないよ。
あとから標準化された時に名前がかぶっていたら互換性の問題が発生する。
Prototype.jsがそれで痛い目にあってる。
http://qiita.com/jwhaco/items/b5b474883d3020f6dc5f
標準のprototypeを拡張するぐらいなら、
独自のオブジェクトでラップした方がいいと思う。
それがjQueryでやってることでも有る。 良いも悪いもElementsを拡張しようと思えばそうするしか無いでしょ。
まあサブクラスを作るのが一番筋がいいと思うけどな。 > まあサブクラスを作るのが一番筋がいいと思うけどな。
それを実現しようと思ったら、document.getElementsByNameの
戻り値をサブクラスにするってことになるんだけど、
getElementsByNameはdocumentだけにあるものじゃない。
すべての要素に、getElementsByNameがあるわけだから
Elementsを拡張するのであれば、Elementを拡張しなければならなくなる。
もちろんgetElementsByNameだけじゃないね。getElementsByTagNameとかもそう
サブクラスを作るって言えば簡単に思えるかもしれないが、
実際には標準のDOMのElementのメソッドを書き換えまくることをしないといけない。
それで安定して動くのか？って考えると難しい話なんだよ。
だから現実には標準のprototypeを書き変えることをしない。
ブラウザという実行環境がユーザーの手にあって開発者の自由にできないものは、
開発者が自由に実行環境を決めることが可能なデスクトップアプリや
サーバーサイドアプリと同じやり方でやったらだめなんだよ。 callで置換されたthisを一時的に変更するにはどうすればいいでしょうか
例えば、
function A(x) {
this.piyo = new B(x);
this.C = x;
};
A.prototype.do = function() {
this.piyo.do.call(this); //(1)
};
function B(x) {
this.B = x;
};
B.prototype.do = function() {
console.log(this.B); // undefined
console.log(this.C); // 10
};
var hoge = new A("10");
hoge.do();
というコードがあったとします。
この時、(1)でthisをhogeとして呼び出したのでthis.Bがundefinedになりますが、
this.Bの時だけthisをpiyoとして呼び出したいのです。
(1)をthis.piyo.do();として、console.log(this.C);をconsole.log(B.C);とすると、クラス変数ではないのでundefinedとなります。 >>671
頭が硬いね。
別にそうしなくてもSub.from(hoge)としてラップすればいいんだよ。
jQueryみたいな１から作るのと違うのはElementsのメソッドを活かしながら必要な機能のみを安全に拡張できるところ。 必要な機能？
onは必要だしattrやpropやdataも必要
addもremoveも、insertもbeforeもafterもreplaceWithもだし、
eachやgrepも必要だろう。
もちろんメソッドチェーンも必要だし、
逆に必要じゃない機能ってなんだ？
結局jQueryの再実装をしているだけなんだが。 >>673
標準のDOM要素に標準化されてないメソッドを追加すると
あとで同じメソッドが標準のDOM要素に追加された時困るから
やるべきじゃないよ。
継承しても一緒。継承元に有る標準のメソッドを
オーバーライドしてしまうことになる。 >>675
オーバーライドしてしまうのなら問題ないよ。
>>663が問題なのはオーバーライドしないことで、同名の標準ができた時に壊れることだから。
それに標準のものには追加してないでしょ。
別個体のサブクラスに明示的にラップするという操作を伴うものだから、他への影響はないよ。
誰かがしちゃいけませんって言ったことを理由も考えずに信じ続けるのは良くない。 >>676
> オーバーライドしてしまうのなら問題ないよ。
おいおいｗ 問題を認識してないのかよ。
DOM非標準のものならば、自分しか使わないから問題ないが
DOM標準の場合は、オーバーライドしてしまったら
他のライブラリが改変された関数を使ってしまうかもしれないだろ。
だからjQueryなどはDOMとは全く別のオブジェクトで
ラッピングするという手法をとっているのだが。
話をまとめるか？
1. 標準のElementsにはattr()というメソッドはありませんでした。
2. だから標準のElementsを拡張してattr()を追加しました。
3. このattr()は当然オレオレ実装です。
4. あるときElementsに標準仕様でattr()が追加されました。
5. オレオレattr()と標準attr()で仕様が違いました。
6. 他のライブラリは標準attr()だと思ってるのにオレオレattr()が呼び出されて困りました。
こういう話なんだが。これprototype.jsで実際に起きた話な。
で、お前はサブクラスなら問題無いと言っているわけだが、
サブクラスでも問題有るんだよ。なぜならElementsを返すのは誰？って話。
例えばdocument.getElementsByTagName()だけじゃなくて
全ての要素.getElementsByTagName() やその他多くの全て。
すべての要素のgetElementsByTagName()だけでなく、
createElement('div') で作られた要素のgetElementsByTagName()も
サブクラスを返すように改変しないといけない。
そうすると、DOMのElementのprototypeを改編する話だってのはわかるな？ >>677
＞＞サブクラスを返すように改変しないといけない
だからそうじゃないって言ってるだろ。
>>673を見たのか？
逐一Elementsをサブクラスにラップして使うやり方について言ってるの。
だからElementsを利用してる他のものに影響を与えることはない。
まず人の話をよく聞いてから批判しような。 >>678
あんたたサブクラスとラップという用語を
ちゃんとわかってないって言うことがよくわかったよｗ
ラップするならばサブクラスにする必要はないし普通はしない。
jQueryはDOM要素郡（そこでいうElements）をラップしたもの。 > jQueryはDOM要素郡（そこでいうElements）をラップしたもの。
正確に言うならば、jQueryの$()などで返すjQueryオブジェクトは
DOM要素郡（そこでいうElements）をラップしたもの。 そもそもElementsを何のサブクラスにするって言ってるんだろう？
ちゃんとわかってるなら○クラスのサブクラスにするって
具体的に言えるはずだ。 ぜひ○の中身を答えて欲しい。
先回りしていっておくと、世の中には○クラスを引数にする
関数が存在するが、○クラスを互換性がない形に改変すると
その関数の引数に入れられなくなる。（本当にサブクラスなら入れられる）
だが改変しないとメソッドチェーンが使えなくなる。 >>679
分かってないのはあんた。
Elementsに元々あるメソッドを使うためにもそうするのが一番自然、
言い訳見苦しいよ。負けを認めなさい。 >>683
> Elementsに元々あるメソッドを使うためにもそうするのが一番自然、
Elementsに元々あるメソッドって何のことだよｗ
なんのサブクラスにしたいわけ？
答えられてないよね？
> 言い訳見苦しいよ。負けを認めなさい。
ワロタｗ
勝ったつもりでいるんだｗ 元々のメソッドを使う方が絶対にいいはずだって
固定観念を持っているんだろうね。
jQueryのeachではなく、
Elements.forEach（Array.forEach）を使ったほうが
いいはずだって思ってるのだろうけど、
forEachではメソッドチェーンが出来無くなってしまうわけで
元々のメソッドを使うとjQueryからすると劣化してしまう。
劣化しないように作るとなると元々のメソッドはほぼ全て使えなくなってしまう。
ここまで考えずに、元々のメソッドを使う方が絶対にいいはずだって
固定観念を持っているんだろうね。 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >>684
queryAllとかあるでしょ。
それらを一々再実装するの？
元からあるのを使った方がいいに決まってる。
>>685
mapを使えばmapはthisのコンストラクタを見て、
きちんとサブクラスのインスタンスに結果を追加していってくれる。
他のArrayのメソッドでも同じ。
そういう意味でもサブクラスにするのは正しい。 >>687
> それらを一々再実装するの？
君はライブラリを使うってことを覚えようよｗ
jQueryが実現しているから使うだけ。
それにqueryAllが返すElementsの話だろ？
Elementsをサブクラスにしろっていう話なんだから。
queryAllがあるのはElementであってElementsじゃない。
mapがあるのはArrayであってElementにはない。
Elementsにも無い。（queryAllが返す要素の配列は、本当の配列じゃないから）
それらを一々サブクラスに再実装するの？ｗ >>688
ライブラリを使えばいいというのはそのとおりだよ。ライブラリはダメとか言ってないだろう。
そういう話ではなく、どういう手法がいいかということで、
jQueryのように丸っと世界を構築するよりも、>>663のようにするよりも、サブクラスを用意するのが一番折り合いがとれてるという話をしてるんだ。
なにを勘違いして一人で苛立ってるんだ？
そしてElements.prototype.__proto__ == Array.prototypeだし、
queryAllが返すのだって列記としたArray exotic objectだから。
ES6からはビルトインコンストラクタはnewTargetを見て適切なプロトタイプを持ったインスタンスを作ってくれるでしょ？
継承するというのはそういうことだよ。
もうホントにね、人の話は聞かない、仕様も読まない知らない、考える力もない、反省もしない。
君と話してると呆れて疲れるね。 >>689
焦点がずれてるな。サブクラスにする危険性をわかってない。
まずElementsがArrayだとしてjQueryに比べれば大幅にメソッドが足りない。
onとかattrとかきりがないから全部言わないよ？
そこでElementsのサブクラスを作ってメソッド追加しろって言いたいんだろ？
それが危険だという話。
ElementsのサブクラスはArrayでは無くなってしまうから。
なぜなら、
Elementsのサブクラスにhogeというメソッドを作った。
将来のArrayが拡張してhogeというメソッドを作った。
ElementsのサブクラスのhogeとArrayのhogeは別物
つまり、ElementsのサブクラスのはArrayではなくなる。
型あり言語なら型とシグネチャで正しくディスパッチしてくれるが
JavaScriptのような言語では無理
そして問題はまだある。
Elementsのサブクラスを作ったからといって、
queryAllがElementsのサブクラスを返してくれるわけじゃない。
DOMのあらゆるAPIがElementsの代わりに、
Elementsのサブクラスを返すようにモンキーパッチしまくらないといけない。
何かを忘れていると、よくわからないエラーが発生することになる。
危険性があるうえに、既存のメソッドを間違いなく修正するという大変な作業が必要。
サブクラスの仕様を考えただけで全てがうまくいくって考えてるようだが経験と想像力が足りないよ。 あと、想像の世界の話をしてないで
実際の動くコード書きなさい。
jsfiddleって知ってるかい？ またjQuery厨が暴れて生温かい視線を浴びてるのか。 >>690
論点がずれてるのはあんた。
オーバーライドは問題にならないという話はもう上でしただろ。
想像力がないのか？
もし万が一新しいメソッドがArrayやElementsに追加され、
それがサブクラスと被ったら、ライブラリをバージョンアップすればいいだけ。
サブクラスは元クラスのプロトタイプ拡張と違って、明示的に使ってない周りへ影響を与えないし、
環境が新しくなっても、古いバージョンのライブラリに依存してる古いコードが壊れることもない。
それと、queryAllがサブクラスを返したりすることはやらないと言ってるでしょ。
一度ラップしてやれば、例えばmapなんかはArrayではなくきちんとサブクラスのインスタンスを返してくれるように
ES6では設計されているので、何度もラップしたりすることなくチェーンできる。 細かくconsole.log()したいから無意味にチェーンしないさせない。
似て非なる物だが最近は右辺をカンマで長々しく区切るコードを少なからず目にする。
他人にはテストし難くてやや理解困難だから引き継ぐ時には丸ごと捨てられてやり直されるのだろうな。 >>661が言ってるようにチェーンという選択肢は間違いではないと思う
但し非同期も同期もあらゆる処理をチェーンで書くメソッドが不足してる
JSの表現力からしたら可能だけど、世界が追いついてない
Observableとそれと共に現れるであろうフレームワークにはかなり期待してる >>693
> オーバーライドは問題にならないという話はもう上でしただろ。
それに対するレスを>>690で書いただろ
ホントお前人の話し聞かないなｗ 将来のES6ではできるようになるんだ！と
言った所で今は使えないわけで、
将来は！将来は！って繰り返し言ってもなぁ
あと10年後にまたおいで。 >>694
> 細かくconsole.log()したいから無意味にチェーンしないさせない。
もしかしてチェーンしたらconsole.logできないと思ってる？
そのための有名なメソッドがtapなんだけど。
残念ながらjQueryでは標準対応してないから、
たった4行だけ書かないといけないけど
$.fn.tap = function (callback) {
callback.apply(this);
return this;
};
これであっという間に、console.logができる。
function log() {
console.log(this);
}
$('#id').children().tap(log).children() >>697
ElementsがElementのメソットを使えるようにするにはどうするのがいいかの話をしているんだろ。
ElementsはES6前提だし、今更何言ってるの？
もう知らないのなら無理に話に入ってこなくていいから。
勉強して出なおしてね。 ElementsがElementのメソットを使えるようにするにはどうするのがいいか？
全部再実装するんだろ？
で、あとからその実装したメソッドと同じ名前で
新たに標準追加されて大混乱ｗ
既に過去に起きた事件だ Elementsに追加するわけじゃないなら混乱は起こらないでしょ。
そのElementsのサブクラスを使ってる部分だけで閉じてるんだから。
新規で使う上で気になるのならライブラリを更新すればいいだけだし、
古い物に依存してる場合も問題は起きない。 え？ 自分が言ったこと忘れたのか？
全てのDOM APIが、Elementsの代わりに
Elementsのサブクラスを返すようにするって
言ったばかりじゃんかｗ 誰がそんなこと言ってるんだろう？
>>678が見えないのかな？ まあ実際問題サブクラス経由のqueryAllがきちんとサブクラスのインスタンスを返してくれるようになるかは分からないけどな
Arrayとかネイティブの奴はES6できちんと継承が考慮がされた設計にされたけど
DOMの継承を利用した奴はこれから実装される段階だしおそらくissueになると思う
まあ例えElementsのままでもサブクラス側では機能を実装する必要はなくて
queryAll{return new SubClass(super.queryAll())}みたいなのでいいだろうし
全てのメソッドをオーバーライドするのが面倒臭ければそれこそProxyをプロトタイプに挟めばいいか
なんにせよこれは重大な問題提起だと思うね jQueryの質問です。
jQueryオブジェクトをコンソールで見ると配列形式で表示されますが、これはどのようにしているのでしょうか？
http://i.imgur.com/lX94ne4.png
> $("body")
> [ <body></body>] ←これのことです
配列という訳でもないみたいですし…なにか条件があるのでしょうか？ >>706
すみません説明不足でした。
配列というのはArrayのインスタンスという意味です。
Array.isArray($("body")) が false であることから分かるように、Arrayのインスタンスではありません。
Arrayのインスタンスでもないのに、なぜ配列形式で表示されるのか？という疑問です。
そしてその方法を使って、自分で定義したArrayのインスタンスでないオブジェクトにも同様のことをしたいと思っています。 >>707
「配列のようなオブジェクト」で検索してみたら、こんな感じだった
{
"0": "0番目の内容",
"1": "1番目の内容",
"length": 2
} >>704
結局それ、jQueryの実装そのものじゃないかｗ >>710
結論はそれかもしれないけど、各ブラウザのデバッグ機能は
jQueryに対して特別な対応をしていたはず。
NightlyのFirefoxではDOM要素にどんなjQueryイベントが紐付いているか見ることができる！
http://blog.mah-lab.com/2014/08/30/nightly-firefox-dev-tool/
http://www.buildinsider.net/web/chromedevtools/01
> ConsoleパネルからはDOM操作でページを直接編集できる。documentオブジェクトなどの
> 基本的なJavaScript機能を操作できるだけでなく、jQuery構文も利用できるようになっている。 >>712
ありがとうございます！
ブラウザ自体がjQueryに対して特別な配慮をしてるんですね。
spliceの件もその配慮の一環なんですかね。
ただGoogleChromeの方は、ただ単にページにjQueryが使われているから使えるだけなのでは…？ >>713
about:blankでも表示される。
そしてページにjQueryが使われているのであれば
$.fn.jqueryでjQueryのバージョンが表示されるが
それがない。 >>714
あれ、そうなんですか？
すくなくとも手元のGC41のabout:blankではjQuery方式の書き方はできませんでした。
なにかフラグとか必要なのでしょうか？
$("body") === document.body; // true
$("body").text("hoge"); // Uncaught TypeError: string is not a function こいつさっきから何を言ってるんだ？？？
ただコンソールにおいて$がdocument.querySelectorAll相当になってるだけじゃん
それ以上でも以下でもない $ はこれ
https://developer.chrome.com/devtools/docs/commandline-api#selector
Build Insiderのような非公式サイトを参考にするから間違いが起きる
あと、こんな荒らしが立てたスレで質問するよりライブラリ総合質問スレで質問した方が有用だと思うけどね
自分もほとんどここ見てないし >>718
やはりそうですよね。
記憶違いかと焦りました。
ありがとうございます！ だからすぐに訂正してあるじゃん？
715 自分：Name_Not_Found[sage] 投稿日：2015/04/13(月) 23:04:47.09 ID:???
jQueryじゃなくて、$が使えるだけかも＾＾ ここは回答者が認められるスレではない
質問者を助けるスレだ
思い上がらないように >>720
かも、とか可能性レベルの話で回答する前にちゃんと確認しろよ
Aかもしれないし、Bかもしれないなんて回答にならん もうそういうのいいから
このスレには質問と回答しかいらない いや宗教論争は必要。
ツーチャンネルの技術板の価値は宗教論争だけ。
他の場所で宗教論争なんて本質に突っ込む議論を始めたら単なるキチガイだから。 >>723
回答になってないから指摘されてるんだろ 指摘される事が嫌ならキータに日報だか月報だかにしか見えない剽窃猿真似技術ブログでも書いて裸の王様やっとけよ雑魚が。 はい現行スレ
+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/hp/1429873274/l50 var small_option=0;
if(document.chbox3 && document.chbox3.elements[0]){
small_option = document.chbox3.elements[0].checked ? 1 : 0;
}
って書いてますが、この場合、存在チェックって、
document.chbox3 && document.chbox3.elements[0]でよろしいでしょうか？
何かいい手がありますでしょうか？ >>735
document.chbox3 && document.chbox3.elements && document.chbox3.elements[0] >>735
jQuery使っていいのなら
var small_option = $('[name="chbox3"]').prop('checked') ? 1 : 0;
（「? 1 : 0 」はいらん気もするが）
要素がなければundefinedになってくれる。
0個以上の要素として扱うと、こういう風にシンプルに書くことが出来る。 >>736-737
ありがとうございます。
small_optionはajaxで、php側に投げるデータで、php側でpostで受け取り、
1か0でないなら「small_optionが不正」ってエラーメッセージを出す仕様なので、
undefinedだとまずいです。 じゃあ仕方ないね。? 1 : 0は必要ということで。 と思ったけど、これでいいのか
var small_option = $('[name="chbox3"]').prop('checked') || 0;
もしくはこれ。（checkboxのvalueの1が設定されている前提）
var small_option = $('[name="chbox3"]').val() || 0; 話がそれた。
存在チェックの話だったね。
jQueryを使えば存在チェックそのものが不要になる。ということで。 jQueryみたいなライブラリ勧める上で決してお手軽ではないことは注意として挙げるべき
一部分だけjQueryのセレクタ使ってるようなコードに違和感がないならいいが ■ このスレッドは過去ログ倉庫に格納されています
