jQuery 質問スレッド vol.8
■ このスレッドは過去ログ倉庫に格納されています
JavaScriptでDOM用ライブラリであるjQueryのスレです。
次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください
このスレはjQueryやjQuery UIの使い方やjQueryプラグインの作り方を質問するスレです。
jQueryを使って作る側のスレであって、こんなプラグインありませんか？と聞くスレではありません。
そういうのは自分で探してください。
ろくにサポートもされてなさそうな野良プラグインの使用はおすすめしません。
JavaScriptの質問は関連スレで質問して下さい。
■前スレ
jQuery 質問スレッド vol.7
https://mevius.5ch.net/test/read.cgi/hp/1478055094/
■関連スレ
JavaScript の質問用スレッド vol.130
https://mevius.5ch.net/test/read.cgi/hp/1501503056/
ECMAScript デス 6
https://mevius.5ch.net/test/read.cgi/tech/1483332914/
JavaScript ライブラリ総合質問所 vol.5
https://echo.5ch.net/test/read.cgi/hp/1465399470/ removeClass()って何気に便利だな
値関係なくとりあえず全部消してくれる この間classで衝突したけどなぁ？
どうやれば衝突しないん？ まだdataかclassかweakmapかって話してたのかｗ >>645
初学者なのでeachでゴリゴリ回す発想しかありませんでしたが
そのような書き方が出来るのですね
参考になります
ありがとうございます アロー関数を使えばもっと減らせる
と書きつつあえて使わないのはなんなの？
そっちのほうが分かりやすいと思ってんの？ <要素 class="bbb eee fff jjj">と、
要素に値（class）を持たせ、値は動的に変化します
この要素は今どの値を持っているかはclassNameで簡単に取得できますが
classを使わずdata-*で持たせた場合はどう取得するのでしょうか？
アロー関数無しでお願いします >>656
穿った見方をすれば、これまでの話の対抗策として書いた感じがするが、
要件が違うから、"今回の場合"は classを使ったほうが良いよと
"この間の例"では、data-*属性を勧めていた俺が答えるｗ いやいや、『この間の例』は要件や目的がはっきりしてないんだから
結局何が最適かは分かりませんと言うことがFAでしょ
だからこういう場合には、とか一般的にはとか話が広がってたのに
その中で大口叩いておいて細かいことに逃げるのは感心しないな
いくら屁理屈こねようとも、周りの人へ感覚的にどう思わせたかってことが大事だからね >>659は自分の書いた内容を自分で見たほうが良い。
おまえはその書いた内容の話をしたいのかと >>659
>結局何が最適かは分かりませんと言うことがFAでしょ
>だからこういう場合には
この辺りはもっともだし、よくわかるが後半よくわからん DOM に状態を持たせるな！
DOM に状態を問い合わせるな！
React を使え！ 状態が要素の外側の見た目振る舞いに関わるものならclassで良い
例えば一度クリックされたボタンに永続効果をつけるためのクラス「clicked」とか
そして中身の内容にしか関わらないものであればdata-*が良い
商品を読み込んでDOMに書き出すスクリプトと
商品を絞り込むスクリプトが独立してあった場合
その間でやり取りするために使う商品の種類情報など
ただ特にスクリプトから要素を検索しないといけない場合はそれなりのコストがかかるので、
そういうスクリプトを統合して、状態をスクリプト中に持たせたほうがスッキリする場合もある なんか見た目を変えるものはclassを思ってるかもしれないけど
属性セレクタが作られたのは、属性で見た目を変えられるようにするためだからね
属性セレクタをには必要とされる機能が追加されている
前方一致、後方一致、そしてclassのようにスペース区切りで
単語が含まれているかどうか、等がある classは名前の通り分類分けのもの
様々な要素に共通する分類を指定する際にはclass
属性はただその要素固有の性質 限られた情報の中で答えるのはそうするしかない上にありがたいが
木だけ見て森全体がわかったように断定してたのはちょっと引くわな 属性やめてjs側に持っていくべきとか意味不明だったよなｗ いや、実際Mapは有用だと思う
>>665の真ん中の例だと
最初から商品情報がHTMLとして存在している場合は
DOMに書き加えるという機能とDOMの情報を編集するという機能に分割するほうが良さげだが
そうでない場合はDOMはただのViewと捉えてModelはJS側で持っておくほうが良さげ 誰がどう読んでもdata君のことなのに無理やりmap君とか見苦しいったら dataでも、classでもHTMLとしては意味はないが、
data属性を使う場合はdataメソッドの取り扱いには注意が必要
動的に追加、削除、変更する場合に
$(Elements).data('hoge') で値を参照するとキャッシュされるで動的変更の値は参照できない
$(Elements).attr('data-hoge') では問題はないけどね
あくまでもカスタム属性なので広い意味で動的に扱うならばclassを使うのが賢明 >>676
それ以前に、dataメソッドでは
data属性を変えることはできないよ
data属性を変える必要が無いなら、dateメソッドで十分だし
書き換える必要があるなら、attrメソッドを使えと言うだけの話
> あくまでもカスタム属性なので広い意味で動的に扱うならばclassを使うのが賢明
その結論はおかしい。なぜならdata属性の読み書きにはattrメソッドを使う
その場合注意する点は何もないわけで、もっというのならDOM APIを使うならば
dataメソッドがdata属性を書き換えるものではないなどという混乱はおきない
つまり、あんたのレスの最後の行はその行以前の話とは全く関係なく
取ってつけたように出てきてる。
カスタム属性を使うかの基準は動的かどうかではなくclassという名前の
属性に入れるのがふさわしいか、別の名前の属性に入れたほうが良いかの違いでしょ？
例えばariaのrole属性だって、classにaria-role-button なんて名前で入れることだって
できただろうけど、そんなことせずにrole属性を作りましょうとなったわけだ
classとは違った別の目的が有るのならclassを使わずに、カスタム属性を使いましょう
そのために汎用にいくつでも自由に属性を作って良いことになったわけなんだから jQueryにもdatasetメソッドを作れば良いのかも あ、DOM APIのDataset APIは読み取り専用だったｗ 嫌いなやつを追い出すには、徹底的に反論して論破するのと
無視するのと煽るのどれが一番効果的だろうか？ >>682
楽しいのは煽りだね どんどん無知さらして笑われてるのに本人は気付かないからな
徹底的に反論はアホには反論自体が理解できないから意味ない
追い出したいだけなら無視が一番だけど 聞いたかい？俺がdata君なわけだけど、本当に荒らしを
しているのは誰かよくわかっただろ？ >>675
WeakMapくんは俺だが自演なんかしてないよ >>674
意味分かってないな
>>685
俺は承知 何も意見を言わずに支持を表明する理由は、
ほら支持してる人がいるだろ？と見せるのが目的だって死んだじいちゃんが言ってた。
名前を隠して言うことで沢山の人に支持されてるように見せられるんだって >>687
それ煽りだけ入れる人、意見を言わずに否定だけする人も同じだよ >>687
匿名掲示板でそんなこと言ってもだから何としか
ちなみに674は明らかに言わんとしてることに対してずれてるぞ もうdata-属性は自分で勝手に定義しちゃダメとか言い出しそうな勢いだなｗ >>664
jQuery(js)はそれなりに使ってるがReactだとその件に関してどういうメリットあるの？ jQuery → DOM
React → 仮想DOM → DOM
React では、DOMを更新しない場合に、React内の仮想DOMに問い合わせるだけ。
DOMにアクセスしない
React内に、DOMのコピーを持ってる
状態を問い合わせるだけとか、DOMを更新しない場合に、
ブラウザにアクセスしないから速い >>694
それって単に変数に問い合わせたいものの
情報を持たせればいいだけだよね？ >>694
状態を問い合わせるだけとか、DOMを更新しない場合に、
レンダリングされないのでDOMにアクセスしても速いよ >>696
それだけじゃあんまり意味なくて、効率的な差分更新アルゴリズムが事実上必須。 >>698
マッチポンプって感じだよねｗ
やらなくてもいいのに仮想DOMとかいう無駄な仕組みを追加して、
仮想DOMという仕組みのせいで遅くなっちゃった、
だから遅くならないように差分更新アルゴリズムを作らなきゃ！ｗ
最初から仮想DOMなんてものがなければシンプルで
無駄のない処理を書くことができるのに。
やっぱり馬鹿対策なのかな？
馬鹿が無駄なコードを書いてもなるべく遅くならないように
する防御策が仮想DOMｗ >>699
> 馬鹿が無駄なコードを書いてもなるべく遅くならないようにする防御策が仮想DOMｗ
いやこれマジこの通りだよ。
現在のDOMがどうなってるか気にしないで書けるんだから。
天才が常にありうるすべての場合のDOMの状態を把握して狙い澄ました最小限のDOM変更コードを書けるならそっちのほうが速い。
ところがいかな大企業と言えど天才のみでチームを組めないし、ライフサイクルの最後までそいつらをそのプロジェクトに縛り付けることも出来ない。
カップ麺スゲーと言ってるところにラーメン屋のラーメンには敵わないだろｗと言ってるようなもん。 >>700
天才は現在のDOMを意識なんかしてねーよ
その時点でずれてるんだな。
天才っていうほどでもないが普通は
DOMが変化しても柔軟に対応できるように作る
idやclassや属性を使うことで、実際のDOMが
変わったとしてもコードはそのままで動くようにする
それは作業分担にもつながる。DOM（HTML）を書くのは
ほかの人に任せることができる。同様にCSSもだな
仮想DOMを使うとプログラマがHTML相当のものを書かなければいけなくなる。
自分の担当の部分に集中できる仕組みにするのが常識だと思ってる俺に
なに？天才はありとあらゆることを把握してる？ アホかｗ
前提が間違ってるんだわ。
あらゆることを把握するのが無理だから仮想DOMが必要だって思ってるようだが
こっちはあらゆることを把握しなくていいから仮想DOMは不要だって言ってるんだよ > idやclassや属性を使うことで、実際のDOMが変わったとしてもコードはそのままで動くようにする
そうなってないコード山ほどあるよね？
理由は出来ないやつ気にもしないやつがたくさんいるから。 できないやつは何を使ってもできないだろ
人間の問題は技術の話の対象外だ 程度と言うものがあるだろ。
DOM直接操作に比べて仮想dom使ってるライブラリは簡単だよ。
だって宣言的に書くだけで操作しなくていいんだもの。
diffしてパッチ作って実domに反映はライブラリがやってくれる。
だからバカにウケてる。
カップ麺が低所得者層にウケるのと同じ。 それを言うならHTMLを書くだけで
画面にレンダリングされるが？
プログラム一切不要 Reactの良さはDOMからセマンティクスやなんやかんや
とにかくレンダリングに必須でない部分を削ぎ落としたスマートな仮想DOMを提供してくれることで
もっと言えばDOMから離れたReact Nativeとかその逆輸入版のReact Native for Webが良さを体現してる > もっと言えばDOMから離れたReact Nativeとかその逆輸入版のReact Native for Webが良さを体現してる
俺に言わせれば、それらが、世界に多数存在するウェブサイトに
どう適用できるの？って感じだけどな
Reactは完全にオーバースペックなんだわ >>708
そもそも既存のWebサイトに適応するようなものではないということ
出発点が違うからオーバースペックとかいう話にはならない 嫁さんがちゃんとご飯作ってくれてるのにわざわざカップ麺買ってきていつ食べるか悩んでるようなもの。
でも独身には人気。そういうこと。 よく分からんけど、画面側とか作ってくれる人が別にいるのに
自分一人で画面も何もかも作っていた人にとっては
Reactは便利ってことかな？ 俺の嫁さんは２日に１回は平気でインスタントを晩飯として食わせるぞ jQueryがHTMLエスケープ用のメソッドを用意していない理由は何ですか？
あほなのでしょうか？ >>717
textってHTMLエスケープされるんですね
というか当然ですね・・
半角スペースが に置き換わらないのでしないのかと勘違いしましたが
スペースはHTMLエスケープに含まれなかったです 半角スペースとnbspは別物だからな
nbspは何の略かしってるか？ non-breaking space、自動改行しないスペースだ
半角スペース（英単語の区切り）では一行に収まらなければ改行するが
nbspだと自動改行しない。別物だ。エスケープじゃねぇ >>719
まさに望まない場所で改行されることに困って置換したのですが
「自動改行しないスペース」の意味だとは気づきませんでした
ありがとうございました blurイベントはデレゲートできませんでした
おそらくバブリングしないからだと思います
バブリングしないイベントは全てデレゲートできないと考えていいのでしょうか？ 特定のページにアクセすしたときに
<div class="contents">
...
</div>
の中だけ表示ってできますか？
特定の要素だけ非表示ってのはできるみたいなんですけど 質問です。
target属性が指定されていないaタグ を選択するにはどのように書けばよろしいでしょうか？ a:not(:target) じゃねぇの？ jQueryというよりセレクタの話 >>725
効かないようですが、記述間違ってますか？
<style>
a:not(:target){
border: solid 1px #000;
}
</style>
<a href="https://www.google.co.jp/";>targetなし</a>
<a href="https://www.google.co.jp/"; target="_blank">targetあり</a> すいません解決しました
a:not([target])
でした :targetなんていう疑似クラスあったのかと思ってしまった 一応有るけど違う意味だったな
:target
https://developer.mozilla.org/ja/docs/Web/CSS/:target
CSS の :target 疑似クラスは、 URL のフラグメントに一致する id を持つ固有の要素（対象要素）を表します。
:target Selector
https://api.jquery.com/target-selector/ 722ですけどスタイルを変更できるのはしってるんですけど
visibleをnoneにするのは簡単でもきりとるのはそれ以外の全部けさないとだし
ターゲットの親は残さないといけないしで簡単にやる方法ってないのかなと… すっかりアロー関数式を使うようになっていたのですが
jQueryはメソッドの中でthisを使うことが多いので
アロー関数式だと問題が出ます
普通の関数を書くしかないのでしょうか？ コールバックにthisで渡される変数は引数でも渡されているので
こっちを使うのがES6風なのでしょうか？ なんでもかんでもアロー関数を使うのが間違いだと思うけどね
addEventListenerでも同じ問題が有るけど
そういう風にthisが変わるようなときには使わないほうが良いと思う
誰か知らないけど（ｗ）この人も同じようなことを言ってる
https://dmitripavlutin.com/when-not-to-use-arrow-functions-in-javascript/
> 2. Callback functions with dynamic context
個人的にはアロー関数は、関数を値のように使いたいときだけにしてほしい
それは大抵一行で済むものになるので () => { return n } みたいな
{} とreturnを使う構文は無くしてほしいね オブジェクト指向的にthisを使うためにアロー関数を使うわけで、
イベントハンドラではtargetを使うのが普通だと思う 少なくともmdnだとメソッドでない関数に最適と書いてある。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/arrow_functions
そうするとオブジェクト指向的にthisを使うため、って出自ではなさそうだが。
むしろ関数型的に使うためでは。
イベントハンドラではtargetを使うのが普通というのはそう思う。 >>738
その文書の"thisを束縛しない"の項目に、
＞これは、オブジェクト指向プログラミングをする上で煩わしいということが分かりました。
って書いてあるよ そういや関数型に使うんならそもそもthis使わないし短く書けるくらいしか使用上の違いなかったな 別にアロー関数がオブジェクト指向に向いてるというわけでもそうでないわけでもない
アロー関数はメソッド自体として使うには確かに不適切
だがメソッド中で関数を定義したりすると必要になるthat=thisなんかは不要になる
適材適所 jsbinで追加出来るjQueryのバージョンに
jQuery WIP
という版があるのですが、このWIPとは何の略でしょうか？ >>744
作成中というような意味ですね
とすると、新しいほどいいだろうと思って選んでいましたが
あまり使わない方がいいのでしょうね
ありがとうございました どんどん使うべきだよ
万が一問題があってもそれを報告すればいいだけだし
自分のスキル向上にもなる
良いことしか無い ■ このスレッドは過去ログ倉庫に格納されています
