元スレ+ JavaScript の質問用スレッド vol.130 +
JavaScript覧 / PC版 /みんなの評価 :
101 :
🐒
102 = :
>>99
Firebaseはどう?
PouchDBは?
103 :
>>99
> サーバは差分情報をクライアントに返し、
> クライアントは差分を自分に適応する、
という部分の実装がどれだけ面倒かによるかな。クライアント側の1レコードの編集に掛かる手間がどれだけか、というのも考慮したい。
サーバのデータ(レコード)に最終更新日時を持たせて、それをバージョン情報として利用できる。
DBの更新条件に最終更新日時を付けてUPDATEして、更新されたレコード数を確認。もし0件だったら、最終更新日時が変更されていたことになる。
> あとこういうアプリのサンプルが載ってる本とかあれば教えてください
本とかは知らない。
104 = :
>>98
おおおりがとう
>>100
これ実はフライングで買ってしまったんだけど解説に次々に知らんjsライブラリぶっこんで来るからソースコードの理解進まないから止めたわ、、
105 = :
>>102-103
firebaseっていうの知らなかったんですが、
面倒な部分をgoogleに全部丸投げできるのめちゃくちゃ魅力的ですね
調べてみます
ありがとうございました
106 = :
数秒ごとに細かく同期して、ずれたら単純に破棄するのが一番見易いよ
107 = :
setIntervalとかsetTimeoutって結構誤差出ませんか?
プチフリするようなしょぼい環境だったり
秒数カウントする(何回も呼ぶ)ものとかだと特にそんな感じがします
1/1000秒単位で正確なタイマーが欲しい場合って
別のタイマー使ってで数秒起きにズレ修正したりするのでしょうか?
108 = :
なんか高精度のタイマーあったろ?
Web APIマニアさんに後は任せた
109 = :
>>107
http://developer.mozilla.org/ja/docs/Web/API/WindowTimers/setTimeout#Reasons_for_delays_longer_than_specified
ここに理由も書かれてるし、代替案のリンクも張られてるな。英語だけどwindow.postMessage()使うみたい。
110 = :
>>109
ありがとうございます
4msから指定可能であって(1ms指定しても4msになる)
1秒に設定したら1004msになるというわけではないですよね?
描画処理入れたら描画が終わってからタイマーが再びセットされる感じで
描画処理の分ずれていってるのかもしれないですね
ちょっとコード見なおして検証してみます
111 = :
>>107
> setIntervalとかsetTimeoutって結構誤差出ませんか?
誤差以前に、その2つは等価じゃないのになぜ同列として扱う?
・setInterval はコールバック関数の処理時間を待機せずにインターバルをおく
・setTimeoutの再帰呼び出しではコールバック関数の処理完了後にインターバルをおく
112 = :
>>108
「なんか高精度のタイマー」とは具体的に何ですか?
113 = :
Node.js にも、何種類か、タイマーがあったかも
高性能タイマーとは、ベンチマークで速いもの
114 = :
>>113
> Node.js にも、何種類か、タイマーがあったかも
>107の要件を満たせそうなタイマーは何?
> 高性能タイマーとは、ベンチマークで速いもの
タイマー処理で何がどう速くなるの?
115 = :
>>111
違いはそこじゃねーよw
setIntervalは登録したコールバックを定期的に何度も呼び出す
setTimeoutは登録したコールバックを一回だけ呼び出す
116 :
>>115
いや、それは誰でも知ってるだろ
同列に扱っているから、定期的に関数を呼び出す処理を前提に質問していると思ったんだよ
それぐらい読み取ってくれ
117 = :
>>116
同列に扱ってなんかいないだろ
setIntervalが誤差でずれていく
setTimeoutが誤差でタイムアウトする時間がずれている
違う話だろ
118 = :
>>117
質問者の下記一文は読んだか?
> 秒数カウントする(何回も呼ぶ)ものとかだと特にそんな感じがします
これを実装する為には setTimeout を再帰呼び出して setInterval と似た振舞いにしなければならない
ここで、setTimeout と setInterval ではインターバルの取り方が違うだろ
要件次第でどちらを選択するかが決まる
目的に合う実装は一つしかないはずなのに、setTimeout と setInterval を一緒くたに問題視するのは違うだろ
119 = :
下記一文ってそれだけが全てじゃないだろうに
120 = :
だな、setTimeout と setInterval の特性ぐらい勉強してね
121 = :
特性の違いは理解してるように読めるけどな
読解力の問題か
122 = :
こんな過疎板で自演するなや見苦しい
123 = :
情報が正しいのなら、自演云々はどうでもいい
煽りは害悪
124 = :
>>119
では、>>115の回答が全てなのか?違うだろ?
回答で全てを語っているなんて誰も言ってない
>>120
知ってる
125 = :
もう不毛な議論な気がする
回答にイチャモンをつけるのが正義みたいな風潮は何とかならんのかな
否定するなら、さらに良い回答で塗りつぶすぐらいの気概がある方が健全だと思う
彼は言葉は悪いけど、回答しているだけ非難だけしている人より数段マシだよ
127 = :
console.log("NumLockキーは"+event.getModifierState("NumLock")?"ON":"OFF");
129 = :
あ、MouseEventにも生えてんのか。
じゃvar fresh = true;とかしといてbodyのmousemoveとかmouseoverとかのハンドラのなかにif(fresh){さっきのconsole文;fresh=false;}すればどうか。
スマホだから確認できんけど
131 = :
すみません
javascriptの曖昧な型定義や柔軟性による複雑さは
jsDocコメントを書く事で回避できますでしょうか?
132 = :
複雑な理由はお前のコードの問題だから
JsDocどころか例え型定義があったり柔軟性がなくても
何も回避できないよ。
133 = :
>>131
jsdocて単なるJavadocのポーティングでしょ?ちゃんと書いたらそれにしたがったドキュメントを自動生成してくれるにすぎない。
flow(flowtype)やtypescriptなら型検査してくれるよ。
お手軽に始めるならflowがいいんじゃない?typescriptはちょっと(週末潰すくらい)気合い要る。
134 :
ありがとうございます。
>>132
そうですね。
その場凌ぎのプロパティ追加やコールバックの嵐等、気を付けます。
>>133
そうですね。flowやtypescriptを使って安心するの良いかもです。
しかしjavascriptはアセンブラ言語みたいな扱いをされているのが
何とも面白いですね。
135 = :
それはES2015が出る前の考え方だよ
今はWASMもあるし今更そういうこと言うやつは居ない
137 = :
idってのはhtml中に1個しか出てきちゃいけないもんだぞ
pタグであるかどうかなんて関係なく#hahahaだけでいい
まぁ別にp #hahahaとかでもいいけど
140 = :
idひとつしかつけちゃいけないって言っても、つけたから何かエラーが起きるわけでもないし普通に2つ以上についてることもある
querySelectorでp#hahahaでいいんじゃない
142 = :
>>141
そのコードの場合、fCheckに関数以外が入っている(つまりバグ)の場合に
スルーされてしまうので良くない。
if (fCheck) {
fCheck();
}
の方が良い
さらにいうなら
fCheck && fCheck();
でもよい
また予め fCheck = fCheck || function() {} などとしておけば、
fCheck(); とするだけでよくなる
143 = :
>>140
それはhtmlをまず直せって話だな
javascriptってあたりよそのhtmlいじるわけじゃないんでしょうし
144 :
>142
なんと・・・
勉強してきます、ありがとうございました
145 = :
>>140
idは一意の値であるべき。
重複してたらバグと考え、エラーにならないなら重複しても良いのではという浅い考えは捨て去るべし。
idとclassの存在意義を理解しろ。
146 = :
>>145>>143
いやもうすでに重複して使ってるサイトは山ほどあるんだから
そんなこと言ったってどうしようもないじゃないか
148 = :
構文を扱う資格なし
149 = :
フォームはnameで区別するのだから
idは基本的に使う必要はない。
150 = :
>>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()
類似してるかもしれないスレッド
- + 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
トップメニューへ / →のくす牧場書庫について