+ JavaScript の質問用スレッド vol.131 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【条件】期待する回答の条件を書いてください。(ex: jQuery不可, フレームワーク不可)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです >>663
そうあってほしいと考えているわけですね
でもね、最初からjQueryはDOMライブラリだって言ってましたー
その他の用途には、それ用のライブラリを使いますー >>667
jQueryがそういう用途に最適化された設計がされていないことについてはどう考える？ 「いつまでもDOM APIと張り合って」って
書いているところから読み取れないかな？
jQueryはなんでもできるんだろ？
あれもこれもできるんだろ？
だがjQueryはあれもこれもの用途に
最適化された設計になっていない
所詮DOM API代わりのDOM用ライブラリにすぎない 当たり前ですよね？
jQueryはDOM用ライブラリですよ？
なんでDOM用ライブラリをなんでもできるライブラリに
しないといけないんですか？
どんな機能にも対応している神ライブラリとでも
思っていたんですか？
アホですねｗ ムキー！ お前らがjQueryはなんでもできるライブラリだって言っていただろ
その公約を守ってないからjQueryはクソライブラリだ！
お前らが言っていたことができないからクソだ >>666
window.onload
https://developer.mozilla.org/ja/docs/Web/API/GlobalEventHandlers/onload
load イベントは文書のローディング工程の終了時に発生します。
このイベントが発生した時点で、文書中の全てのオブジェクトは DOM 内にあり、
全ての画像とサブフレームのロードは完了しています
画像のロード完了を待つ必要があるかな？
漏れなら、画像など無視するから、<body>のラストで、JS を読み込む お前らが言っていた = 妄想
自分の妄想が実現されてないからクソだって言ってたのか
アホだな window.onloadは発動が遅いから、
それよりも早く発動するDOMContentLoadedってのができた。
そしてjQueryはDOMContentLoaded相当のタイミングで発動する
readyメソッドっていうのをDOMContentLoadedができるより前から実装していた
でもbodyの最後で実行していれば、readyはいらんのよね。
なぜか昔はJavaScriptは、<head>の中に書くもんだってお作法があった
今はbodyの最後で書いてもよいとなったから、実はjQueryでもreadyは使う必要がない。
更に言うならば、<head>で書いたとしても、
$(document).on(イベント, セレクタ) の形式を使っていればreadyはいらないんだよね。
なぜならdocumentはその時点で存在しているから
bodyの最後で書くのは最速に思えるかもしれないけど、
1ページの長さが極端に長かった場合、bodyの最後に到達するまでは
JavaScriptの処理が発動しないことになる。
でも、<head>で $(document).on(イベント, セレクタ) の形式で書いていれば
bodyの最後に到達しなくてもイベントを捉えることができる。
イベントを捉えてももちろんまだ該当の要素が読み込まれていなければ反応はしないが
jQueryの正しいやり方で書いていれば、要素が0個でもエラーにはならない。
というわけで要素が画面に表示された直後からJavaScriptの処理が働くように
するには、<head>で $(document).on(イベント, セレクタ) の形式で書くやり方なんだが
思考に慣れが必要ではあるだろうな >>673
上でコンポーネント化の話などが挙がってるし、
逆に色々話題が出たときこれはjQueryでは向いてないという話になったことがない
なんやかんや無理やりjQueryが使えると思い込んでる 思い込みが酷すぎて怖い
一緒に仕事したくないタイプ >>679
向いていないという話が出なかったら
向いていると言っているんだ！って思い込んでんのか？
例えば日付処理にjQueryは向いてない
ほら言ってやったぞ？どうするんだ？ >>682
jQueryはDOMライブラリである。
誰もjQueryが何にもでも使えるとは言ってない
ここまではいいな？ > なんやかんや無理やりjQueryが使えると思い込んでる
誰もjQueryが何にでも使えるとは言ってないので
（エスパーでもない限り他人が思ってることなんてわからないので）
思い込んでる事とわかるのは自分自身（>>679）だけである
ここまではよい ああ、スレ建てたやつがライブラリ禁止のテンプレ消したのか example.com?q=文字列
をサーバーサイドで受け取る時に文字列中に￥ｒや￥ｎも渡す事は出来ますか？ >>685
一番の問題はそう思われてるってことだと思うぞ
jQuerer含むライブラリスタが過剰にライブラリを推してるのは事実
度々スレ分離したり議論になってるのにまだ自分たちがどう思われてるのかが分かってないのか > 一番の問題はそう思われてるってことだと思うぞ
jQueryのアンチが変なふうに思い込んでるのは
アンチが悪いってことで終わりじゃね？ ライブラリの書き方はライブラリ使わないと通じない
ライブラリを使わない書き方はライブラリ使ってても使ってなくても通じる
ってところか？ クチャラーに自覚したらと諭したら
俺は普通に食べてるだけ
耳障りに聞こえるのはお前が悪いと言われたって感じか react.jsやangular.jsが役立つ大規模案件、とは具体的にどの程度の規模のサイトですか？
今まで小さな企業でしか勤めたことがなく、大規模案件と言われてもイメージが湧きません >>693
てことは一生知る必要がないんじゃないか すいませんageてしまいましたね
今のままの小さい仕事しかせずにjavascriptと言えばjqueryでチョロチョロ、みたいなキャリアで本当に将来生き残れるのかという不安があるのです
あとは、自分がjqueryしかできないから会社も大きな仕事が取れないんじゃないかとか考えてしまったりですね どの位大規模かというと、最近YouTubeがPolymerを導入した
だが、そのバージョンはv0.いくつのもの、今の最新はv3
そのくらい年単位で開発する案件に使うもの
そこからわかると思うがフレームワークは前もって勉強する必要はない
実際使うべきときには役に立たないから
大手も使うと決めたときに改めて勉強会を開くなりして対応してる 離脱したくても離脱しづらくなるから使うなら見合った理由が必要
大規模だから使うというより
少数の比較的小規模な会社が
使い続けてく方が多い印象がある jQueryってもう役目が終わってるんだよ
いい加減目を覚ましたほうが良い
作者も見放してReactやってるじゃん jQuery 73.2%（前年比 +1.4%）、React 0.6%（前年比 +0.5%）
jQueryの役目が終わってからjQueryの役目が終わったというように
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトが
JavaScriptのライブラリとしてjQueryを使用していることが判明したが
それから1年たった2018年1月現在、73.2%に1.4%も増えていることが判明した。
またAngularは0.5%、だがReactが伸びてきており0.5%
とAngularを逆転したことがわかる
だがjQueryには大幅なさをつけられており取って代わるのは
いつになるのか動向が注目される >>701
これからの自分たちがどうしていくかの話をしてるのに
他の人が今何をやってるのかを気にするって意味がわからんな
良く使われてるのは所謂「枯れた技術」とは言えるけど
熟れた物ってこれから先腐っていくこととほぼイコールじゃん HTTPがまだ周りでよく使われているからHTTPSにしないって言ってるのとかと同じだぞ？ >>702
せやな、一年前に、これからはjQueryは減っていくとか
これからは腐っていくとか予想を立てた人恥ずかしいよな
これから？来年にはまたjQueryのシェア増えるんじゃね？
AngularもReactも熟れる前にくされなきゃ良いけど
Angularは一回腐れたよな HTTPSは費用と処理と通信のコストがあるからなあ >>703
> HTTPがまだ周りでよく使われているからHTTPSにしないって言ってるのとかと同じだぞ？
わかったわかった。HTTPSは最初からある程度使われいたからな
何かのフレームワークの使用率が10%を超えたら考えよう。
それでいいだろ？ >>696
中小規模の会社が請ける規模の案件なら
素のJSだけでも十分やってけるよ
昔と比べて格段に安定して書けるようになってきたから
万が一必要になったらその時必要な分だけ調べれば済む 大規模な会社がReact使っているかと言ったらそうじゃないからな
なにせ0.5%しか使われていない Ruby のHTMLのテンプレートエンジン、erb では、
HTMLとRubyの構文が交互に来るから、わかりにくい。
PHP なんかもそう
<% @items.each do |item| %>
<li><%= item %></li>
<% end %>
もしRuby に、JSX があれば最強だろう JSXもクソじゃん。条件分岐とループごときに
言語の機能を使うようじゃダメ
mustacheが最強 ここまで見てきて分かったのは
仕様というのは作って環境というのは動かしていくもんだと考えてる開発者と
仕様というのは与えられて環境というのは落ち着いたものに浸かるもんだと考えてる開発者じゃ
話合うわけ無いってことだな 問題
「作って環境というのは動かしていくもん」と
「与えられて環境というのは落ち着いたものに浸かるもんだ」の
違いを完結に述べよ >>712
簡潔に言えば仕様標準化と実装に関わっているかどうかってことで言えるんじゃない？
企業で言うとミーティングやカンファレンスに社員を出張させているかどうか
別にそれは社会貢献のためではなくて自分たちのやりたいように環境を動かすためにそうしてる
環境というが実際は人
その場にいる仕様や実装書いてる人に直接会って、
こここういうバグが有るんですよとか、こういうところで困ってるんですよとか話ができるってことが重要
やっぱりそれはオンラインでプルリクエスト送るのとはぜんぜん違う
仕様や実装を作ってるのは人間で、意外と少数だから、向こうも幅広い意見を汲み取ろうとはしてるけれど
どうしても自分たちの近い範囲が得をする恣意的なものになってしまう
そのために皆わざわざ録画で見れるものを会場まで行く >>693です
ひとまず自分のやりうる業務のことを考えたらjqueryやes6の習熟でひとまずは大丈夫だと感じました
まずはjqueryを使い倒してみて、jqueryでは不十分だと感じられるようになった段階で改めて考えてみることにします
ありがとうございました オブジェクト型の分割代入やasyncジェネレータなど
既にモダンブラウザで使える重要なES2018の機能もあるよ 初めてのJavaScript 第3版、オライリー、2017
ES2015 の本。
これを読めば、クラスとか、素人はあまりの難しさに愕然とするだろう 素人が騒然とするのは当たり前だろ？
いや、お前がプロで、難しくて騒然としたっていうなら
それはそれで面白いことだがｗ 人間のメンタルモデルとコードを一致させられるから
理解しやすくなる。可読性の向上
ひねくれた方法で「実現できる」じゃだめなんだ
普通に書いて普通に読めなければいけない 設計で方法論に従うことができる。
しかしテストでパターン数爆発で大抵死ぬ。 JSにテストなんて必要ない、トライアンドエラーがベスト
テストしたいんならよりし易い言語で書いてコンパイルすべき > テストしたいんならよりし易い言語で書いてコンパイルすべき
ではその、よりし易い言語がなにで
どういう理由で、よりし易いのか言えるんでしょうな？ 726ではないが、結局selenium動かしたり
casperでもぞもぞしたりするなあ svgの制御についての質問はここでしてもいいですか 昔foreignObjectを使って要素のミラーを作るというのを試した記憶があるのですが
今その情報を教えて頂けますか?
「あああ」をミラーしたら「あああ」が２つになって、大本を 「いいい」に変更するとコピー先も「いいい」になるという機能です 地図上に車のアイコンを置いて決まったルート上(svgのパス上)を動かすアニメーションを考えていて、進行方向に合わせてアイコンの向きを変えたいのですが、何を基準に計算をして向きを調整すれば良いかわからず困っています。
svg関連で角度の計算に使える関数やよい方法があれば教えていただけますか。
動きとしては↓こちらのサイトのようなものです。
https://itstudio.co/sample/svganime/anime7.html ここの奴ら役に立たんな
もうお前らには一切聞かんわ >>735
SVGの線上となるとアレだけど
動かすルートが決まっているなら接線の傾き求めればいいじゃない >>739
接線か、なるほど気づきませんでした
接線の求め方から勉強してみます。。 決まったルートがあるならatanだけで済む気がするんだが >>736
すみません。アニメーション自体はサイトのようなもので、これに角度の変化を付け加えたいという意味でした。
そしてよく見たらサイトのも微妙にrotateで傾けてますね。。折り返しの際に逆を向いてくれないので考えているものとは違いますが。 >>743
反転はtransformのscaleを使うのが容易いかも var test = {
a: 1,
b: 5,
c: 6
}
ってあって
test.aからtest.cまでの値をループで取得しようと思ったらどうすればいいですか？ >>745
『javascript test.aからtest.cまでの値をループで取得しようと思ったらどうすればいいですか？』
のGoogle検索結果を見ていけばわかる for(let [key, value] of Object.entries(test)){
console.log(key + ':' + value);
}
こうするとちょっとPHPっぽい >>745
for (let v of Object.values(test)) {
console.log(v);
}
とか
Object.values(test).forEach(v => {
console.log(v);
}); こっちのが汎用的だったか
Object.entries(test).forEach(([key, value], index) => {
console.log(key, value, index);
}); なんで標準のJavaScriptを使うと
冗長になるのか教えてほしいものだ。
lodashを使ったほうが短いとか意味分からん
_.forOwn(test, (value, key) => {
console.log(key + ':' + value);
}); どの言語も普通は標準よりライブラリ使った方が短くならね？ だよなｗ
いつものlodashくんがスレチ話するためのエクスキューズのつもりなんだろｗ 自作の関数作ればもっと短くなるよね
はいlodash敗北 ほんとlodashの名前が出るだけで
必死になるなｗ for( var key of test )とかfor( var key in test )じゃダメなん？ >>756
前者はそもそもエラーなので論外
後者は普通にあり
entriesやvaluesは使えない環境も多いしね
個人的にはObject.keysを使うことが多いかな
よっぽど大量にループさせるんならfor..in使うけど 使えない環境はあるがけして多くはない
そんなことを言ったら何もできない
いつまでレガシーブラウザを延命させる気なんだ for..inで十分にできて、key / valuesが key / test[key] になる程度の違い
構造は明示されてて
構造が未知だったり完全に信頼できなかったりしない
javascriptはゴルフ絶対主義なんか for-inのデメリットは.hasOwnProperties()のチェックを入れるかどうかの問題が発生するから
もちろんオブジェクトにそのチェックが不要だという保証があるなら.hasOwnProperties()で調べる必要はない hasOwnPropertiesやっててよかったとか
今までに一度もないなｗ for..inは式ではなく文なのがちと煩わしい
とはいえ素のJavaScriptで
Object.values(test).filter(x => x % 2 === 0).map(x => x * 2)
みたく書くと無駄に何度も配列作っちゃうから、そういう意味ではlodashが羨ましい 何度も配列作らなくてもforEach内の処理で十分な場合が多い
filterとかしなくてもif returnで良いんだし ■ このスレッドは過去ログ倉庫に格納されています
