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

みんなの評価 :
レスフィルター : (試験中)
>>402
いや書くよw
いや書くよw
lodashはそりゃOKに決まってるよ。
質問者がその名前を出してるんだから
今回はライブラリはOK
質問者がその名前を出してるんだから
今回はライブラリはOK
>>305の(2)ってどなたか説明できませんか?
アドレス同士の比較で高速なのならなんで'文字列'(1回目)と'文字列'(2回目)の===がtrueなのかサッパリ。
'文字列'(1回目)と'文字列'(2回目)は別のアドレスにメモリ割り当てられてるんじゃないの?それだとtrueはおかしくありません?
それともまさか===なのに一文字づつ比較してるわけじゃないよね?
アドレス同士の比較で高速なのならなんで'文字列'(1回目)と'文字列'(2回目)の===がtrueなのかサッパリ。
'文字列'(1回目)と'文字列'(2回目)は別のアドレスにメモリ割り当てられてるんじゃないの?それだとtrueはおかしくありません?
それともまさか===なのに一文字づつ比較してるわけじゃないよね?
>>308にあるじゃん
回答全部読めと
回答全部読めと
本当に解決しようとするなら、回答に対して「~が分かって、~は~まで理解できたが、~が分からん」とか自分で切り分けして返信しようとするもんだ
それがないって事はたいして重要な問題でもないんだろうさ
それがないって事はたいして重要な問題でもないんだろうさ
>>420
君に理解できない事が分かっただけでも良かったじゃないか
君に理解できない事が分かっただけでも良かったじゃないか
図々しい奴だな
「わからないんですかと煽っても無駄です」のテンプレを思い出した
「わからないんですかと煽っても無駄です」のテンプレを思い出した
>>425
つまり
let a = 'abc', b = 'abc';
a === b
としたときも
let a = 'abc';
let b = a;
a === b
としたときも、
'abc'の一文字づつ比較されてすべて等しかったからtrueが返されてると、そういうことですかね?
つまり
let a = 'abc', b = 'abc';
a === b
としたときも
let a = 'abc';
let b = a;
a === b
としたときも、
'abc'の一文字づつ比較されてすべて等しかったからtrueが返されてると、そういうことですかね?
型を限定した配列を簡単に作成する方法はありますか。
例えば、String型しか代入できず、String型以外を代入したらTypeErrorを返す配列、とか。
例えば、String型しか代入できず、String型以外を代入したらTypeErrorを返す配列、とか。
>>426
一文字ずつ比較するとかそういうロジック的なことは仕様にはない
とにかく同じ文字コード列ということが確認できればtrueが帰る
そこでアドレスの一致を利用するかどうかはエンジンの問題
君もいい加減分かったほうがいい
仕様に沿う実装方法なんて幾つもあるということ
エンジンは最適化もしないといけないし仕様のステップどおりに実装してるわけでもない
仕様から期待される挙動と同等の挙動ができるように実装されている
一文字ずつ比較するとかそういうロジック的なことは仕様にはない
とにかく同じ文字コード列ということが確認できればtrueが帰る
そこでアドレスの一致を利用するかどうかはエンジンの問題
君もいい加減分かったほうがいい
仕様に沿う実装方法なんて幾つもあるということ
エンジンは最適化もしないといけないし仕様のステップどおりに実装してるわけでもない
仕様から期待される挙動と同等の挙動ができるように実装されている
>>429
配列ではないようですが、どういう意味でしょう?
配列ではないようですが、どういう意味でしょう?
ES2015以前からTypedObjectの提案があるけど何回もポシャってる
http://github.com/dslomov/typed-objects-es7
数値型はバイナリを扱うために必要だとしても
基本的にはJSではキチキチに制限するよりもそれっぽく扱っていったほうが良いと思う
http://github.com/dslomov/typed-objects-es7
数値型はバイナリを扱うために必要だとしても
基本的にはJSではキチキチに制限するよりもそれっぽく扱っていったほうが良いと思う
まあディズニーランド来て何でスパイダーマンライドが無いんだと喚いてるようなものだからな。USJ行けと。
>>438
> ES2015以前からTypedObjectの提案があるけど何回もポシャってる
そういう動きがあったのですね。
ポシャった理由が気になります…。
> 基本的にはJSではキチキチに制限するよりもそれっぽく扱っていったほうが良いと思う
Int32Array が ToNumber しているように、TypeError を返すよりも型変換した方がJSらしい、というような思想は理解できます。
ただ、コードを書いていく上で制限をかけた方がパターン数が減って都合が良い事はあると思います。
例えば、変数には一つの型を決めるコーディング規約が一般的ですが、これは受け取る変数の型を一つに限定する事で、想定される変数の組み合わせを少なくする効果があります。
どんな型が来ても良い設計にすると、7つの型全てを考慮しなければなりませんが、一つの型になれば、アルゴリズムを考えるコストは1/7です。
同じ理由で配列の値に期待される型を一つに限定する事で、考えるコストを減らす事が出来ます。
> ES2015以前からTypedObjectの提案があるけど何回もポシャってる
そういう動きがあったのですね。
ポシャった理由が気になります…。
> 基本的にはJSではキチキチに制限するよりもそれっぽく扱っていったほうが良いと思う
Int32Array が ToNumber しているように、TypeError を返すよりも型変換した方がJSらしい、というような思想は理解できます。
ただ、コードを書いていく上で制限をかけた方がパターン数が減って都合が良い事はあると思います。
例えば、変数には一つの型を決めるコーディング規約が一般的ですが、これは受け取る変数の型を一つに限定する事で、想定される変数の組み合わせを少なくする効果があります。
どんな型が来ても良い設計にすると、7つの型全てを考慮しなければなりませんが、一つの型になれば、アルゴリズムを考えるコストは1/7です。
同じ理由で配列の値に期待される型を一つに限定する事で、考えるコストを減らす事が出来ます。
言語自体はだいたいわかったけど仕事の真似事みたいなことがしたい
なにをしたらいい?
なにをしたらいい?
スーパー初心者です
引数について質問なのですが
(とあるページのコードです)
const func = ({ hoge = 'foo' } = {}) => console.log(hoge);
func(); // 'foo'
func({ hoge: 'bar' }); // 'bar'
3行目のように「何らかの値をオブジェクトや配列にして渡す」という場合は
そのオブジェクトや配列を定義しておく必要ないんですか?
引数について質問なのですが
(とあるページのコードです)
const func = ({ hoge = 'foo' } = {}) => console.log(hoge);
func(); // 'foo'
func({ hoge: 'bar' }); // 'bar'
3行目のように「何らかの値をオブジェクトや配列にして渡す」という場合は
そのオブジェクトや配列を定義しておく必要ないんですか?
皆さん、多くの回答を、ありがとう!
確かに、ERB みたいな、テンプレートファイルじゃなく、
JavaScript(JS) ファイル内の配列から、簡単に要素を作りたいから、
文字列から要素を作るよりも、JS のメソッドで、要素を作った方がよいかも
map みたいなもので、1行で書けて、ループの記述を排除できれば、うれしいです。
可読性も高い方がよい
でも、同じ手法を、3回使うので、テンプレートエンジンでも良いのか
それと、配列内の数値は、他者からの入力ではなく、自分で用意したものなので、サニタイズは不要です
DOM 操作は遅いけど、createDocumentFragment で、まとめてDOM に追加すれば、
1回になるから、速いのでは?
確かに、ERB みたいな、テンプレートファイルじゃなく、
JavaScript(JS) ファイル内の配列から、簡単に要素を作りたいから、
文字列から要素を作るよりも、JS のメソッドで、要素を作った方がよいかも
map みたいなもので、1行で書けて、ループの記述を排除できれば、うれしいです。
可読性も高い方がよい
でも、同じ手法を、3回使うので、テンプレートエンジンでも良いのか
それと、配列内の数値は、他者からの入力ではなく、自分で用意したものなので、サニタイズは不要です
DOM 操作は遅いけど、createDocumentFragment で、まとめてDOM に追加すれば、
1回になるから、速いのでは?
速いっていうのが何を大事にしてるのか良く分からん
実際大事なのはUXであって処理の速さではない
処理を分割したほうが良いという場合も多分にある
実際大事なのはUXであって処理の速さではない
処理を分割したほうが良いという場合も多分にある
今はinnerHTMLを使うほうが速いのか?
http://jsperf.com/document-fragment-vs-innerhtml-vs-looped-appendchild/90
http://jsperf.com/document-fragment-vs-innerhtml-vs-looped-appendchild/90
str変数にHTMLをためていって、最後にinnerHTMLをするよりも
div.innerHTML += で変更していくほうが速いのか?
createDocumentFragmentを使うほうが遅くなるんだな
div.innerHTML += で変更していくほうが速いのか?
createDocumentFragmentを使うほうが遅くなるんだな
パーサーとレイアウトは非同期で一部マルチスレッド化されてるんだから
そのときの他の処理の状況にもよるし何が速いとか言うことはできない
そのときの他の処理の状況にもよるし何が速いとか言うことはできない



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
トップメニューへ / →のくす牧場書庫について