+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
+ JavaScript の質問用スレッド vol.123 +
http://peace.2ch.net/test/read.cgi/hp/1423915644/
（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです） >>747
別に必ず全部保持して全部伝える必要性は無くね？
最後のイベント保持して伝えて欲しいっていうユースケースは多いと思うよ
最近はaddEventListener第三引数にオプションオブジェクトが指定できるようになってて
間隔間引く提案とか色々されてきてるから、最後のイベントを得るようにもできるようになると思うよ >>749
韓国人死ね
お前らはそうやってすぐ声闘するのも特徴だ。
喚けばそれが事実として認識されるのは、韓国人には馬鹿しかいないから。
それで日本人を騙すのはもう無理だ。ウザイだけだから韓国人はマジで死ね。
俺の日本語に問題があるから意味が取れないという主張で俺を叩く気なら、
少なくとも>>744内の日本語は完璧じゃないといけない。（日本人的には）
間違いなく言えるのは、>>744,749は韓国人であること。
・この程度の簡単な論理すら理解できない。
・749は744の日本語の間違いに気づけないからこそ「追い打ちできる」と勘違いしている。
分かるか？表面的な書き込みではなく、相手がどうしてそういう書き込みに至ったかを読みとるんだ。
叩くなら叩くでいいとして、
肝心の先鋒744があの日本語では、普通の日本人なら二の矢を継ぐ気にはならんだろ。
そして俺はそれを正面から分かりやすく指摘してるのに、(746)
749は出てきた。この感覚の違いを読みとるんだ。
もっと単純に言えば、自分だったら何を選択するか？を考えればいい。(黙るってのも含めて)
そこで自分と違う反応をしたのなら、それは君と彼の立ち位置の違いなんだよ。
自分の立ち位置を正しく理解できているのなら、相手の立ち位置を逆算できる。
「違和感」を感じ取って、それを頼りに辿るんだよ。
JavaScriptのスレだけ酷いのは、お前らが酷いからだよ。
技術レベルも酷いが、緊喫の問題はお前らの人間レベルだ。
だから上記をよく読んで読み方を学び、このスレの何が問題なのか、各自で理解しろ。
そして誰を殺すべきか、きちんと考えろ。
繰り返すが、匿名掲示板上で殺すのは躊躇しなくていい。
それは純粋に書き込みが酷かったからであり、ここは差別の存在しようのない世界だ。
似非人権屋、パヨク、韓国人は纏めて殺していい。 >>750
> 最後のイベント保持して伝えて欲しいっていうユースケースは多いと思うよ
例えばどんなユースケース？
念の為に言っておくと最後のイベントが送られているというのは
例えば1時間前に起きたイベントをonでイベントハンドラを付けた時に伝えられるとか、
あるオブジェクトが複数種類のイベントを送信する時onchangeとかonkeydownとか
onkeyupとonclickとかonmousemoveとかその全部が送られてくるっていうことだからね
（最後の一種類しか送られてこないとしたらonmousemoveでほとんど打ち消されるだろう）
そんなことをされても迷惑な場合しか思いつかない まだ勘違いしてる点がありそうだから補足しておくと
「最後のイベントを伝える」ということの意味は
イベントを送信するsenderオブジェクトがいたとして
そのsenderオブジェクトからevent1というイベントが送信される
一時間後、reciever1がon('event1', function() })すると
すぐにイベントハンドラが呼び出される。
その一時間後、reciever2がon('event1', function() })すると
やっぱりイベントハンドラが呼び出される
その一時間後に、reciever3がon('event1', function() })するかどうかは
未来にならないとわからないので、最後のイベントであるevent1を
ずーっと保持し続けなければならないということ >>754
mousemoveが複数送られた時、最後の一つだけあればいいよね。それならメモリも少ないし
ってことじゃないのか >>756
だからそれをどういう時にそれを使いたいのか？ってことなんだ
なんども一時間後にと言ってることから推測してくれ
画面をスクロールとかしてそのイベントを発生させた
要素が画面外にある時、mousemoveを受け取って、
それでやりたいことがあるのか？ってこと
「よくあるユースケース」というがそのユースケースが思いつかないよ
逆に予想外のことが起きたとしか思わないだろう。
なんで今その要素触ってないのに、その要素からmousemouveイベとが
発生したんだ？って混乱するだけでしょ。 もちろん限られたユースケースなら考えつくと思うよ
だけど基本機能に組み込むほどの需要ないだろ？ >>751
と言うか、
>>744が日本語として完璧である必要は無いし、逆に>>751は>>744で挙げているSyncと言うかサフィックスの付け方の間違いの指摘(同期関数には無差別につけるべき、ではない)に対しての反論が含まれてるべきだと思うが。
斜めに読んだ感じ「間違ってました、ごめんなさい」が言えずに長文で論点をそらしにかかってるようにしか取れない。
だから、三行で、別の話は持ち出さずに命名規則としてソースを出して反論して。 >>757
これからはasync-awaitとESModuleが主流になってくるけど
それで必要になったときにロードかけて、例えば君が言ってたDOMCLなんかをそのモジュールから登録すると取りこぼすのよ
他に実際困ったケースを挙げるとmessageとか
取りこぼしを考えると無駄にやり取りのロジックが必要になる うーん
キャンバスでマウスの動きに合わせて特殊なラインを書くモードのボタンを押したときに
そのモジュールがロードされるまでのイベントを取りこぼしてしまうっていうのを想像したが
それだと最後の１つだけじゃ機能不足になるな
出来る限り個別の機能はモジュールに任せてメイン側で特別な工夫はしたくないとしたらどうすればいいのだろう
イベント発生を止めて貯めるということができればいいか
その間他のモジュールにも影響が出てしまうけれど、逆に他のモジュールと足並み揃えられるから現実的か
だけどモジュールによっては足並みを揃えない方が良い場合もあるだろうし
これでもモジュールが止めるまでの間、メイン側で行ったとしても実際イベントが伝播してくるイベントループと、
イベントを貯め始める処理を開始するまでの間にループがいくらか回ってしまう可能性がある
async世界で抽象化してると、イベントが起きてそのイベントハンドラの中ですぐ何かをすると言うことが難しくなる
モバイルで音声鳴らすときにも同じような問題がある
つまり、クリックされてその流れで音声鳴らすコードを書いても
思ったより間隔が開いて（確か100msくらい開くと駄目）しまうかも知れない
ということでそこだけ特別な書き方をしないといけないという問題
イベントは本当に難しい >>759-760
韓国人死ね
意味が取れないことを隠す為に「斜めに読んで」と言い訳している時点でお察し。
俺の日本語について文句を言っているのにひよるとか、マジで韓国人ですと自白しているようなもの。
(これは749の時点で既にそうだが）
お前らの立場なら、どんどん俺の日本語の問題点をあげつらってこないとおかしいだろ。
こういった、整合性が全くなく、ただ叫ぶのも連呼リアンの特徴。
「三行」の主張も中身は同じ。
俺の日本語に駄目出し出来るほど日本語が上手いつもりなら、三行にこだわるとか頭おかしいだろ。
2chの長文なんて、世間では短文だ。一瞬で読めなくてどうする？
MDNにしても、どのページも三行では書いてない。
三行しか読めないようなら、今後プログラマを続けるのは無理だ。辞めた方がいい。
池沼韓国人はマジで死ね。
まあとにかく、このスレをよくする為にはどうすればいいか、お前ら自身が考えろ。
ただそれ以前に、お前らはいろいろ読めてない。
少なくとも、俺が具体的に示していることくらいは読めるようにしろ。
そうすれば、もっと匿名掲示板を楽しめるようになるから。
そして、日本語/論理が通じない韓国人を殺すことを躊躇するな。
お前らが大学生だとして、幼稚園児に研究室に乱入してこられても困るだろ。
適当になだめて、出ていってもらうのが妥当だ。そうじゃないと研究室が機能しない。
お前らが議論したいのなら、議論に耐えない日本語/論理能力の人は出ていってもらうのが妥当だ。
これは本当に当たり前の話だ。パヨクやゴキブリ韓国人に騙されてはいけない。
レベルの高い奴らが深く話し込みたいとして、馬鹿がそれを邪魔する権利はない。 >>763
日本語が問題じゃないからあげつらわないよ。バカなの？
お前の考えてるSyncというプレフィックスの付け方が問題で、そしてそれは間違ってるって言ってるんだけど。
間違ってたか合ってたかの二択で答えられるようにしたのに、まるで日本人では無いかのように感情に基づいた(しかも意味のない)長文だな。
で、間違いか正解かどっちだったの？ 三行と言ったのは、
「合ってるor間違ってる」
「それはこういう理由」
「謝辞or訂正」
で充分だからであって、三行以上読まないって言ってる訳じゃ無い。
三行にまとめられなきゃ無能だよと言ってるだけだ。 > 三行しか読めないようなら、今後プログラマを続けるのは無理だ。辞めた方がいい。
そりゃ誰だって中身もないのに無駄な長文は読みたくないっしょ
簡潔な文が書けないと今後プログラマを続けるのは無理だからやめた方がよい >>764
韓国人死ね
> 日本語が問題じゃないからあげつらわないよ。バカなの？
なら俺の投稿を全部読み直し、お前の間違いを謝るのが先だな。
というか、日本人ならそうする。 >>761
> 君が言ってたDOMCLなんかを
何の話なのか分からんが、正しい使い方をして取りこぼしているなら
ライブラリの問題としか思わんが。
まあ実際は間違った使い方をしてるだけだろうね。
コード書いてごらん？ 修正してあげるから >>770
上で挙がってたjQueryのreadyはDOMContentLoaded過ぎても効くし、
DOMCLには対応するdocument.readyStateがあるよねってこと
例えばじゃあ今からマウスの位置に何かを表示しますってしようとしても
そこからマウスが動かなくていつまで経ってもmousemoveイベントが起きないといつまでも表示されないし、
もちろんそれで致命的な何かが起きるわけではないけれど、
今Webでもリッチなアプリが作れるようになってきてる訳でそういう細かいデザインも気になってくる
かと言ってあまり複雑なことはしたくないということ
だからdocument.readyのように
documentレイヤーだけでいいからlastEvent.mousemoveみたいなのがあったら結構楽になる
でも一々イベント履歴をチェックするのも面倒だから、できればaddEventListenerで取りたいけど、
実際無制限にするわけには行かないから、一つの落とし所としてはここからイベントを貯めるという指定ができるようにすること > 上で挙がってたjQueryのreadyはDOMContentLoaded過ぎても効くし、
readyはイベントじゃないからね
だからなんなんだ？としか思えないが
何が言いたいんだ？ >>770
そうすれば、ターゲットがクリックされたことを機会に、ターゲットをフリーズさせて、
その間にドラッグするためのモジュールを読み込んでそこから再開するというようなことができる
ただ厳密に言うと、async-await、observable的に書いたりフレームワーク使うと
そのイベントの直接のハンドラ呼び出しから同期的に処理が続くとは限らない、
例えばasync関数を呼び出すとそれは次回のジョブキューに登録され、おそらくブラウザだと次回のイベントループ時に処理される
それが組み合わさってくると、クリックされたことを契機に、それからの別のイベントを把握しようと考えても
その一瞬以下の間に１つ２つ取りこぼすロジック上の可能性を残してしまう
そしてこれが発生すると迷惑な事象、つまりバグ挙動になることが多い
ドラッグくらいじゃそんなに大したことにはならないと思うが、メッセージングとかだと０に近い可能性でも駄目なので
確実性を出すためにメッセージにidを振るだとか、再送要求を設計するとか面倒くさい気遣いがかかってしまう
結局はモバイルの音出しの問題のようにasyncな世界を外れたフックが必要になるんだけど、
そこを愚直に書くと汚らしくなるので、今のジョブキューや今のイベントループといった状態を得るためのAPIが要るんじゃないかと思う
ちょっと違うが、ECMAにZoneという、これまたまあまあ違うがNodeの昔のdomain的雰囲気を持ったAPIが提案されてるが
そういうのがいいのかもしれない >>771
> 例えばじゃあ今からマウスの位置に何かを表示しますってしようとしても
今のマウスの位置に何かを表示したいのか
それとも一時間前に発火したイベントのマウスの位置に
何かを表示したいのかはっきり言ってしてくれる？ > documentレイヤーだけでいいからlastEvent.mousemoveみたいなのがあったら結構楽になる
いらん。documentのmousemoveで
xとyを保存するだけでいい。
それだけで解決できる問題なのに
イベントの仕組みを複雑化させて
需要の少ないユースケースに対応するのはアホ >>772
要するに、asyncな世界でイベントハンドリングを確実に綺麗に上手くできやすくするための
なんらかの、そして幾つかの標準による補助機能が必要という話
たとえばaddEventListnerの第三引数のオプションの指定を増やす
抜本的な改革はその方向じゃ難しいかも知れないが、 >>774
話が噛み合っていないね
ここから先と指定できればいいが、ずっと貯めておくのは非現実的だし、
ならそういう標準的な補助の話を一旦抜きとしても一般的な話をしてもやっぱり
マウスダウンが起きた、ではここから先のマウス移動を見よう、としてもasyncな世界だと
onmousedown=e=>onmousemove=
みたいな同期的なロジックではないのだから、
クリックが起きてから、マウスの移動を検知し始めるまでに１つイベントが走ってしまうかもしてない
つまり、マウスダウンされた瞬間超人的なスピードでマウスが動いた場合、取りこぼすということ
ドラッグの話の場合大げさなことかもしれないが、
それでも同期的に書いてた頃はイベントループという仕組みでこういうケースも保護されていた
でもそれが無くなると、本当に様々な心配事が出てきて、それは実際起きうることだったりもするという話
その一つの解決策は、onmousedown=に直接フックして、同期的に>>775の処理だけでもしとくことだが、
そうするとせっかくの抽象化async世界が壊れる
それなら最初から同期的に昔からの書き方で書いとけばいいということになる
そういう問題 > つまり、マウスダウンされた瞬間超人的なスピードでマウスが動いた場合、取りこぼすということ
うん？ それが最後のイベントをonした瞬間に再生したら解決できるとでも？
Aの位置でマウスダウン発生、超人的なスピードでBの位置に移動、
onしてマウスダウンを捕まえたら、今Bの位置にいるのに
Aの位置でマウスダウン発生だよね >>779
最後のイベントだけでは有効なケースはより限られるという話はした
ただそれでもDOMC.L.みたいなケースには有効
だからそういうのもあるけど、もしくはここから先イベントを貯めると言うことができればいいかもという話もして、
それも完璧じゃないけど、改善作は欲しいよねという話になってる
だけどここまで考えてやっぱりObservableAPIが良いのかなと思い始めた
つまりdragstart = mousedown.flatMap(() =>mousemove
とかした際にそのフレームワークがしっかり可同期的に設計されていれば
とりあえず、mousedownからmousemoveまでの間の取りこぼしはなくなる
もちろんfor await dragとかをしてもそこは非同期だから
そのドラッグから次に何かをするまでの間は気をつけないといけないけれど、
こういうようにイベントを組み合わせて１つのイベントとして固めておくと言うことができればかなりの問題緩和策になる
問題はObservableが標準に入ったとき、async generatorとかあるのに対し内部的に同期で回せる設計でやってくるのかということだな なんかこの人が何を勘違いしているかわかった気がするわｗ
説明めんどくせーなー、
イベントの情報っていうのを
わかってないんだよなー
イベントを只の割り込みみたいな扱いをして
イベントの情報を使うのじゃなくて
割り込みが発生した時点の情報をかき集めて
処理しようとしてるんだな。
イベント発生時点で情報をもたせればいいだけなのに
うん、やっぱりコードの書き方が間違ってるってわかったから
もういいよｗ >>781
だから例えば、ドラッグ＝マウスダウン→flatmap:マウスムーブ→until:マウスアップ、と設計するように
あるイベントが発生してそれから先また別のイベントを補足したいってことはよくあるけど
同期的に書いてそのイベントループ中にイベントの補足を開始できればいいけど
async関数使ってると原理的にそこが保証されないコードになることがあるよね
それを簡単に改善できる方法ってないのかなって話だよ
イベント発生時点でやれば良いって言っても
async関数でイベントをawaitしてるとイベントが起きたループとは実際処理が走るのはずれるのよ
つまり
new Promise((_ok)=>{ok=_ok}).then(e=>console.log('P'))
のとき
onclick=e=>{
ok(e)
console.log('C')
}
とすると、C→Pの順番で呼ばれるでしょ？
Promiseってのか解決と同時にコールバックが走るわけじゃないんだから、
そこで隙間が開いてしまって、積み重なるとタイミングバグの元になるのよ
それを確実に回避するためにはイベントハンドラを使って同期的に処理を書き連ねていかないといけないから
async世界と相性悪いねって話だよ >>782
onした時点で最後のイベント発生してほしいという話と
全く関係ないない。
えとな、お前が言いたいのは、
イベントが発生した順番で、
イベントハンドラが呼び出されてほしい
ってだけだろ
それだけだろ。いちいち話を複雑にさせやがって
UDPの順番は保証されませんという
問題を解決する話と一緒だ。 node.jsでUTF8ファイルにBOMを追加するという処理を書きました
BOMというのはFEFFという2バイトのバイナリなので
ファイルに書き込む文字列の先頭に
'\ufeff'
を付加すればいいとネットで知り、そのとおりにやって実際に動作しています
\uを使ってバイナリを書き込むことに関して疑問を持ちました
\uという記法は4桁の16進数でUnicode文字を記述する方法とあります
Unicode文字は「任意のバイナリ」とイコールではないと思いますが、
どうなのでしょうか？
今回はFEFFが偶然unicodeのコードの範囲におさまっていたから問題なく書けたのでしょうか？
それともこの書き方でどんなバイナリデータでも書けるのでしょうか？
だとしたら「Unicode」っていう必要あるか？と思うのですが、どうなのでしょうか？ バイナリの2バイトFEFFを付加するという認識が間違ってて
UnicodeのU+FEFF ZERO WIDTH NO-BREAK SPACEを
書き込むというのが正しい うっかり投稿してしまった
U+FEFFはUTF-16（Unicode）としてはFEFFと呼称されるが
実際にファイルに書き込まれる時はエンディアンによってバイト順序が変わる
ビッグエンディアン＝FE FF
リトルエンディアン＝FF FE
だからファイルを開く際にOSが先頭2バイトを見て
FE FFならビッグエンディアンのUTF-16
FF FEならリトルエンディアンのUTF-16と判断できる >>769
謝罪だけを求めるなんてどこの国の人なんでしょ。
とりあえず、おまえがあってたか間違ってたかを答えて。
その結果俺の行動は考えるよ。
お前の自己責任で謝罪が得られていないようなもんだ。 >>785-786
FEもFFもUnicodeのコード領域に含まれたUnicode文字列なのですね
\u記法を任意のバイナリを書き込むために使うことは、できるかどうかしりませんが、
たとえできたとしても推奨はされない方法ということでしょうね
ありがとうございました FEとFFが別々の意味かと勘違いしていました
FEFFで「ZERO WIDTH NO-BREAK SPACE」という一文字なのですね ついでだから、何故韓国人を殺さなければならないか、さらに説明しておく。
非韓三原則
韓国人には、助けない、教えない、関わらない
日本人はディベートが下手だが、これは場数を踏んでないからだ。
論理は出来ている。上手くなる為には後は場数を踏むしかない。
>>757から一連のレスは（内容はさておきディベートの形式は)まあまあだ。
だから、やりたいのなら気が済むまでやればいい。
それに対して、韓国人>>760は糞だ。
これはパヨク/韓国人/ヤクザの論法で、相手にしても何も得られない。
だから相手をしてはいけない。韓国人/ヤクザは無視して殺すべきだ。
違いを見分けるのは（知っていれば）簡単だ。
ディベートはある事柄に対し「どちらがいいか」を決着する物だ。
だから通常戦術は「相手の意見を否定しつつ、『自分の意見を補強』（ここ大事）する」ことになる。
自分の意見が優勢なら＋、劣勢なら−としてスコアを付けると、
通常、双方の発言で０を挟んで天秤のように振れ、発言毎に、+1, -2, +2, -1 といった経路を辿る。
これに対して、パヨク/韓国人/ヤクザの論法はそうじゃない。
「相手を否定すること」だけを目的とし、自説の補強は全く行わない。
そして「対応できない相手が悪い」と連呼し、精神的に参らせるわけだ。
ヤクザやパヨクがよくやっている手だから見たことあると思うが。
この場合、上記スコアを付けるのなら、０から＋方向にしか振れず、意見が広がっていかない。
典型的には「対案を出せ」と対策されるケースだ。
相手は否定するばかりで、新しい知見を出さないものだから、
結局自分の意見の範囲でしか広がらず、ブレストにもならない。
韓国人死ね > 命名規則としてソースを出して反論して (>>760)
ディベートに持ち込み、どちらが優位か結論を出す気なら、
760自身が「命名規則としてソースを出して」自説を補強すれば、それで済む。
それをせず、相手に要求して連呼するのはヤクザのやり方。上記通りだ。
相手にしたところで、何も得られない。だから無視して殺さなければならない。
多分、韓国人流の精神的勝利法の一環なんだと思うが、
そもそも、匿名掲示板上で勝った負けたしても意味無いだろ。
ここでやるべきなのは、「その案件について、一番妥当だと思える意見は何か」であって、
それを「誰が言ったか」は価値がないと見なすから匿名なのであって。
だから、何であっても、「それについては俺はこう思う、理由はこうだから（自説の補強）」が匿名掲示板での基本スタイルで、
相手に対して優位に立つ為の「相手の意見を否定する」戦術は基本的に必要ない。
そしてどっちの意見が妥当かは読者が勝手に判断するだけ。
相手の意見を全部否定できたとしても、スコアは０には戻るが、＋にはならない。
つまり、否定するだけだと引き分けには持ち込めるが、絶対に勝てない。
勝つ為に＋にしたいのなら、自説の補強をするしかないんだよ。しない時点でアホ確定だ。
だから繰り返すが、
> 命名規則としてソースを出して反論して (>>760)
この発言だけでこいつは馬鹿だと分かる。相手をしても何も得られない。
勝ちたいのなら、勝手にソースを出して自説の信者が増えるよう努力すればいいだけの話だ。
それが妥当かどうかは読者が勝手に判断してくれる。俺が否定しようがしまいが、関係ない。
ということを念頭に置きつつ、ディベートしたい奴は気が済むまでやればいい。場数を踏めば上手くなる。
ここは匿名掲示版なんだから、基本戦術は、「俺はこう思う、理由はこう（自説の補強）」でよろしく。
他人の意見を否定しても勝てない。勝つ気なら、よりよい意見で「上書き」することを目指せ。
あんまり酷いようなら行司してやるよ。
とはいえ、今のところ「余計なお世話」になりそうなのはいいことだね。
韓国人死ね 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) うーん、同期関数しか用意しない場合はSyncはつけるべきじゃない、と何度言ったらわかるのかな。
requireって非同期でうごくっけ？とか色々あるだろうに。 さらについでに講評しとくと、
>>777の時点で理解できないのは777がアホだから。
そこまでに十分な説明はなされているし、俺には通じてる。説明も下手ではない。
> そうすれば、ターゲットがクリックされたことを機会に、ターゲットをフリーズさせて、
> その間にドラッグするためのモジュールを読み込んでそこから再開するというようなことができる(>>773)
JavaScriptはそのように設計はされていない。
だからこれをやりたいのなら、何らかのサポートが必要なのも事実。
とはいえ、このやり方が必要かは議論になるだろう。
> だけどここまで考えてやっぱりObservableAPIが良いのかなと思い始めた (>>780)
> async世界と相性悪いねって話だよ (>>782)
はっきり言えばJavaScript含めて一般のプログラミング言語は
同期的に処理が行われる前提だからそもそも相性が悪い。
と言っても通じないだろうから簡単に説明すると、
var a = 1; // (A)
a = a + 1; // (B)
console.log(a); // (C)
とあった場合、(A)(B)(C)の順に処理されて2が出力されることを当然だと思ってるだろ？
世の中にはそうじゃない言語もある。
https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
韓国人死ね >>782(続き）
プログラミング言語ではないが、verilogで説明すると、
assign a = b;
は b が変化するたびに再評価されて a = b が定常的には保証される。
JavaScriptで言えば
Object.observe(b, function(){ a = b;});
とほぼ同じと考えていい。
だからverilogの場合は(A)(B)(C)は独立な関数であって、実行順は規定されない。
必要なときに必要な順で評価される。この点はHaskellも同じで、例えば、
console.log(b);
assign b = a + 1;
assign a = 1;
については、JavaScriptならundefinedになるが、verilogとHaskellでは2と正しく評価される。
だからHaskellについて詳しいのなら、そっちから考えてもいいだろう。
Haskellは遅延評価でしかないが、初期値の計算方法自体はデータフロー型と似ているところがある。
君はイベントをデータフロー的に接続することを考えている。
それが効率がいいのかは俺には分からない。
ただし、一般的にverilogは難しいとされるから、その方法は流行りにくいだろう。
JavaScriptでは関数単位で非同期だが、verilogは行単位で非同期で、これについて行けない奴が多い。
JavaScriptでもそうだが、同期的に書きたがる奴はいるだろ？
結局の所、同期的に書けること自体が簡単なんだよ。そして簡単なことは重要な事なんだ。
君はJavaScriptをverilog化しようとしている。それは多分受けない。
韓国人死ね ソースも何もなぁ。
最初に自分が張ったURLから辿れるように
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking
であるように
All of the I/O methods in the Node.js standard library provide asynchronous versions, which are non-blocking,
and accept callback functions. Some methods also have blocking counterparts, which have names that end with Sync.
いくつかは、Syncで終わる、対応する非同期関数の同期版があるよ(同期関数だからSyncだとは言ってない)、とか
https://github.com/nodejs/node/issues/5
で議論されてるように、とてもライトウェイトな同期関数はもういいんじゃねえの？
みたいな話に落ち着くんじゃない？
requireの名前がrequireSyncに変わったらまた声高らかに演説してくれたら良いよ。
変わらないうちは、同期関数しかない物は別にSyncで終わる必要はないと言いたいが。 >>794
verilogが常にすべて同時に動くのはそういう問題じゃないだろ。
メッセージポンプが全てって割とあるんじゃねえの？
メッセージポンプだけじゃなくてデータも一方向にしか流さないFlux的な考え方が何度めかの流行りだったんだし。 >>795
それに対する返答も、俺は既に書いている。
日本語が読めるつもりなら、俺の投稿を理解できるまで読み返し、ちゃんと自殺しろ。
韓国人死ね 最近書いたコード、ほとんどすべての行にawaitが入っててさながら「await地獄」だったわ。 繰り返すが、韓国人を殺すことを躊躇するな。
お前らにも彼らの論理の稚拙さは分かるだろ。邪魔なだけだ。
なぜJavaScriptのスレにだけゴキブリ韓国人が溜まるのかはさっぱり分からないが、
とにかくこのスレを正常化する為にはまずは汚物を消毒するしかない。
お前らの議論スキルが低すぎるから、韓国人やパヨクの詭弁に騙される。
だから俺がグダグダとお前らに議論のやり方を説明している。
冷静に見て、彼らは邪魔してるだけだ。それに気付け。そしてきちんと殺しきれ。
例えば、>>795は>>742の時点で書けるレスだ。
それを書かないのは、意図的に邪魔しようとしているか、そもそも議論の能力がないか。
区別する必要はない。どちらも殺処分でいい。邪魔なだけだ。
韓国人死ね
対して>>747は、基本的に自説の開陳＆補強で突っ走ってるだろ。
匿名掲示板上の議論はこれで正しい。だからまあまあの議論になる。
>>778に関しては、自分で修正できているし、説明も議論も十分上手い。まあ要らん世話だろうがね。
今のお前らは、仮にジェンヌと同じ削能力を与えられたとしても、
誰が問題なのか分からず、スレを良くできない。
これでは良いスレは持てない。民主主義と同じで、自分たちの議論能力以上のスレは持てないのだよ。
だからお前らにはまず議論上手になってもらう必要がある。
リアルの議論はリアルタイム性がありなかなか難しいが、
ここでの議論は、何度でも読み返せるし、じっくり考えられる。この点は学習には向いている。
だからまずは議論が上手くなってくれ。そして誰が問題なのか、ちゃんと見抜けるようになってくれ。
ゴキブリ韓国人マジで死ね
邪魔するだけの奴を殺すことを躊躇する必要はない Electronでアプリを作っている者ですが
CSS Grid Layoutというものを知りました
今まではHTML5+CSS3で苦労してレイアウトしていたのですが
簡単にレイアウトできるCSS Grid Layoutというものがあり、
それはもうChromeで、つまりElectronで使えると。
今まで何してたんだろうと思わずにはいられません
JavaScripterといえどもCSS方面のキャッチアップも怠ってはいけないですね？ Gridとかもう古い方だよ
JSer的にはこれからはHoudiniを勉強していこう HoudiniはローレベルAPIだからこれが早々古くなるのは考えにくい
半年後だとまだHoudiniの一部が実装中の段階だと思う HoudiniというのはCSSをJavaScriptで操作できるようにするものなのですね
Electronを使いはじめてから、ブラウザ対応を考えなくていい良さをしみじみと実感したので
ブラウザ間の差異が吸収されていく流れは歓迎です
ありがとうございました Houdiniって低レベルAPI用意してやったからお前ら自分たちで好きなライブラリ作って勝手にやれよ、という標準団体からのメッセージだから
このスレにもその内難しくてセンシティブな低レベルAPIの質問と、誰もが初めて聞くようなマイナーライブラリの質問が増えてくるんだろうな
JSは色々自由な所が多いが、どういう構文使ってどういうAPI使うかは、標準やブラウザの実装状況から判断すれば良かった
でもこれからはライブラリの作者とユーザーが考えないといけなくなりそうだね JSの世界ってそんな感じだよな
標準で提供するのは低レベルAPIです。
あとはjQueryなり好きなライブラリを作って
それを使ってください 最終的にはオレオレCSSの定義からペイント、レイアウトまでJSで行えるのがHoudiniだから
jQuery時代のラッパーライブラリとは次元が違ってくるとは思うけどな > オレオレCSSの定義からペイント、レイアウトまで
ん？ それってレンダリング周りしかできないってこと？
じゃあDOM操作のjQueryとはかぶらないのか >>809
その通り
レイアウトを担当する所謂jQueryライブラリには関係があるかも知れないが、本体とは関係ない
ただ仕様群のうちTyped OMだけは幅広いユーザーやライブラリに影響もとい恩恵がある ReactとTypeScriptはHTMLに型を与えてくれた。
IDE経由で必要なプロパティが分かるのはほんとありがたい。
cssもそういう方向に進んでくれたらありがたい 値を文字列として読み書きするのが.innerHTMlのように時代遅れになる日も近いな 上で話題になってたことと関連して
今年はロックやスケジューリング機能が入ったマルチスレッドDOMの話が進みそう
今非同期を使い倒さないといけないのって、結局UIスレッドが１つでメインスクリプトはそれを妨害しないように動かないといけないからで
Houdiniと一緒にDOMもパーツ毎に別スレッドで制御できれば、ただ同期的に書けばいいだけになるよね >>813
マルチスレッドになるとかやべえ。
iOSアプリだって描画系はシングルスレッドで動かしてるし、絶対デットロックするだろ。 マルチスレッド自体はWorkerや非同期XHR、タイマーなどでもできるが
マルチスレッドDOMって何ぞ？ 読んでないけど、ページを論理的に分割する方法があれば
マルチスレッドDOMは実現できるでしょ？
コンポーネントに分割して外部とやり取りする
インターフェース経由でしかアクセス出来ないようにすれば良い メニューと本文を別々にロードするようなものなら、XHRを2つ使えば可能なんだけど
マルチスレッドDOMはJSでやるものではなくブラウザの実装の問題じゃないのかな
たしかにテーブルや複雑な段組み表示で描画が待たされるけど
上部のレイアウトが決まらないと下部の描画ができないのはどうしようもない
擬似フレーム、レイヤー、サイドバーを別スレッドで描画するというのならできそうではあるけど
（ブラウザを作るのは人ごとなので、言うだけなら何とでも言える）
iframeで分割してpostMessage()するのは現行規格でもできるけどね rustを使って開発してるFirefoxの
レンダリングエンジンはマルチコアに最適化してるんだっけ
ということはマルチスレッドでDOMが動いてる？
とりあえず最終的な描画部分はマルチスレッドになったとしてもjs側はシングルスレッドのままな気がする。
そもそも描画系以外の処理はserviceWorkerとか使えばマルチスレッドぽくなるんだからそれで良くないか？ レイアウトとレンダリングに関してはすでにHoudiniで定義されている
Workerはオーバーヘッドが大きいのでWorkletという
レンダリングエンジンの各作業スレッドの拡張ポイントとしてJSを動かす仕組みで行う
あとある部分のレイアウトが完全に決まっていなくてもとりあえずの値で確定させて描画ができる
画像が読み込み中の場合を考えたらいい 単にマルチスレッドで複数の要素をアニメーションさせたいだけであれば、
アニメーションさせたい要素の数だけタイマーを生成すれば可能かと
（ただしJSアニメーションはCSSアニメーションに比べて処理速度が遅い）
シングルスレッドのアニメーション（タイマーを1つ生成）
function anim_all(){
要素Aをアニメーション;
要素Bをアニメーション;
requestAnimationFrame(anim_all);
}
requestAnimationFrame(anim_all);
マルチスレッドのアニメーション（タイマーを2つ生成）
function anim_a(){
要素Aをアニメーション;
requestAnimationFrame(anim_a);
}
function anim_b(){
要素Bをアニメーション;
requestAnimationFrame(anim_b);
}
requestAnimationFrame(anim_b); ついでだから聞くんだけどxhrをworkerで動かしてるサンプルがあったんだけど
あれって普通にxhr使うより早くなんの？ ファイルを取得するとこまでは殆ど関係ないけど
それを使って重い処理をWorkerでするのなら
取得もWorkerでするのが普通でしょ JavaScriptで大文字と小文字の使い分けをどうしているのかが最大の謎
たとえばJavaなら
Hoge hoge = new Hoge();
ならば、「hoge」はインスタンス、そして「Hoge」はクラス名
だと分かる。
ところが、JSの場合、
var hoge = new Hoge();
のとき「Hoge」はクラスではなくこちらも「オブジェクト」だから、
「hoge」も「オブジェクト」「Hoge」も「オブジェクト」じゃん？
だけど片方は大文字で片方は小文字だから結局「頭が大文字な変数」と
「頭が小文字な変数」の何を見分けていいかわからなくなる。
「hoge」があったときにこれがオブジェクトなのか関数なのか
プロトタイプなのかコンストラクタなのか一体何者なのかさっぱり分からん。 >>826
実体が○○だから、こうするって考え方は初心者だよ
どうしたいのか、どういう意図を込めたいのか、その考えをコードに反映させる。
と言っても意味がわからないだろうな。
古いGoogleのコーディング規約だがその一節にこういうものが有る
http://cou929.nu/data/google_javascript_style_guide/#constant-values
> 一定で不変であることを意図した値には CONSTANT_VALUE_CASE のように定数としての名前をつけます.
> 加えて, すべてを大文字にし単語をアンダースコアで区切るようにすることは
> @const (その値は overwrite できない) という意味にもなります..
これが書かれた当時はconstというものはなく、実体は只の変数にすぎない。
只の変数に「定数である」という意図を込めるために、全部大文字にするわけだ
Hogeも同じ。実体が関数かオブジェクトかってのは関係ない。
例え実体は関数やオブジェクトであっても、それ（Hoge）にクラスだよという
意図を込めるために大文字で始める。
ならばそれを見た人は、Hogeをクラス名だと考えるようにしないといけない
（もちろんコーディング規約次第だが）
Hogeをどのように作り出すかは関係なく、大文字で始まっているのだからそれはクラス
逆に言えば、クラスとして見せたいから大文字で始める。そういう意図を込めるわけだよ。
コードっていうのは自分の考えを反映させて書くもの。
コードがどうなっているかではなく、自分がどうしたいか。
そして読むときは書いた人の意図を読み取れるようなろう。
実体が何かで考えているうちはまだまだ初心者
> 「hoge」があったときにこれがオブジェクトなのか関数なのか
一般的にはhogeが名詞ならオブジェクト。動詞なら関数。 馬鹿は答えるな。node.jsのwsモジュールでws.oncloseに関数を代入するやりかたと
ws.on('close',callback)を使うやりかたのなにが違うのか分かりません。
教えてください。 CSSエンジンをJavaScriptで組んだものってありますか？ CSSエンジンってなんや？
どこからどこまでをさすんや？ HTMLとCSSをレンダリングするようなやつです
floatのアルゴリズムを知りたいのです SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？
現状
https://support.google.com/webmasters/answer/181708?hl=ja
に示すみたいにソフト404エラーみたいになってるんですが
SPAでステータスコードを返す方法がよくわからないんです。 >>835
つまり404は普通にwebPageとして作ってリダイレクトしろよと。 それは現実的じゃないと思うな
直リンクとSPAでの遷移が違うと不自然だし
SPAでの遷移で存在しない場合リダイレクトするのも不自然だし
今だとServiceWorkerとかもあるし ソフト404でいいと思うけどな。googleが悪い。 >>834
一応JavascriptスレだからNode.jsで答えるけど
res.status(404);
res.send('File Not Found');
でいいのでは SPAとしての決まりはあんまりない感じなんですかね？stackoverflowを見るとgoogleがリダイレクトで404で飛ばすようにサービス作ってるからそれでいいのでは？という話でした。 SPAっていうのもピンきりだから
mobile jQueryを使ったりしてただ単にリクエスト量削減のオマケなら404を返せばいいし、
アプリケーションと呼ぶようなものならそうしなければいい >>842
Googleの場合色んな検索窓があるページがSPAだけど、
考え方によっちゃヒットの無いキーワードでの検索っていうのは
404に当たるものだけど返してないよね
逆にそういう１つのアプリケーション内で
404にリダイレクトせざるを得ない事なんて考えにくいよね 検索結果が０件であることと、検索結果ページが存在しないことは別物 >>844
> 考え方によっちゃヒットの無いキーワードでの検索っていうのは
> 404に当たるものだけど返してないよね
ないわ〜 >>846
何言ってんだ？
商品ページがない場合は404だろ >>848
言いなおそう
検索結果が0件であることと、検索結果を表示するためのページが存在しないことと、
検索結果を表示するためのページからリンクをたどった先のページが存在しないことは別物 んで、質問内容は、リンクを辿った先のページがない時に
404を返すにはどうするかって話だろ ■ このスレッドは過去ログ倉庫に格納されています
