私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.130 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>99
> サーバは差分情報をクライアントに返し、
> クライアントは差分を自分に適応する、
という部分の実装がどれだけ面倒かによるかな。クライアント側の１レコードの編集に掛かる手間がどれだけか、というのも考慮したい。
サーバのデータ（レコード）に最終更新日時を持たせて、それをバージョン情報として利用できる。
DBの更新条件に最終更新日時を付けてUPDATEして、更新されたレコード数を確認。もし0件だったら、最終更新日時が変更されていたことになる。
> あとこういうアプリのサンプルが載ってる本とかあれば教えてください
本とかは知らない。
> サーバは差分情報をクライアントに返し、
> クライアントは差分を自分に適応する、
という部分の実装がどれだけ面倒かによるかな。クライアント側の１レコードの編集に掛かる手間がどれだけか、というのも考慮したい。
サーバのデータ（レコード）に最終更新日時を持たせて、それをバージョン情報として利用できる。
DBの更新条件に最終更新日時を付けてUPDATEして、更新されたレコード数を確認。もし0件だったら、最終更新日時が変更されていたことになる。
> あとこういうアプリのサンプルが載ってる本とかあれば教えてください
本とかは知らない。
setIntervalとかsetTimeoutって結構誤差出ませんか？
プチフリするようなしょぼい環境だったり
秒数カウントする（何回も呼ぶ）ものとかだと特にそんな感じがします
1/1000秒単位で正確なタイマーが欲しい場合って
別のタイマー使ってで数秒起きにズレ修正したりするのでしょうか？
プチフリするようなしょぼい環境だったり
秒数カウントする（何回も呼ぶ）ものとかだと特にそんな感じがします
1/1000秒単位で正確なタイマーが欲しい場合って
別のタイマー使ってで数秒起きにズレ修正したりするのでしょうか？
なんか高精度のタイマーあったろ？
Web APIマニアさんに後は任せた
Web APIマニアさんに後は任せた
>>107
http://developer.mozilla.org/ja/docs/Web/API/WindowTimers/setTimeout#Reasons_for_delays_longer_than_specified
ここに理由も書かれてるし、代替案のリンクも張られてるな。英語だけどwindow.postMessage()使うみたい。
http://developer.mozilla.org/ja/docs/Web/API/WindowTimers/setTimeout#Reasons_for_delays_longer_than_specified
ここに理由も書かれてるし、代替案のリンクも張られてるな。英語だけどwindow.postMessage()使うみたい。
>>109
ありがとうございます
4msから指定可能であって（1ms指定しても4msになる）
1秒に設定したら1004msになるというわけではないですよね？
描画処理入れたら描画が終わってからタイマーが再びセットされる感じで
描画処理の分ずれていってるのかもしれないですね
ちょっとコード見なおして検証してみます
ありがとうございます
4msから指定可能であって（1ms指定しても4msになる）
1秒に設定したら1004msになるというわけではないですよね？
描画処理入れたら描画が終わってからタイマーが再びセットされる感じで
描画処理の分ずれていってるのかもしれないですね
ちょっとコード見なおして検証してみます
>>107
> setIntervalとかsetTimeoutって結構誤差出ませんか？
誤差以前に、その2つは等価じゃないのになぜ同列として扱う？
・setInterval はコールバック関数の処理時間を待機せずにインターバルをおく
・setTimeoutの再帰呼び出しではコールバック関数の処理完了後にインターバルをおく
> setIntervalとかsetTimeoutって結構誤差出ませんか？
誤差以前に、その2つは等価じゃないのになぜ同列として扱う？
・setInterval はコールバック関数の処理時間を待機せずにインターバルをおく
・setTimeoutの再帰呼び出しではコールバック関数の処理完了後にインターバルをおく
>>108
「なんか高精度のタイマー」とは具体的に何ですか？
「なんか高精度のタイマー」とは具体的に何ですか？
Node.js にも、何種類か、タイマーがあったかも
高性能タイマーとは、ベンチマークで速いもの
高性能タイマーとは、ベンチマークで速いもの
>>117
質問者の下記一文は読んだか？
> 秒数カウントする（何回も呼ぶ）ものとかだと特にそんな感じがします
これを実装する為には setTimeout を再帰呼び出して setInterval と似た振舞いにしなければならない
ここで、setTimeout と setInterval ではインターバルの取り方が違うだろ
要件次第でどちらを選択するかが決まる
目的に合う実装は一つしかないはずなのに、setTimeout と setInterval を一緒くたに問題視するのは違うだろ
質問者の下記一文は読んだか？
> 秒数カウントする（何回も呼ぶ）ものとかだと特にそんな感じがします
これを実装する為には setTimeout を再帰呼び出して setInterval と似た振舞いにしなければならない
ここで、setTimeout と setInterval ではインターバルの取り方が違うだろ
要件次第でどちらを選択するかが決まる
目的に合う実装は一つしかないはずなのに、setTimeout と setInterval を一緒くたに問題視するのは違うだろ
だな、setTimeout と setInterval の特性ぐらい勉強してね
もう不毛な議論な気がする
回答にイチャモンをつけるのが正義みたいな風潮は何とかならんのかな
否定するなら、さらに良い回答で塗りつぶすぐらいの気概がある方が健全だと思う
彼は言葉は悪いけど、回答しているだけ非難だけしている人より数段マシだよ
回答にイチャモンをつけるのが正義みたいな風潮は何とかならんのかな
否定するなら、さらに良い回答で塗りつぶすぐらいの気概がある方が健全だと思う
彼は言葉は悪いけど、回答しているだけ非難だけしている人より数段マシだよ
console.log("NumLockキーは"+event.getModifierState("NumLock")?"ON":"OFF");
eventはkeydownとかのKeyboardEventじゃないとgetModifierState()生えてないからリロードの時とかは無理だな
あ、MouseEventにも生えてんのか。
じゃvar fresh = true;とかしといてbodyのmousemoveとかmouseoverとかのハンドラのなかにif(fresh){さっきのconsole文;fresh=false;}すればどうか。
スマホだから確認できんけど
じゃvar fresh = true;とかしといてbodyのmousemoveとかmouseoverとかのハンドラのなかにif(fresh){さっきのconsole文;fresh=false;}すればどうか。
スマホだから確認できんけど
>>127-129
レスありがとうございます。 event.getModifierState("NumLock") で色々細工してみます
レスありがとうございます。 event.getModifierState("NumLock") で色々細工してみます
すみません
javascriptの曖昧な型定義や柔軟性による複雑さは
ｊsDocコメントを書く事で回避できますでしょうか？
javascriptの曖昧な型定義や柔軟性による複雑さは
ｊsDocコメントを書く事で回避できますでしょうか？
複雑な理由はお前のコードの問題だから
JsDocどころか例え型定義があったり柔軟性がなくても
何も回避できないよ。
JsDocどころか例え型定義があったり柔軟性がなくても
何も回避できないよ。
>>131
jsdocて単なるJavadocのポーティングでしょ？ちゃんと書いたらそれにしたがったドキュメントを自動生成してくれるにすぎない。
flow(flowtype)やtypescriptなら型検査してくれるよ。
お手軽に始めるならflowがいいんじゃない？typescriptはちょっと(週末潰すくらい)気合い要る。
jsdocて単なるJavadocのポーティングでしょ？ちゃんと書いたらそれにしたがったドキュメントを自動生成してくれるにすぎない。
flow(flowtype)やtypescriptなら型検査してくれるよ。
お手軽に始めるならflowがいいんじゃない？typescriptはちょっと(週末潰すくらい)気合い要る。
それはES2015が出る前の考え方だよ
今はWASMもあるし今更そういうこと言うやつは居ない
今はWASMもあるし今更そういうこと言うやつは居ない
idってのはhtml中に1個しか出てきちゃいけないもんだぞ
pタグであるかどうかなんて関係なく#hahahaだけでいい
まぁ別にp #hahahaとかでもいいけど
pタグであるかどうかなんて関係なく#hahahaだけでいい
まぁ別にp #hahahaとかでもいいけど
普通に
document.querySelector('#hahaha');
でいいんじゃね
速度が問題になるほどかどうかだけど
document.querySelector('#hahaha');
でいいんじゃね
速度が問題になるほどかどうかだけど
idひとつしかつけちゃいけないって言っても、つけたから何かエラーが起きるわけでもないし普通に2つ以上についてることもある
querySelectorでp#hahahaでいいんじゃない
querySelectorでp#hahahaでいいんじゃない
>>141
そのコードの場合、fCheckに関数以外が入っている（つまりバグ）の場合に
スルーされてしまうので良くない。
if (fCheck) {
fCheck();
}
の方が良い
さらにいうなら
fCheck && fCheck();
でもよい
また予め fCheck = fCheck || function() {} などとしておけば、
fCheck(); とするだけでよくなる
そのコードの場合、fCheckに関数以外が入っている（つまりバグ）の場合に
スルーされてしまうので良くない。
if (fCheck) {
fCheck();
}
の方が良い
さらにいうなら
fCheck && fCheck();
でもよい
また予め fCheck = fCheck || function() {} などとしておけば、
fCheck(); とするだけでよくなる
id重複は DOM 的には最初の id 以外は無視され、 CSS 的には詳細度の高い class みたいなもの
自動的に validator を通すようにしとけば id重複は自然となくなる
自動的に validator を通すようにしとけば id重複は自然となくなる
フォームはnameで区別するのだから
idは基本的に使う必要はない。
idは基本的に使う必要はない。
>>136,146
他サイトで重複idがあることは、自サイトで重複idを使うことの理由にはならない
「重複して使ってるサイトは山ほどある」(採用例が多い)も観測範囲によって変わってくる主観的なものだし、仮に信頼できる統計で採用例が多かったとしても、「使ってよい」かの判断は別
文法違反なんだから
http://momdo.github.io/html/dom.html#global-attributes
自分の管轄外のサイトにJavaScriptを適用するのであればどうしようもないが、そういう前提条件があるのなら質問の冒頭に付け加えるべきだし、<p id="hahaha">, <div id="hahaha"> のどちらが先に存在するのかによって変わってくる
<p id="hahaha"> が初めに来ることが保証されているのなら、getElementById
id="hahaha" が出現する順番がランダム or <p id="hahaha"> が2番目以降に出現し、<p id="hahaha"> を特定したいのならば、document.querySelectorAll('p[id="hahaha"]').forEach()
他サイトで重複idがあることは、自サイトで重複idを使うことの理由にはならない
「重複して使ってるサイトは山ほどある」(採用例が多い)も観測範囲によって変わってくる主観的なものだし、仮に信頼できる統計で採用例が多かったとしても、「使ってよい」かの判断は別
文法違反なんだから
http://momdo.github.io/html/dom.html#global-attributes
自分の管轄外のサイトにJavaScriptを適用するのであればどうしようもないが、そういう前提条件があるのなら質問の冒頭に付け加えるべきだし、<p id="hahaha">, <div id="hahaha"> のどちらが先に存在するのかによって変わってくる
<p id="hahaha"> が初めに来ることが保証されているのなら、getElementById
id="hahaha" が出現する順番がランダム or <p id="hahaha"> が2番目以降に出現し、<p id="hahaha"> を特定したいのならば、document.querySelectorAll('p[id="hahaha"]').forEach()
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.130 + (974) - [100%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + 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.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について