のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,645,055人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレ+ JavaScript の質問用スレッド vol.131 +

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
752 = :

>>748
for (let v of Object.values(test)) {
console.log(v);
}
とか
Object.values(test).forEach(v => {
console.log(v);
});

753 = :

こっちのが汎用的だったか
Object.entries(test).forEach(([key, value], index) => {
console.log(key, value, index);
});

754 = :

なんで標準のJavaScriptを使うと
冗長になるのか教えてほしいものだ。

lodashを使ったほうが短いとか意味分からん
_.forOwn(test, (value, key) => {
 console.log(key + ':' + value);
});

755 = :

どの言語も普通は標準よりライブラリ使った方が短くならね?

756 = :

だよなw
いつものlodashくんがスレチ話するためのエクスキューズのつもりなんだろw

757 = :

自作の関数作ればもっと短くなるよね
はいlodash敗北

758 = :

ほんとlodashの名前が出るだけで
必死になるなw

759 = :

for( var key of test )とかfor( var key in test )じゃダメなん?

761 = :

>>759
前者はそもそもエラーなので論外
後者は普通にあり
entriesやvaluesは使えない環境も多いしね
個人的にはObject.keysを使うことが多いかな
よっぽど大量にループさせるんならfor..in使うけど

762 = :

使えない環境はあるがけして多くはない
そんなことを言ったら何もできない
いつまでレガシーブラウザを延命させる気なんだ

763 = :

for..inで十分にできて、key / valuesが key / test[key] になる程度の違い
構造は明示されてて
構造が未知だったり完全に信頼できなかったりしない
javascriptはゴルフ絶対主義なんか

764 = :

for-inのデメリットは.hasOwnProperties()のチェックを入れるかどうかの問題が発生するから

もちろんオブジェクトにそのチェックが不要だという保証があるなら.hasOwnProperties()で調べる必要はない

765 = :

>>748を見れば一目瞭然だな

768 = :

プロゴルファー?

769 = :

何度も配列作らなくてもforEach内の処理で十分な場合が多い
filterとかしなくてもif returnで良いんだし

770 = :

はいはい、俺様専用

771 = :

>>769
処理分離したいし破壊的代入はなるべく避けたいじゃん?

772 = :

破壊的代入したって頑張ればできるだろ
ほんの少しづつ頑張ればいいだけだよ
小さいものを積み重ねても大きくはならない

773 = :

>>771
今回がそもそもfor-inとの対比の話だからな
値を列挙して利用したいというだけだから
配列をどう処理していきたいかみたいな一般論とは話が違う

つまりfor-ループの{}内の置き換えだから、それは素直に考えるとforEachでいいじゃないかと
列挙したい物を連続してフィルタリングしたりする書き方したいか?ということ

774 = :

そもそも、すべての属性を取得するような、
メタプログラミングみたいな設計自体がおかしい

もし、テストツール以外で、こういう設計をしていたら、おかしいと思え!

775 = :

いやです

782 = :

= でいい
http://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API

784 = :

>>782
知らんかった!恥ずかしい

>>783
こんなかんじでどうじゃろ
var storage = localStorage;
//保存
storage.data = document.getElementById("tbodyのID").innerHTML;
//復元
document.getElementById("tbodyのID").innerHTML = storage.data;

786 = :

LocalStorage って、HTML を保存するものじゃないだろ

どちらも文字列の、key : value 型だろ

788 = :

イベントリスナ無視していいなら
innerHTMLを出し入れしてもただの文字列でしょ、問題はないんじゃね
なんか問題あるっけ

789 = :

ない。>>786がinnerHTMLの戻り値が文字列だと理解してないだけ。だからバカにされている。

790 = :

普通、HTML タグなど、保存しないだろ。
なんで、そんな表示情報を保存するねんw

保存するのは、アプリに必要なデータだろ

key : value
アプリに必要な、データの項目と値

791 = :

今回はtableの保存だからな
HTMLのままが駄目と言っちゃ
縦横長+配列に分割することになるんだろうけど
そうなったらJSON化もあんまりスマートでないのでIDB使おうかとかも言えるしな

まあ、大きなアプリで沢山入出力するなら
そこ抽象化して丁寧にやるのもいいけど
簡素なものには適当な対応でHTML突っ込んで戻すくらいで良いんじゃないかと思うよ

792 = :

>>790
で?復元時にはバラバラにしたデータからまた元のhtmlの文字列組み直すのか?それとも一つずつcreateElement繰り返して挿入か?w
どっちにしろバカなんじゃねーのオメー
えんぴつを使わないアメリカかよwww

793 = :

>>792
でも君プログラムのアーキテクチャについて無知じゃん

794 = :

っていうか、たったそれだけのことで悩んでどうするんだって気がするけどね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);

795 = :

スマートかどうか、仕様的に許されたことかどうか、この2つは別問題

1行で終わる話

796 = :

テーブルの部分をコンポーネントにしてそっちに配列読み込みの機能を持たせるべきだと思う

797 = :

ネズミ倒すのに戦車が必要とか組織再編が必要とか言い出す兵隊、降格です。

798 = :

javascriptを使ってネズミを駆除

799 = :

$('#table').append(data.map(function(row) {
 return $('<tr/>').append(row.map(function(attrs) {
  return $('<td/>', attrs);
 }));
}));

800 = :

つーかHTMLをそのままデータにすると柔軟性がなくなるよ。
後からHTMLをかえたくなったときとかね

テンプレートにデータを流し込んでビューを作るってことを
やっている人なら理解できると思う

そもそもデータとして参照する時HTMLを解析しなければいけなくなる

仕様的に許されているからOKと考えるんじゃなくて
後々のメンテナンス性なんかも考えらるようでなければダメ


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について