+ 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にして見えないようにしてください。文句をつける＝荒らしです >>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で良いんだし >>766
処理分離したいし破壊的代入はなるべく避けたいじゃん？ 破壊的代入したって頑張ればできるだろ
ほんの少しづつ頑張ればいいだけだよ
小さいものを積み重ねても大きくはならない >>768
今回がそもそもfor-inとの対比の話だからな
値を列挙して利用したいというだけだから
配列をどう処理していきたいかみたいな一般論とは話が違う
つまりfor-ループの{}内の置き換えだから、それは素直に考えるとforEachでいいじゃないかと
列挙したい物を連続してフィルタリングしたりする書き方したいか？ということ そもそも、すべての属性を取得するような、
メタプログラミングみたいな設計自体がおかしい
もし、テストツール以外で、こういう設計をしていたら、おかしいと思え！ childNodes[n] や item(n) では最後の要素は -1 では取得できないってことでいいですよね?
n の変更でアクセスする方法ってないんでしょうか?
lastChildとかつうと位置が変わった時に書き換えるのが面倒なんですけど。 >>774
ありがとうございます。
別の質問なんですけど
table の tbody に入っているデータを
localStorageに保存したあとで
ページを開き直した後に
localStorageから呼び出して
同じ形式で再表示したいんですけどどうすれば良いんでしょう?
storage.data = document.getElementByID("toboyのID")
で保存して
appendChild(storage.data)
とかやってもうまく行かないんですけど
forループかなんかつかって1つづつ要素を createChild とかして appendChild() するしかないんですか? 訂正
storage.data = document.getElementByID("toboyのID")
↓
storage.data = document.getElementById("tbodyのID") >>778
プロパティ構文、ブラケット構文、メソッド構文とあるようなので問題ないようです。
>>777
あぁ、それ本に書いてたなぁと思って調べたら
オブジェクトはJSON.stingiy/parseつかえってかいてたので試したけど
駄目っぽいですね。
一つ一つデータをオブジェクトかなにかで保存して
それを取り出して一つ一つcreateElement/appendChildしていくしか無いっぽいですかね。
だれか妙案あれば引き続きよろしくお願いします。 >>779
知らんかった！恥ずかしい
>>780
こんなかんじでどうじゃろ
var storage = localStorage;
//保存
storage.data = document.getElementById("tbodyのID").innerHTML;
//復元
document.getElementById("tbodyのID").innerHTML = storage.data; >>781
あぁ、それ良いかもですね!
あとで試してみます。 LocalStorage って、HTML を保存するものじゃないだろ
どちらも文字列の、key : value 型だろ ふーん、じゃ>>781がダメならオブジェクトをJSON.stringifyして保存するのも禁止な。 イベントリスナ無視していいなら
innerHTMLを出し入れしてもただの文字列でしょ、問題はないんじゃね
なんか問題あるっけ ない。>>783がinnerHTMLの戻り値が文字列だと理解してないだけ。だからバカにされている。 普通、HTML タグなど、保存しないだろ。
なんで、そんな表示情報を保存するねんw
保存するのは、アプリに必要なデータだろ
key : value
アプリに必要な、データの項目と値 今回はtableの保存だからな
HTMLのままが駄目と言っちゃ
縦横長＋配列に分割することになるんだろうけど
そうなったらJSON化もあんまりスマートでないのでIDB使おうかとかも言えるしな
まあ、大きなアプリで沢山入出力するなら
そこ抽象化して丁寧にやるのもいいけど
簡素なものには適当な対応でHTML突っ込んで戻すくらいで良いんじゃないかと思うよ >>787
で？復元時にはバラバラにしたデータからまた元のhtmlの文字列組み直すのか？それとも一つずつcreateElement繰り返して挿入か？ｗ
どっちにしろバカなんじゃねーのオメー
えんぴつを使わないアメリカかよｗｗｗ >>789
でも君プログラムのアーキテクチャについて無知じゃん っていうか、たったそれだけのことで悩んでどうするんだって気がするけどねw
値からテーブルを作るコードはデータの部分を除いてたったの6行でできる。
（アロー関数を使えばもっと減らせる）
https://jsfiddle.net/1uopxycn/
var data = [
[{text: 1, colspan:2},{text: 3}],
[{text: 1},{text: 2},{text: 3}],
[{text: 1},{text: 2},{text: 3, style: 'color:red'}],
];
var rows = data.map(function(row) {
return $('<tr/>').append(row.map(function(attrs) {
return $('<td/>', attrs);
}));
});
$('#table').append(rows); スマートかどうか、仕様的に許されたことかどうか、この2つは別問題
1行で終わる話 テーブルの部分をコンポーネントにしてそっちに配列読み込みの機能を持たせるべきだと思う ■ このスレッドは過去ログ倉庫に格納されています
