+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/03/22(日) 16:19:45.75

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です）

**デフォルトの名無しさん** · 2018/02/02(金) 01:35:18.66

>>779
最後のイベントだけでは有効なケースはより限られるという話はした
ただそれでもDOMC.L.みたいなケースには有効
だからそういうのもあるけど、もしくはここから先イベントを貯めると言うことができればいいかもという話もして、
それも完璧じゃないけど、改善作は欲しいよねという話になってる

だけどここまで考えてやっぱりObservableAPIが良いのかなと思い始めた
つまりdragstart = mousedown.flatMap(() =>mousemove
とかした際にそのフレームワークがしっかり可同期的に設計されていれば
とりあえず、mousedownからmousemoveまでの間の取りこぼしはなくなる

もちろんfor await dragとかをしてもそこは非同期だから
そのドラッグから次に何かをするまでの間は気をつけないといけないけれど、
こういうようにイベントを組み合わせて１つのイベントとして固めておくと言うことができればかなりの問題緩和策になる

問題はObservableが標準に入ったとき、async generatorとかあるのに対し内部的に同期で回せる設計でやってくるのかということだな

**デフォルトの名無しさん** · 2018/02/02(金) 01:36:39.52

なんかこの人が何を勘違いしているかわかった気がするわｗ

説明めんどくせーなー、
イベントの情報っていうのを
わかってないんだよなー

イベントを只の割り込みみたいな扱いをして
イベントの情報を使うのじゃなくて
割り込みが発生した時点の情報をかき集めて
処理しようとしてるんだな。

イベント発生時点で情報をもたせればいいだけなのに

うん、やっぱりコードの書き方が間違ってるってわかったから
もういいよｗ

**デフォルトの名無しさん** · 2018/02/02(金) 01:57:53.92

>>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世界と相性悪いねって話だよ

**デフォルトの名無しさん** · 2018/02/02(金) 02:15:59.03

>>782
onした時点で最後のイベント発生してほしいという話と
全く関係ないない。

えとな、お前が言いたいのは、
イベントが発生した順番で、
イベントハンドラが呼び出されてほしい
ってだけだろ

それだけだろ。いちいち話を複雑にさせやがって

UDPの順番は保証されませんという
問題を解決する話と一緒だ。

**デフォルトの名無しさん** · 2018/02/02(金) 13:49:28.44

node.jsでUTF8ファイルにBOMを追加するという処理を書きました
BOMというのはFEFFという2バイトのバイナリなので
ファイルに書き込む文字列の先頭に
'\ufeff'
を付加すればいいとネットで知り、そのとおりにやって実際に動作しています
\uを使ってバイナリを書き込むことに関して疑問を持ちました
\uという記法は4桁の16進数でUnicode文字を記述する方法とあります
Unicode文字は「任意のバイナリ」とイコールではないと思いますが、
どうなのでしょうか？
今回はFEFFが偶然unicodeのコードの範囲におさまっていたから問題なく書けたのでしょうか？
それともこの書き方でどんなバイナリデータでも書けるのでしょうか？
だとしたら「Unicode」っていう必要あるか？と思うのですが、どうなのでしょうか？

**デフォルトの名無しさん** · 2018/02/02(金) 14:10:56.79

バイナリの2バイトFEFFを付加するという認識が間違ってて
UnicodeのU+FEFF ZERO WIDTH NO-BREAK SPACEを
書き込むというのが正しい

**デフォルトの名無しさん** · 2018/02/02(金) 14:14:50.57

うっかり投稿してしまった
U+FEFFはUTF-16（Unicode）としてはFEFFと呼称されるが
実際にファイルに書き込まれる時はエンディアンによってバイト順序が変わる
ビッグエンディアン＝FE FF
リトルエンディアン＝FF FE

だからファイルを開く際にOSが先頭2バイトを見て
FE FFならビッグエンディアンのUTF-16
FF FEならリトルエンディアンのUTF-16と判断できる

**デフォルトの名無しさん** · 2018/02/02(金) 14:47:14.31

>>769
謝罪だけを求めるなんてどこの国の人なんでしょ。

とりあえず、おまえがあってたか間違ってたかを答えて。
その結果俺の行動は考えるよ。
お前の自己責任で謝罪が得られていないようなもんだ。

**デフォルトの名無しさん** · 2018/02/02(金) 15:30:38.66

>>785-786
FEもFFもUnicodeのコード領域に含まれたUnicode文字列なのですね
\u記法を任意のバイナリを書き込むために使うことは、できるかどうかしりませんが、
たとえできたとしても推奨はされない方法ということでしょうね
ありがとうございました

**デフォルトの名無しさん** · 2018/02/02(金) 16:18:08.94

FEとFFが別々の意味かと勘違いしていました
FEFFで「ZERO WIDTH NO-BREAK SPACE」という一文字なのですね

**デフォルトの名無しさん** · 2018/02/02(金) 22:51:14.28

ついでだから、何故韓国人を殺さなければならないか、さらに説明しておく。

非韓三原則
韓国人には、助けない、教えない、関わらない

日本人はディベートが下手だが、これは場数を踏んでないからだ。
論理は出来ている。上手くなる為には後は場数を踏むしかない。
>>757から一連のレスは（内容はさておきディベートの形式は)まあまあだ。
だから、やりたいのなら気が済むまでやればいい。

それに対して、韓国人>>760は糞だ。
これはパヨク/韓国人/ヤクザの論法で、相手にしても何も得られない。
だから相手をしてはいけない。韓国人/ヤクザは無視して殺すべきだ。

違いを見分けるのは（知っていれば）簡単だ。
ディベートはある事柄に対し「どちらがいいか」を決着する物だ。
だから通常戦術は「相手の意見を否定しつつ、『自分の意見を補強』（ここ大事）する」ことになる。
自分の意見が優勢なら＋、劣勢なら－としてスコアを付けると、
通常、双方の発言で０を挟んで天秤のように振れ、発言毎に、+1, -2, +2, -1 といった経路を辿る。

これに対して、パヨク/韓国人/ヤクザの論法はそうじゃない。
「相手を否定すること」だけを目的とし、自説の補強は全く行わない。
そして「対応できない相手が悪い」と連呼し、精神的に参らせるわけだ。
ヤクザやパヨクがよくやっている手だから見たことあると思うが。
この場合、上記スコアを付けるのなら、０から＋方向にしか振れず、意見が広がっていかない。
典型的には「対案を出せ」と対策されるケースだ。
相手は否定するばかりで、新しい知見を出さないものだから、
結局自分の意見の範囲でしか広がらず、ブレストにもならない。

韓国人死ね

**デフォルトの名無しさん** · 2018/02/02(金) 22:52:10.85

> 命名規則としてソースを出して反論して (>>760)
ディベートに持ち込み、どちらが優位か結論を出す気なら、
760自身が「命名規則としてソースを出して」自説を補強すれば、それで済む。
それをせず、相手に要求して連呼するのはヤクザのやり方。上記通りだ。
相手にしたところで、何も得られない。だから無視して殺さなければならない。

多分、韓国人流の精神的勝利法の一環なんだと思うが、
そもそも、匿名掲示板上で勝った負けたしても意味無いだろ。
ここでやるべきなのは、「その案件について、一番妥当だと思える意見は何か」であって、
それを「誰が言ったか」は価値がないと見なすから匿名なのであって。

だから、何であっても、「それについては俺はこう思う、理由はこうだから（自説の補強）」が匿名掲示板での基本スタイルで、
相手に対して優位に立つ為の「相手の意見を否定する」戦術は基本的に必要ない。
そしてどっちの意見が妥当かは読者が勝手に判断するだけ。
相手の意見を全部否定できたとしても、スコアは０には戻るが、＋にはならない。
つまり、否定するだけだと引き分けには持ち込めるが、絶対に勝てない。
勝つ為に＋にしたいのなら、自説の補強をするしかないんだよ。しない時点でアホ確定だ。

だから繰り返すが、
> 命名規則としてソースを出して反論して (>>760)
この発言だけでこいつは馬鹿だと分かる。相手をしても何も得られない。
勝ちたいのなら、勝手にソースを出して自説の信者が増えるよう努力すればいいだけの話だ。
それが妥当かどうかは読者が勝手に判断してくれる。俺が否定しようがしまいが、関係ない。

ということを念頭に置きつつ、ディベートしたい奴は気が済むまでやればいい。場数を踏めば上手くなる。
ここは匿名掲示版なんだから、基本戦術は、「俺はこう思う、理由はこう（自説の補強）」でよろしく。
他人の意見を否定しても勝てない。勝つ気なら、よりよい意見で「上書き」することを目指せ。
あんまり酷いようなら行司してやるよ。
とはいえ、今のところ「余計なお世話」になりそうなのはいいことだね。

韓国人死ね 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2018/02/02(金) 22:52:57.96

うーん、同期関数しか用意しない場合はSyncはつけるべきじゃない、と何度言ったらわかるのかな。
requireって非同期でうごくっけ？とか色々あるだろうに。

**デフォルトの名無しさん** · 2018/02/02(金) 22:53:36.67

さらについでに講評しとくと、
>>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

韓国人死ね

**デフォルトの名無しさん** · 2018/02/02(金) 22:55:10.28

>>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化しようとしている。それは多分受けない。

韓国人死ね

**デフォルトの名無しさん** · 2018/02/02(金) 23:08:38.80

ソースも何もなぁ。
最初に自分が張った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で終わる必要はないと言いたいが。

**デフォルトの名無しさん** · 2018/02/02(金) 23:13:56.08

>>794
verilogが常にすべて同時に動くのはそういう問題じゃないだろ。

メッセージポンプが全てって割とあるんじゃねえの？
メッセージポンプだけじゃなくてデータも一方向にしか流さないFlux的な考え方が何度めかの流行りだったんだし。

**デフォルトの名無しさん** · 2018/02/02(金) 23:34:40.13

>>795
それに対する返答も、俺は既に書いている。
日本語が読めるつもりなら、俺の投稿を理解できるまで読み返し、ちゃんと自殺しろ。

韓国人死ね

**デフォルトの名無しさん** · 2018/02/02(金) 23:39:27.35

最近書いたコード、ほとんどすべての行にawaitが入っててさながら「await地獄」だったわ。

**デフォルトの名無しさん** · 2018/02/03(土) 00:18:22.95

>>797
そうですか、お疲れ様。

**デフォルトの名無しさん** · 2018/02/03(土) 00:19:45.31

繰り返すが、韓国人を殺すことを躊躇するな。
お前らにも彼らの論理の稚拙さは分かるだろ。邪魔なだけだ。
なぜJavaScriptのスレにだけゴキブリ韓国人が溜まるのかはさっぱり分からないが、
とにかくこのスレを正常化する為にはまずは汚物を消毒するしかない。

お前らの議論スキルが低すぎるから、韓国人やパヨクの詭弁に騙される。
だから俺がグダグダとお前らに議論のやり方を説明している。
冷静に見て、彼らは邪魔してるだけだ。それに気付け。そしてきちんと殺しきれ。
例えば、>>795は>>742の時点で書けるレスだ。
それを書かないのは、意図的に邪魔しようとしているか、そもそも議論の能力がないか。
区別する必要はない。どちらも殺処分でいい。邪魔なだけだ。

韓国人死ね

対して>>747は、基本的に自説の開陳＆補強で突っ走ってるだろ。
匿名掲示板上の議論はこれで正しい。だからまあまあの議論になる。
>>778に関しては、自分で修正できているし、説明も議論も十分上手い。まあ要らん世話だろうがね。

今のお前らは、仮にジェンヌと同じ削能力を与えられたとしても、
誰が問題なのか分からず、スレを良くできない。
これでは良いスレは持てない。民主主義と同じで、自分たちの議論能力以上のスレは持てないのだよ。
だからお前らにはまず議論上手になってもらう必要がある。
リアルの議論はリアルタイム性がありなかなか難しいが、
ここでの議論は、何度でも読み返せるし、じっくり考えられる。この点は学習には向いている。
だからまずは議論が上手くなってくれ。そして誰が問題なのか、ちゃんと見抜けるようになってくれ。

ゴキブリ韓国人マジで死ね
邪魔するだけの奴を殺すことを躊躇する必要はない

**デフォルトの名無しさん** · 2018/02/03(土) 07:38:45.12

Electronでアプリを作っている者ですが
CSS Grid Layoutというものを知りました
今まではHTML5+CSS3で苦労してレイアウトしていたのですが
簡単にレイアウトできるCSS Grid Layoutというものがあり、
それはもうChromeで、つまりElectronで使えると。
今まで何してたんだろうと思わずにはいられません
JavaScripterといえどもCSS方面のキャッチアップも怠ってはいけないですね？

**デフォルトの名無しさん** · 2018/02/03(土) 13:03:30.64

Gridとかもう古い方だよ
JSer的にはこれからはHoudiniを勉強していこう

**デフォルトの名無しさん** · 2018/02/03(土) 13:19:38.88

半年後・・・

Houdiniとかもう古いよ

**デフォルトの名無しさん** · 2018/02/04(日) 05:03:12.23

HoudiniはローレベルAPIだからこれが早々古くなるのは考えにくい
半年後だとまだHoudiniの一部が実装中の段階だと思う

**デフォルトの名無しさん** · 2018/02/04(日) 11:43:44.83

HoudiniというのはCSSをJavaScriptで操作できるようにするものなのですね
Electronを使いはじめてから、ブラウザ対応を考えなくていい良さをしみじみと実感したので
ブラウザ間の差異が吸収されていく流れは歓迎です
ありがとうございました

**デフォルトの名無しさん** · 2018/02/04(日) 12:14:34.20

Houdiniって低レベルAPI用意してやったからお前ら自分たちで好きなライブラリ作って勝手にやれよ、という標準団体からのメッセージだから
このスレにもその内難しくてセンシティブな低レベルAPIの質問と、誰もが初めて聞くようなマイナーライブラリの質問が増えてくるんだろうな

JSは色々自由な所が多いが、どういう構文使ってどういうAPI使うかは、標準やブラウザの実装状況から判断すれば良かった
でもこれからはライブラリの作者とユーザーが考えないといけなくなりそうだね

**デフォルトの名無しさん** · 2018/02/04(日) 12:30:29.21

JSの世界ってそんな感じだよな
標準で提供するのは低レベルAPIです。
あとはjQueryなり好きなライブラリを作って
それを使ってください

**デフォルトの名無しさん** · 2018/02/04(日) 16:36:41.51

最終的にはオレオレCSSの定義からペイント、レイアウトまでJSで行えるのがHoudiniだから
jQuery時代のラッパーライブラリとは次元が違ってくるとは思うけどな

**デフォルトの名無しさん** · 2018/02/04(日) 16:39:21.65

> オレオレCSSの定義からペイント、レイアウトまで

ん？それってレンダリング周りしかできないってこと？
じゃあDOM操作のjQueryとはかぶらないのか

**デフォルトの名無しさん** · 2018/02/04(日) 19:33:02.43

>>809
その通り
レイアウトを担当する所謂jQueryライブラリには関係があるかも知れないが、本体とは関係ない
ただ仕様群のうちTyped OMだけは幅広いユーザーやライブラリに影響もとい恩恵がある

**デフォルトの名無しさん** · 2018/02/05(月) 11:43:34.20

ReactとTypeScriptはHTMLに型を与えてくれた。
IDE経由で必要なプロパティが分かるのはほんとありがたい。

cssもそういう方向に進んでくれたらありがたい

**デフォルトの名無しさん** · 2018/02/05(月) 14:03:07.36

値を文字列として読み書きするのが.innerHTMlのように時代遅れになる日も近いな

**デフォルトの名無しさん** · 2018/02/06(火) 12:17:27.83

上で話題になってたことと関連して
今年はロックやスケジューリング機能が入ったマルチスレッドDOMの話が進みそう
今非同期を使い倒さないといけないのって、結局UIスレッドが１つでメインスクリプトはそれを妨害しないように動かないといけないからで
Houdiniと一緒にDOMもパーツ毎に別スレッドで制御できれば、ただ同期的に書けばいいだけになるよね

**デフォルトの名無しさん** · 2018/02/06(火) 17:27:24.12

>>813

マルチスレッドになるとかやべえ。
iOSアプリだって描画系はシングルスレッドで動かしてるし、絶対デットロックするだろ。

**デフォルトの名無しさん** · 2018/02/06(火) 20:43:33.16

マルチスレッドDOMってどこで検討が進んでるの？

**デフォルトの名無しさん** · 2018/02/06(火) 23:49:08.32

マルチスレッド自体はWorkerや非同期XHR、タイマーなどでもできるが
マルチスレッドDOMって何ぞ？

**デフォルトの名無しさん** · 2018/02/07(水) 00:29:03.84

https://docs.google.com/document/d/17LQtUzxNj31ElYCk_Ozgn4kJqQktrK8m6I8e1i7948I/edit
https://github.com/chrishtr/async-dom/
Googleの議論で挙がりましたってとこか

**デフォルトの名無しさん** · 2018/02/07(水) 00:51:26.45

読んでないけど、ページを論理的に分割する方法があれば
マルチスレッドDOMは実現できるでしょ？
コンポーネントに分割して外部とやり取りする
インターフェース経由でしかアクセス出来ないようにすれば良い

**816** · 2018/02/07(水) 07:05:53.98

メニューと本文を別々にロードするようなものなら、XHRを2つ使えば可能なんだけど
マルチスレッドDOMはJSでやるものではなくブラウザの実装の問題じゃないのかな

たしかにテーブルや複雑な段組み表示で描画が待たされるけど
上部のレイアウトが決まらないと下部の描画ができないのはどうしようもない

擬似フレーム、レイヤー、サイドバーを別スレッドで描画するというのならできそうではあるけど
（ブラウザを作るのは人ごとなので、言うだけなら何とでも言える）
iframeで分割してpostMessage()するのは現行規格でもできるけどね

**デフォルトの名無しさん** · 2018/02/07(水) 10:57:44.93

rustを使って開発してるFirefoxの
レンダリングエンジンはマルチコアに最適化してるんだっけ
ということはマルチスレッドでDOMが動いてる？
とりあえず最終的な描画部分はマルチスレッドになったとしてもjs側はシングルスレッドのままな気がする。
そもそも描画系以外の処理はserviceWorkerとか使えばマルチスレッドぽくなるんだからそれで良くないか？

**デフォルトの名無しさん** · 2018/02/07(水) 18:14:47.81

レイアウトとレンダリングに関してはすでにHoudiniで定義されている
Workerはオーバーヘッドが大きいのでWorkletという
レンダリングエンジンの各作業スレッドの拡張ポイントとしてJSを動かす仕組みで行う

あとある部分のレイアウトが完全に決まっていなくてもとりあえずの値で確定させて描画ができる
画像が読み込み中の場合を考えたらいい

**デフォルトの名無しさん** · 2018/02/07(水) 20:15:34.39

単にマルチスレッドで複数の要素をアニメーションさせたいだけであれば、
アニメーションさせたい要素の数だけタイマーを生成すれば可能かと
（ただし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);

**デフォルトの名無しさん** · 2018/02/07(水) 20:42:03.07

Animationはまた別個にWorklet仕様がある
https://wicg.github.io/animation-worklet/

**デフォルトの名無しさん** · 2018/02/07(水) 20:45:47.82

ついでだから聞くんだけどxhrをworkerで動かしてるサンプルがあったんだけど
あれって普通にxhr使うより早くなんの？

**デフォルトの名無しさん** · 2018/02/08(木) 02:27:56.97

ファイルを取得するとこまでは殆ど関係ないけど
それを使って重い処理をWorkerでするのなら
取得もWorkerでするのが普通でしょ

**デフォルトの名無しさん** · 2018/02/12(月) 00:04:36.56

JavaScriptで大文字と小文字の使い分けをどうしているのかが最大の謎
たとえばJavaなら
Hoge hoge = new Hoge();
ならば、「hoge」はインスタンス、そして「Hoge」はクラス名
だと分かる。

ところが、JSの場合、
var hoge = new Hoge();
のとき「Hoge」はクラスではなくこちらも「オブジェクト」だから、
「hoge」も「オブジェクト」「Hoge」も「オブジェクト」じゃん？
だけど片方は大文字で片方は小文字だから結局「頭が大文字な変数」と
「頭が小文字な変数」の何を見分けていいかわからなくなる。
「hoge」があったときにこれがオブジェクトなのか関数なのか
プロトタイプなのかコンストラクタなのか一体何者なのかさっぱり分からん。

**デフォルトの名無しさん** · 2018/02/12(月) 00:17:33.53

>>826
実体が○○だから、こうするって考え方は初心者だよ
どうしたいのか、どういう意図を込めたいのか、その考えをコードに反映させる。
と言っても意味がわからないだろうな。

古いGoogleのコーディング規約だがその一節にこういうものが有る
http://cou929.nu/data/google_javascript_style_guide/#constant-values

> 一定で不変であることを意図した値には CONSTANT_VALUE_CASE のように定数としての名前をつけます.
> 加えて, すべてを大文字にし単語をアンダースコアで区切るようにすることは
> @const (その値は overwrite できない) という意味にもなります..

これが書かれた当時はconstというものはなく、実体は只の変数にすぎない。
只の変数に「定数である」という意図を込めるために、全部大文字にするわけだ

Hogeも同じ。実体が関数かオブジェクトかってのは関係ない。
例え実体は関数やオブジェクトであっても、それ（Hoge）にクラスだよという
意図を込めるために大文字で始める。
ならばそれを見た人は、Hogeをクラス名だと考えるようにしないといけない
（もちろんコーディング規約次第だが）

Hogeをどのように作り出すかは関係なく、大文字で始まっているのだからそれはクラス
逆に言えば、クラスとして見せたいから大文字で始める。そういう意図を込めるわけだよ。

コードっていうのは自分の考えを反映させて書くもの。
コードがどうなっているかではなく、自分がどうしたいか。
そして読むときは書いた人の意図を読み取れるようなろう。
実体が何かで考えているうちはまだまだ初心者

> 「hoge」があったときにこれがオブジェクトなのか関数なのか
一般的にはhogeが名詞ならオブジェクト。動詞なら関数。

**デフォルトの名無しさん** · 2018/02/12(月) 10:56:03.12

馬鹿は答えるな。node.jsのwsモジュールでws.oncloseに関数を代入するやりかたと
ws.on('close',callback)を使うやりかたのなにが違うのか分かりません。
教えてください。

**デフォルトの名無しさん** · 2018/02/12(月) 11:26:10.44

答えたやつは馬鹿

**デフォルトの名無しさん** · 2018/02/13(火) 10:28:09.45

CSSエンジンをJavaScriptで組んだものってありますか？

**デフォルトの名無しさん** · 2018/02/13(火) 11:04:35.19

CSSエンジンってなんや？
どこからどこまでをさすんや？

**デフォルトの名無しさん** · 2018/02/13(火) 11:27:41.20

HTMLとCSSをレンダリングするようなやつです
floatのアルゴリズムを知りたいのです

**デフォルトの名無しさん** · 2018/02/13(火) 14:03:13.60

じゃPhantomJS

**デフォルトの名無しさん** · 2018/02/13(火) 16:18:30.17

SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？

現状
https://support.google.com/webmasters/answer/181708?hl=ja
に示すみたいにソフト404エラーみたいになってるんですが
SPAでステータスコードを返す方法がよくわからないんです。

**デフォルトの名無しさん** · 2018/02/13(火) 17:42:13.75

https://stackoverflow.com/questions/27525828/angularjs-html5mode-and-hard-404

**デフォルトの名無しさん** · 2018/02/13(火) 19:42:45.41

>>835
つまり404は普通にwebPageとして作ってリダイレクトしろよと。

**デフォルトの名無しさん** · 2018/02/14(水) 15:28:31.17

それは現実的じゃないと思うな
直リンクとSPAでの遷移が違うと不自然だし
SPAでの遷移で存在しない場合リダイレクトするのも不自然だし
今だとServiceWorkerとかもあるし

**デフォルトの名無しさん** · 2018/02/14(水) 17:37:54.60

ソフト404でいいと思うけどな。googleが悪い。

**デフォルトの名無しさん** · 2018/02/14(水) 18:57:53.49

なんでもいい！ユーザーはそんなの気にしてない！

**デフォルトの名無しさん** · 2018/02/14(水) 19:42:05.87

そもそも誰が誰に404を返すようにしたいのか

**デフォルトの名無しさん** · 2018/02/15(木) 00:01:48.36

>>834
一応JavascriptスレだからNode.jsで答えるけど
res.status(404);
res.send('File Not Found');
でいいのでは

**デフォルトの名無しさん** · 2018/02/15(木) 00:56:50.81

SPAとしての決まりはあんまりない感じなんですかね？stackoverflowを見るとgoogleがリダイレクトで404で飛ばすようにサービス作ってるからそれでいいのでは？という話でした。

**デフォルトの名無しさん** · 2018/02/15(木) 02:21:06.62

SPAっていうのもピンきりだから
mobile jQueryを使ったりしてただ単にリクエスト量削減のオマケなら404を返せばいいし、
アプリケーションと呼ぶようなものならそうしなければいい

**デフォルトの名無しさん** · 2018/02/15(木) 06:30:29.99

>>842
Googleの場合色んな検索窓があるページがSPAだけど、
考え方によっちゃヒットの無いキーワードでの検索っていうのは
404に当たるものだけど返してないよね

逆にそういう１つのアプリケーション内で
404にリダイレクトせざるを得ない事なんて考えにくいよね

**デフォルトの名無しさん** · 2018/02/15(木) 06:57:50.10

リダイレクトは300番台だぞ

**デフォルトの名無しさん** · 2018/02/15(木) 07:02:37.33

検索結果が０件であることと、検索結果ページが存在しないことは別物

**デフォルトの名無しさん** · 2018/02/15(木) 08:11:26.78

>>844
> 考え方によっちゃヒットの無いキーワードでの検索っていうのは
> 404に当たるものだけど返してないよね

ないわ～

**デフォルトの名無しさん** · 2018/02/15(木) 08:55:12.72

>>846
何言ってんだ？
商品ページがない場合は404だろ

**デフォルトの名無しさん** · 2018/02/15(木) 10:01:16.08

>>848
言いなおそう

検索結果が0件であることと、検索結果を表示するためのページが存在しないことと、
検索結果を表示するためのページからリンクをたどった先のページが存在しないことは別物

**デフォルトの名無しさん** · 2018/02/15(木) 10:04:09.93

んで、質問内容は、リンクを辿った先のページがない時に
404を返すにはどうするかって話だろ

**デフォルトの名無しさん** · 2018/02/15(木) 10:45:25.62

いつ404を返すべきかはさておき

返し方はとりあえず >>841 に書いた
静的ファイルならApacheやnginxが勝手に返してくれるし
PHPやほかの言語ならそれぞれの言語のスレに行ってくれ

**デフォルトの名無しさん** · 2018/02/15(木) 10:45:55.81

犬がたくさん出てくる映画は？

**デフォルトの名無しさん** · 2018/02/15(木) 12:40:11.35

>>851
> 返し方はとりあえず >>841 に書いた

吹いたｗ SPA、おい、S・P・Aだ
nodeはサーバーサイド側での返し方だろ

お前SPAしらんだろ？ SPAなんだからクライアントJavaScriptの話で
PHPや他の言語は関係ないし、静的ファイルでもない

SPAで構成されたすべてのURLが一つのHTMLが呼び出される状況で
すべてのURLに含まれてしまう存在しないURL　に対して
どうやってクライアントJavaScriptで404を返すのかって話だろうが

ついてこれてないぞｗ

**デフォルトの名無しさん** · 2018/02/15(木) 12:59:26.53

404に独立したページが存在したらそれってSPAじゃなくない？

**デフォルトの名無しさん** · 2018/02/15(木) 13:05:22.69

独立したページ？それは曖昧な言い方だな

SPAっていうのは、一つのページ（HTML+JavaScript）が
複数のURLを持っているものなんだよ。

もちろん一つのURLだけを持つのもありだが、
それだとSEO的にあまり良くないからな

一見複数のページが有るように見えても実際は
一つのページになってるように作るのがSPAだ

**デフォルトの名無しさん** · 2018/02/15(木) 13:10:14.71

> 複数のURLを持っているものなんだよ。

持ってないよ。複数のURLどれでも同じページ返してjsでパスに応じて内容切り替えてるだけだよ。

**デフォルトの名無しさん** · 2018/02/15(木) 13:16:17.44

> 複数のURLどれでも～内容切り替えてるだけだよ。

それ複数のURL持ってますねｗｗｗ

**デフォルトの名無しさん** · 2018/02/15(木) 13:28:35.51

ああそういう意味か

**デフォルトの名無しさん** · 2018/02/15(木) 13:34:00.16

で、話を戻すと

複数のURLどれでも同じページを返す・・・
ということは

複数のURL（存在しないページ含む）のどれでも同じページを返す
から単純にやったら404にはならないということ

URL直接入力だったらサーバーが介在する余地があるからまだどうにかなるが、
存在しないページに対してSPAからアクセスした時に
そのページ（URL）をどうやって404にするのか？という話がでてくる

**デフォルトの名無しさん** · 2018/02/15(木) 15:32:52.51

>>849
別もんじゃないよ
動的なアプリケーションの場合
所在地としてのURLとコンテンツの在り処には最早関係がない

逆に別にx.cgiが存在してもそれに対するクエリがコンテンツ検索のためのものなら
場合に応じてcgiが404を返したって問題ないんだから
Googleの挙動だって最初期の論文や日記くらいしかなかったWebではありえないことなのよ
今や重要なのは定義でなくどう使われてるかの意図

**デフォルトの名無しさん** · 2018/02/15(木) 15:43:52.20

ひとまず
https://stackoverflow.com/questions/37334220/how-do-i-return-a-http-404-status-code-from-a-spa
上記リンクの情報に従うと
404 page にリダイレクトさせることでステータスコードを返すって方法しかない
ということでいいでしょうか？

js側でステータスコードを返したようにブラウザに認識させる方法とか
あるのかなーと期待していたんですが、、、

**デフォルトの名無しさん** · 2018/02/15(木) 15:55:44.81

俺としてはまあ答はでてるんだが
ほかの人、もう少し頑張ってみてくれｗ

**デフォルトの名無しさん** · 2018/02/15(木) 16:33:58.37

どうせSEOのために仕方なくでしょ。
ソフト404でいいと思うんだがSPA推してるくせにgoogleマジなにやってんの。

**デフォルトの名無しさん** · 2018/02/15(木) 17:23:29.73

サーバー側のCGIが404を返すことは何の問題もない
PATH_INFOで動作しているCGIは404や300番台も返すことがある
例えば、 ttps://www.amazon.co.jp/dp/abcdefg
ブラウザ内部では200と404を区別してるだろうけど、見た目には200と404の違いはない

404を返す方法じゃなくて、返ってきた404コードをどのように扱うかは
SPAに限ったことではなく、Ajax全般に言えることだが
フレームワークはフレームワークにその書き方が用意されてなかったらどうにもならんだろ

生のJavascriptの場合

if( xhr.status === 200 ){

}else if( xhr.status === 404 ){
//たとえばalert()して終わり
//responseTextやあらかじめ用意しておいたエラーページを表示してpushState()
//locationでそのURLに移動する
}

自分はlocationで移動する方法はあまりいい方法とは思えんけどな

**デフォルトの名無しさん** · 2018/02/15(木) 18:15:02.91

SPAでも、ルーターで判定するだけじゃないの？
俺はそうしてるけど。
SPAなんだから、誰がどうその404と言う情報が欲しいかというと、多分エンドユーザだよ。
となると、ごく当たり前のように404に相当するコンポーネントを出すしか出来ないだろ。
それが正しく404として扱われてるか、はGoogle Search Consoleで確か確認できる。
むしろ404として扱われていないかを確認するためにも、Search Consoleは見るべきかと。

**デフォルトの名無しさん** · 2018/02/15(木) 19:02:16.42

>>864 に書いた
> //たとえばalert()して終わり
> //responseTextやあらかじめ用意しておいたエラーページを表示してpushState()
> //locationでそのURLに移動する
この部分の書き方にどんな種類があるのかを知りたいのではなく、
サーバーは404を返したけど、クライアント（フレームワーク・ルーター）が反応しないということであれば
フレームワーク・ルーターには
if( xhr.status === 200 ){
}
これしか書かれてないわけだから、
あきらめて200で処理する（いわゆるソフト404）か、フレームワーク・ルーターを作り直せという返事になる

**デフォルトの名無しさん** · 2018/02/15(木) 19:49:37.33

>>864
返ってきたコードをどう扱うかは自由だが
locationで移動しない場合、検索エンジンなどに404を伝えるにはどうするんだよ

**デフォルトの名無しさん** · 2018/02/15(木) 19:53:50.40

>>866
サーバが返すも何も、SPAで、fetchのレスポンスがなんて話なら、そりゃアプリケーション内部の話であってユーザには全く関係が無いかと。
そんな台所事情でエラーメッセージを出すのは404でもなんでもなく、デスクトップアプリで予期できるexceptionを吐いたときにexceptionをそのまま出力しちゃうぐらい悪手では？
かつ、少なくとも、その場合はサーバ側のロジックも結果なしという結果、にすべきなんじゃないかな。
本当にそのリソース(API)がデグレなりクライアントのキャッシュなりでバージョン不一致なりの理由で存在しない場合との切り分けが難しくなる。
RESTのAPIだから、なんて場合は404を返したいのはわかるんだけど、危険な原理主義ではないかなぁ。

**デフォルトの名無しさん** · 2018/02/15(木) 20:57:04.69

>>867
HTTPヘッダの404を見て404で登録される
https://support.google.com/webmasters/answer/35120?hl=ja
URLエラーのタイプ、一般的なURLエラーのソフト404の説明書きを参考

ただ、フレームワークが200しかサポートしていない、にもかかわらず404で処理したい
というのであれば、まあ、locationしかないんじゃないかなと思うんだけど
検索エンジンに、SPAのURLとlocationでジャンプしたURLが同一だということを理解できるのかなぁ

>>868
ブログにニュース記事へのリンクを張った後に、
ニュース記事を削除した場合に404を返すようにしている
Google SEO的には410のほうがいいかもしれないけど

ページを追加、削除し、そこにリンクを張った過去のブログを更新しないことなんかはよくあることだし、制作時に対応できない

検索結果０件（コンテンツのない、またはSEOの重要度が非常に低いURLが存在する）のと、
URLそのものが存在しないのとは区別すべきというのが自分の考え方だから

**デフォルトの名無しさん** · 2018/02/15(木) 21:03:46.64

どんなURLでも同じページをサーバーが返して
そのページがデータをフェッチして表示するようなもので
クローラからのアクセスの時のみ404レスポンスを返すのはありなのか?
Googleは特別扱いするなとか言いつつ、クローラを考慮した仕様も出してるから
どうしたらいいのか難しい

**デフォルトの名無しさん** · 2018/02/15(木) 21:05:43.22

つまり検索エンジンに載せたくないという理由で
実際ページが表示できるかに関わらず404を返していいのかということ
SPA用のスマートな方法は用意されているのだろうか

**デフォルトの名無しさん** · 2018/02/16(金) 09:40:25.43

>>869
自分が言いたいのはURLを動的に解釈している場合は多かれ少なかれ
URLはコンテンツの静的な住所という大原則からは外れてしまっているということ
つまり「URLそのものが存在しない」という判定が自明でなくなる

**デフォルトの名無しさん** · 2018/02/16(金) 10:54:49.83

さて、むそろそろ俺の登場かな？
この問題はねSPAだからといってパフォーマンスさげないよね？
無駄なことはしないよね？という話で解決するんだよ。

例えば、http://example.com/foo/1 とかにアクセスした時、
index.html に30x のリダイレクトしたりはしない
なぜかって？リダイレクトしたらパフォーマンス落ちるでしょ？

つまりね。PATH_INFO（でいいかな？）の情報を持った状態で
サーバーサイドアプリが呼び出されるんだよ
そこでサーバーサイド側の仕組みを使って404を返せばいい

SPAの話なのに何を言ってるのと思うかもしれないけど、
ちゃんとしたSPAっていうのはF5を押しても同じ画面が表示されるし
URLも http://example.com/foo/1 のままになるもの

SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
それは他のページから辿った場合で、直接 http://example.com/foo/1 に
アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
なぜかって？ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
データが見つからない時に404を返すことも容易

そして検索エンジンとかは、基本的にAjaxを使ってデータを読んだりしない。
読むことも有るかもしれないけど、Ajaxリクエスト（Content-Type: application/json）として
そのページを読み込むことはないだろう。だからいま問題にしているどうやって404を返すか？という
話は実は当てはまらない。検索エンジンは http://example.com/foo/1 を直接読み込むのだから

Ajaxによるリクエスト、つまり別ページを読み込んでからSPAの処理としてページを読み込む場合は
そのリクエストを404にすればよい。たしかにページ自体は404にはならないんだけどね。
でも検索エンジンには関係ない話

**デフォルトの名無しさん** · 2018/02/16(金) 11:13:52.52

>>873
今現在はサーバサイドレンダリングは不要で、GoogleBotはちゃんとjsを解釈してくれます。
但しchrome41相当なんでES2015はダメでES5にトランスパイル必須ですが。

**デフォルトの名無しさん** · 2018/02/16(金) 12:12:33.62

> GoogleBotはちゃんとjsを解釈してくれます。

なにを解釈しているかちゃんと分かってますか？

解釈していると主張しているだけで、何をどう解釈しているかは
非公開のはずですが？どうして問題ないと信じられるのでしょうか？

**デフォルトの名無しさん** · 2018/02/16(金) 12:31:37.30

>>875
https://qiita.com/m0a/items/89aec890f98a599846ce
GoogleBotのchrome version調べることができます。
bot用にカスタマイズしている可能性はあるので確かに100%保証というわけではないですが

**デフォルトの名無しさん** · 2018/02/16(金) 12:34:28.83

>>876
それで今はサーバーサイドレンダリングの話なんですか？
404にサーバーサイドレンダリングなんか関係ないでしょ

**デフォルトの名無しさん** · 2018/02/16(金) 12:37:37.23

>>877
>SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
>それは他のページから辿った場合で、直接 http://example.com/foo/1 に
>アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
>なぜかって？ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
>だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
>最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
>データが見つからない時に404を返すことも容易

ここに対するツッコミをしただけですよ。

**デフォルトの名無しさん** · 2018/02/16(金) 12:49:30.63

>>873
それはSSRする場合というごく少数のSPAの場合であって、
大体はpathinfo効かせて、htmlにリダイレクトさせると思うんだが。
悪手よ。二種類のルーターの同時保守は。

hoge/foo/1は、hogeへの/foo/1というルートのパラメータであって、パスじゃない。pathinfoの時もね。
ajaxでURLとしてのfoo/1を取得するかどうかも、SPA次第であって、実はそんなこと関係なくクライアントサイドの処理で済むものなのかもしれない。

なので、404というステータスはhtmlに対してはユーザが見れうるが、各パスに対しては見ようがない。
SPAのAはApplicationのAだからね。