私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.131 +

みんなの評価 :
レスフィルター : (試験中)
for(let [key, value] of Object.entries(test)){
console.log(key + ':' + value);
}
こうするとちょっとPHPっぽい
console.log(key + ':' + value);
}
こうするとちょっとPHPっぽい
>>748
for (let v of Object.values(test)) {
console.log(v);
}
とか
Object.values(test).forEach(v => {
console.log(v);
});
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);
});
Object.entries(test).forEach(([key, value], index) => {
console.log(key, value, index);
});
なんで標準のJavaScriptを使うと
冗長になるのか教えてほしいものだ。
lodashを使ったほうが短いとか意味分からん
_.forOwn(test, (value, key) => {
console.log(key + ':' + value);
});
冗長になるのか教えてほしいものだ。
lodashを使ったほうが短いとか意味分からん
_.forOwn(test, (value, key) => {
console.log(key + ':' + value);
});
だよなw
いつものlodashくんがスレチ話するためのエクスキューズのつもりなんだろw
いつものlodashくんがスレチ話するためのエクスキューズのつもりなんだろw
for( var key of test )とかfor( var key in test )じゃダメなん?
>>759
前者はそもそもエラーなので論外
後者は普通にあり
entriesやvaluesは使えない環境も多いしね
個人的にはObject.keysを使うことが多いかな
よっぽど大量にループさせるんならfor..in使うけど
前者はそもそもエラーなので論外
後者は普通にあり
entriesやvaluesは使えない環境も多いしね
個人的にはObject.keysを使うことが多いかな
よっぽど大量にループさせるんならfor..in使うけど
使えない環境はあるがけして多くはない
そんなことを言ったら何もできない
いつまでレガシーブラウザを延命させる気なんだ
そんなことを言ったら何もできない
いつまでレガシーブラウザを延命させる気なんだ
for..inで十分にできて、key / valuesが key / test[key] になる程度の違い
構造は明示されてて
構造が未知だったり完全に信頼できなかったりしない
javascriptはゴルフ絶対主義なんか
構造は明示されてて
構造が未知だったり完全に信頼できなかったりしない
javascriptはゴルフ絶対主義なんか
for-inのデメリットは.hasOwnProperties()のチェックを入れるかどうかの問題が発生するから
もちろんオブジェクトにそのチェックが不要だという保証があるなら.hasOwnProperties()で調べる必要はない
もちろんオブジェクトにそのチェックが不要だという保証があるなら.hasOwnProperties()で調べる必要はない
>>748を見れば一目瞭然だな
hasOwnPropertiesやっててよかったとか
今までに一度もないなw
今までに一度もないなw
for..inは式ではなく文なのがちと煩わしい
とはいえ素のJavaScriptで
Object.values(test).filter(x => x % 2 === 0).map(x => x * 2)
みたく書くと無駄に何度も配列作っちゃうから、そういう意味ではlodashが羨ましい
とはいえ素のJavaScriptで
Object.values(test).filter(x => x % 2 === 0).map(x => x * 2)
みたく書くと無駄に何度も配列作っちゃうから、そういう意味ではlodashが羨ましい
何度も配列作らなくてもforEach内の処理で十分な場合が多い
filterとかしなくてもif returnで良いんだし
filterとかしなくてもif returnで良いんだし
>>769
処理分離したいし破壊的代入はなるべく避けたいじゃん?
処理分離したいし破壊的代入はなるべく避けたいじゃん?
破壊的代入したって頑張ればできるだろ
ほんの少しづつ頑張ればいいだけだよ
小さいものを積み重ねても大きくはならない
ほんの少しづつ頑張ればいいだけだよ
小さいものを積み重ねても大きくはならない
>>771
今回がそもそもfor-inとの対比の話だからな
値を列挙して利用したいというだけだから
配列をどう処理していきたいかみたいな一般論とは話が違う
つまりfor-ループの{}内の置き換えだから、それは素直に考えるとforEachでいいじゃないかと
列挙したい物を連続してフィルタリングしたりする書き方したいか?ということ
今回がそもそもfor-inとの対比の話だからな
値を列挙して利用したいというだけだから
配列をどう処理していきたいかみたいな一般論とは話が違う
つまりfor-ループの{}内の置き換えだから、それは素直に考えるとforEachでいいじゃないかと
列挙したい物を連続してフィルタリングしたりする書き方したいか?ということ
そもそも、すべての属性を取得するような、
メタプログラミングみたいな設計自体がおかしい
もし、テストツール以外で、こういう設計をしていたら、おかしいと思え!
メタプログラミングみたいな設計自体がおかしい
もし、テストツール以外で、こういう設計をしていたら、おかしいと思え!
文字列もそうだけどそもそもlocal Storageの使い方大丈夫か?
=使ってるようだが…
http://developer.mozilla.org/ja/docs/Web/API/Window/localStorage
=使ってるようだが…
http://developer.mozilla.org/ja/docs/Web/API/Window/localStorage
LocalStorage って、HTML を保存するものじゃないだろ
どちらも文字列の、key : value 型だろ
どちらも文字列の、key : value 型だろ
ふーん、じゃ>>784がダメならオブジェクトをJSON.stringifyして保存するのも禁止な。
イベントリスナ無視していいなら
innerHTMLを出し入れしてもただの文字列でしょ、問題はないんじゃね
なんか問題あるっけ
innerHTMLを出し入れしてもただの文字列でしょ、問題はないんじゃね
なんか問題あるっけ
ない。>>786がinnerHTMLの戻り値が文字列だと理解してないだけ。だからバカにされている。
普通、HTML タグなど、保存しないだろ。
なんで、そんな表示情報を保存するねんw
保存するのは、アプリに必要なデータだろ
key : value
アプリに必要な、データの項目と値
なんで、そんな表示情報を保存するねんw
保存するのは、アプリに必要なデータだろ
key : value
アプリに必要な、データの項目と値
今回はtableの保存だからな
HTMLのままが駄目と言っちゃ
縦横長+配列に分割することになるんだろうけど
そうなったらJSON化もあんまりスマートでないのでIDB使おうかとかも言えるしな
まあ、大きなアプリで沢山入出力するなら
そこ抽象化して丁寧にやるのもいいけど
簡素なものには適当な対応でHTML突っ込んで戻すくらいで良いんじゃないかと思うよ
HTMLのままが駄目と言っちゃ
縦横長+配列に分割することになるんだろうけど
そうなったらJSON化もあんまりスマートでないのでIDB使おうかとかも言えるしな
まあ、大きなアプリで沢山入出力するなら
そこ抽象化して丁寧にやるのもいいけど
簡素なものには適当な対応でHTML突っ込んで戻すくらいで良いんじゃないかと思うよ
>>790
で?復元時にはバラバラにしたデータからまた元のhtmlの文字列組み直すのか?それとも一つずつcreateElement繰り返して挿入か?w
どっちにしろバカなんじゃねーのオメー
えんぴつを使わないアメリカかよwww
で?復元時にはバラバラにしたデータからまた元のhtmlの文字列組み直すのか?それとも一つずつcreateElement繰り返して挿入か?w
どっちにしろバカなんじゃねーのオメー
えんぴつを使わないアメリカかよwww
>>792
でも君プログラムのアーキテクチャについて無知じゃん
でも君プログラムのアーキテクチャについて無知じゃん
っていうか、たったそれだけのことで悩んでどうするんだって気がするけどねw
値からテーブルを作るコードはデータの部分を除いてたったの6行でできる。
(アロー関数を使えばもっと減らせる)
http://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);
値からテーブルを作るコードはデータの部分を除いてたったの6行でできる。
(アロー関数を使えばもっと減らせる)
http://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行で終わる話
1行で終わる話
テーブルの部分をコンポーネントにしてそっちに配列読み込みの機能を持たせるべきだと思う
ネズミ倒すのに戦車が必要とか組織再編が必要とか言い出す兵隊、降格です。
$('#table').append(data.map(function(row) {
return $('<tr/>').append(row.map(function(attrs) {
return $('<td/>', attrs);
}));
}));
return $('<tr/>').append(row.map(function(attrs) {
return $('<td/>', attrs);
}));
}));
つーかHTMLをそのままデータにすると柔軟性がなくなるよ。
後からHTMLをかえたくなったときとかね
テンプレートにデータを流し込んでビューを作るってことを
やっている人なら理解できると思う
そもそもデータとして参照する時HTMLを解析しなければいけなくなる
仕様的に許されているからOKと考えるんじゃなくて
後々のメンテナンス性なんかも考えらるようでなければダメ
後からHTMLをかえたくなったときとかね
テンプレートにデータを流し込んでビューを作るってことを
やっている人なら理解できると思う
そもそもデータとして参照する時HTMLを解析しなければいけなくなる
仕様的に許されているからOKと考えるんじゃなくて
後々のメンテナンス性なんかも考えらるようでなければダメ



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [100%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
トップメニューへ / →のくす牧場書庫について