私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.141 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>848
メソッドチェーンはパフォーマンスのために有るんだよ。
もしメソッドチェーンがなければ、$(セレクタ)を一旦ローカル変数に入れないと
メソッドを呼び出す毎に、内部でquerySelectorAllする必要がある
メソッドチェーンが有るのでローカル変数を使うこと無く、
パフォーマンスを落とすこと無くメソッドを実行できる
メソッドチェーンはパフォーマンスのために有るんだよ。
もしメソッドチェーンがなければ、$(セレクタ)を一旦ローカル変数に入れないと
メソッドを呼び出す毎に、内部でquerySelectorAllする必要がある
メソッドチェーンが有るのでローカル変数を使うこと無く、
パフォーマンスを落とすこと無くメソッドを実行できる
>>851
一旦ローカル変数に入れれば解決するのならパフォーマンスのためじゃないじゃん
一旦ローカル変数に入れれば解決するのならパフォーマンスのためじゃないじゃん
Ruby でも、メソッドチェーンのままなら、遅延処理ができる場合がある
例えば、a().b().c()
で、途中で実体化しないで、最後の所でだけ実体化する
Generator みたいに、無限配列の最初の5つとか、取得できる
もし、これを途中で変数に入れると、先に無限配列が実体化されて、エラーになる。
ただし、関数のまま持ち運べば、OK なのかな?
例えば、a().b().c()
で、途中で実体化しないで、最後の所でだけ実体化する
Generator みたいに、無限配列の最初の5つとか、取得できる
もし、これを途中で変数に入れると、先に無限配列が実体化されて、エラーになる。
ただし、関数のまま持ち運べば、OK なのかな?
jQueryはNode,Element,HTMLCollectionmHTMLAnchorElement...etcを廃止して、全メソッドをNodeListに生やしているようなもの
で、9割以上のメソッドを「絶対NodeListを返す関数」にしてメソッドチェーンを強引に実装
複数のオブジェクト指向から、jQuery単独の独裁思想に染まっているわけだな
ESで「Arrayだけあればいいのた」と唱えるようなもの
で、9割以上のメソッドを「絶対NodeListを返す関数」にしてメソッドチェーンを強引に実装
複数のオブジェクト指向から、jQuery単独の独裁思想に染まっているわけだな
ESで「Arrayだけあればいいのた」と唱えるようなもの
>>857
使うしか無い
使うしか無い
>>862には排他制御気にしなくていいどうだすごいだろみたいなことかいてあるんだけど…
シングルスレッドだから1プロセス内のメモリの競合はないけど、
マルチプロセスでファイル操作するなら排他ロックは要るやろ。
マルチプロセスでファイル操作するなら排他ロックは要るやろ。
>>862にはシングルスレッドは誤解でスレッドプールがあってマルチスレッド走る
けどそんな実装意識しないで使えるって書いてあるけど…
けどそんな実装意識しないで使えるって書いてあるけど…
誰もファイルをロックできないなんて言ってないんだがw
>>863が排他制御気にしなくていいと書いてあるって言ったからファイルの排他は要るやろと言っただけで
>>863が排他制御気にしなくていいと書いてあるって言ったからファイルの排他は要るやろと言っただけで
誰もファイルをロックできないなんて言ってるなんて言ってないんだがw
マルチプロセスとか関係ないやろと言っただけで
マルチプロセスとか関係ないやろと言っただけで
>ファイルならロックができるでしょ
これはどういう必要性があって言ったんだ?
ロックできると理解してる相手にこれを言う思考回路が理解できんわw
これはどういう必要性があって言ったんだ?
ロックできると理解してる相手にこれを言う思考回路が理解できんわw
>>865
http://qiita.com/junjis0203/items/7d3e63253a3d291a04c6#%E3%81%A8%E3%81%93%E3%82%8D%E3%81%A7%E3%81%BB%E3%82%93%E3%81%A8%E3%81%AB%E5%90%8C%E6%9C%9F
> 実は、読み込みは多分大丈夫ですが書き込みは怪しいです。...(以下略)
http://qiita.com/junjis0203/items/7d3e63253a3d291a04c6#%E3%81%A8%E3%81%93%E3%82%8D%E3%81%A7%E3%81%BB%E3%82%93%E3%81%A8%E3%81%AB%E5%90%8C%E6%9C%9F
> 実は、読み込みは多分大丈夫ですが書き込みは怪しいです。...(以下略)
そのページ持ち出した奴どういう意図か知らんが、ファイルの排他制御全然関係ないじゃん。
nodeならfs.openにflags指定するだけだろ。
nodeならfs.openにflags指定するだけだろ。
>>869
理解できないのは完全に君のオツムの問題だね
理解できないのは完全に君のオツムの問題だね
>>871
それロックできなくね?
それロックできなくね?
>>857
async await 関連の排他ロックは色々あるよ
node.jsは
「既にこの世にあるコードは例え1行でも自分では書かん!」みたいな文化あるんで
npm漁ればコレでもかっつーくらい色々あるよ
async await 関連の排他ロックは色々あるよ
node.jsは
「既にこの世にあるコードは例え1行でも自分では書かん!」みたいな文化あるんで
npm漁ればコレでもかっつーくらい色々あるよ
要素の座標を取得して、要素をクリック時にその値を使用するとした場合、
事前に取得してクリック時の処理を軽減する方が望ましいのでしょうか?
事前に取得する場合は、ブラウザをリサイズしたときに、要素の高さが変わる
可能性があるため、リサイズする度に値を取得する必要があります。
このような場合、記述が増えるけども、クリック時の処理の軽減に努めるべきなのか、
座標の取得など大した処理ではないので、クリック時に取得するべきなのか、
構成の考え方について、ご指導お願いいたします。
事前に取得してクリック時の処理を軽減する方が望ましいのでしょうか?
事前に取得する場合は、ブラウザをリサイズしたときに、要素の高さが変わる
可能性があるため、リサイズする度に値を取得する必要があります。
このような場合、記述が増えるけども、クリック時の処理の軽減に努めるべきなのか、
座標の取得など大した処理ではないので、クリック時に取得するべきなのか、
構成の考え方について、ご指導お願いいたします。
処理を軽減して一体どの程度の効果があるのか
説明出来ないなら検討する必要なし
説明出来ないなら検討する必要なし
早速ありがとうございます。
全く説明できそうにないので、クリック時に取得します。
少し↑でも何万回繰り返すと、ほんの少し早くなる・・・みたいなこと
書いてありましたし。
フロント側で初心者なので、対して難しい処理できませんので。
モヤモヤが晴れました!
全く説明できそうにないので、クリック時に取得します。
少し↑でも何万回繰り返すと、ほんの少し早くなる・・・みたいなこと
書いてありましたし。
フロント側で初心者なので、対して難しい処理できませんので。
モヤモヤが晴れました!
>>878
逆転させれば?
逆転させれば?
>>882
プロミスを解決するためのreturnと、解決されたプロミスを返すreturnは概念的に違う
プロミスを解決するためのreturnと、解決されたプロミスを返すreturnは概念的に違う
ドキュメントが読み込まれて
src属性とかのソースをブラウザがとりにいく前に
srcをとりにいかないようノードを削除したいのですが
どのイベントを使えばいいですか?
onloadでは一旦srcをとってきてから削除になるのでリクエストは発生してしまいます
src属性とかのソースをブラウザがとりにいく前に
srcをとりにいかないようノードを削除したいのですが
どのイベントを使えばいいですか?
onloadでは一旦srcをとってきてから削除になるのでリクエストは発生してしまいます
>>892
サービスワーカー
サービスワーカー
サービスワーカーですか?ありがとうございます
XHRから手つけてないのでちょっと読みましたが全くわかりませんでした
ちょっと頑張って勉強してみます
XHRから手つけてないのでちょっと読みましたが全くわかりませんでした
ちょっと頑張って勉強してみます
>>897
やってみました?無理ですよ。それじゃ
やってみました?無理ですよ。それじゃ
>>892
イベントじゃ無理だよ
そんなイベントはない。
無理にやるなら、document.writeを使って、HTML全体をコメント化する。
そして、ページ読み込みあとにHTMLを解析すればできるかもしれないけど
HTMLの中にコメント有るとうまく行かないし、まあまず無理
ブラウザ拡張を作るぐらいかねぇ
イベントじゃ無理だよ
そんなイベントはない。
無理にやるなら、document.writeを使って、HTML全体をコメント化する。
そして、ページ読み込みあとにHTMLを解析すればできるかもしれないけど
HTMLの中にコメント有るとうまく行かないし、まあまず無理
ブラウザ拡張を作るぐらいかねぇ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [100%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
- + 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.120 + (1002) - [95%] - 2014/11/8 1:15
トップメニューへ / →のくす牧場書庫について