+ 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(金) 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だからね。

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

>>878
突っ込みになってないよ？
パフォーマンスの点から、最初から表示に必要なデータを
HTMLに埋め込むって言ってるんだから

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

pathinfo？
pathnameのこと？

ApplicationのAだから？
railsやexpressやspringでサーバーサイドで作ったものはApplicationではない？？？

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

>>879
> 悪手よ。二種類のルーターの同時保守は。

そんなもんする必要が無いだろ？

http://example.com/foo/1 にアクセスしたら
どうせクライアントサイドから /api/foo/1とか呼び出すんだろ？

ならその呼び出す命令の代わりに、
サーバーサイド側で http://example.com/foo/1 でアクセスした時に
同じ /api/foo/1 を呼び出せばいいだけ

汎用化できるから保守の必要はない

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

/api/foo/1と書いたけど、もちろん /foo/1 でもよい。

その場合、Ajax（Content-Type: application/json）からのリクエストか
どうか判別してそのページのデータのみを返すか、
HTMLを返すか切り分ければいい

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

そもそもGETはキャッシュラブルだとかそういうのも守れてないし

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

また関係ない話が出てきたな・・・

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

>>882
しないこともあるのがSPAだよ。

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

しないならしなければいいだけだろ？
何を言いたいのか分からん

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

>>887
だから、>>882の通りにはいかないでしょ。
リクエストのURIと同じURIのリソースを呼び出すこともあれば呼び出さないこともあるSPAだと。
アプリケーションのなかで一意なURIと、Webサーバとして配信してるURIは混同するほうがおかしい話で。
クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。

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

>>888
> リクエストのURIと同じURIのリソースを呼び出すこともあれば呼び出さないこともあるSPAだと。

それはページ内部の話だろ。クローラーからすりゃ関係ない話

クローラーが記録するのはブラウザのアドレスバーに表示される
あのURLのみと考えればいい。そのURLに対してGETリクエストを行うだけ

そもそもお前、SPAの初期ページの読み込みが遅いって問題と解決方法知ってるか？

https://qiita.com/takeshy/items/b7e1b6bd30d12ecb02c6
> 1.データを別々にAjaxで取得
> 各CollectionやModelがRESTを使ってデータをAjaxで取得するので、
> リクエスト数が多くて遅くなる上に、ブラウザの同じサイトに対しての同時リクエスト数制限にひっかかります。

> 1.に関しては、初期画面のHTMLにAjaxで取得予定のデータを予め埋め込んでしまい、
> 初期データとして使うことで初期画面表示時のAjax呼び出しをなくしました。

https://qiita.com/takeshy/items/ba8b3ee4606993c1c5b8

> 初期表示時にサーバとの通信を極力行わない
> SPAで作成する場合、各モデルごとにサーバとデータを同期する必要がありますが、
> データを初期のHTMLにJSONデータとして埋め込んでしまうことで、Ajax通信を回避することが可能です。

どうせこれやるんだから、この時にデータが見つからなければ404を返すだけの話だろ

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

>>888
> クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
> クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。

クライアントサイドだけが生成されるものというのはURLを持たないってことか？
URLを持たないページならクローラーの対象とならないんだから
そんなのどうでもいいだろ。URLがなｂ｢ならクローラ＝[はこねーよｗ

まさかURLを持たなくてもクロールしてくれるとか思ってねーよな？
クローラーがクリックイベントまでシミュレートして、URLは変わらないのに
ページ辿ってくれるとか思ってねーよな？しねーからなそんなこと

> https://www.bricoleur.co.jp/blog/archives/2628
> 原文：
> We don’t “click” during rendering so any click event will be ignored,
> but we do execute JavaScript that is triggered by for example onLoad events.
> > 原文：
> （Googlebotは）ページをレンダリングする際に何も「クリック」しない。
> 従って、クリックイベント（によって発生する動的なコンテンツ）は無視する。
> しかし、onLoadイベントなどがトリガーとなるようなJavaScriptについては実行する。

クローラーの動きとしては
1. ページを読み込んでレンダリングする
2. そのページのURLをかき集める
3. そのページは一旦閉じSPAが終了されてるのと同じ状態から、かき集めたURLの一つを読み込む

だからな。SPAアプリをクローラーが操作してくれるわけじゃない。
SPAの画面をそのままクロールしてくれるんじゃなくて、その状態からF5（画面更新）を
押して表示されたものしか見てくれないからな。だからURLがあることは必須

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

数年前からクリックするようになってるよ

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

>>891
React-router-dom触ってると
onclickで遷移する仕組みがチュートリアルで紹介されてないんだよね。
(よく探すとあるけど。)

GoogleBotが辿ってくれるためにはAnchorである必要があるってことで
そのためにonClickじゃなくてLinkタグを使って遷移処理するようにするってことだね。
非同期通信を介してレンダリングすると一々Stateに保存してLinkタグを書くのがシンドいと思ってたんだけどSEOのためだったんだなぁ

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

なってるといいよねｗ

どちらにしろURLがないコンテンツは
クロールしてくれないことに変わりないんだがな

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

>>892
リンクタグを使った所で、そのリンクを
アドレスバーに入れて表示されないと意味ないからね

クローラーはリンクのみを取り出してアドレスバーに入れて
表示されたものを、そのURLのコンテンツとして認識する

そこからクリックして変化したものまでクロールしてくれない
（普通に考えれば当たり前だが）

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

クリックじゃなく遅延して表示してるのはどうなるんだろ？何秒か適当にwaitしてから取ってんのかな？それとも

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

>>895
運次第だろ？

1秒毎に変わるページでも作って、それがクロールされるかとか
やってみたら？少なくとも全部クロールされることはないだろうね

クリックされると副作用が現れるということで、
ページ上にクリックできるものが複数あって、
じゃあどれをクリックしたものをクロールされるのか？とかさ
考えてみれば不可能だってわかると思うんだが

クローラーがJavaScriptを実行するというのは
JavaScriptで動的に出したもの全てをクロールして
くれるわけじゃないことはわかるでしょ？

クロールされるのは指定したURLを表示して（JavaScriptで）
レンダリングした最初の画面ぐらいに思っておいたほうが良いよ
そこからのonclickは動かないとみなした方がいい
もちろんレンダリングした結果に含まれるリンクにはURLが書いてあるので
新たなクロール対象になる。
onclickの場合はURLが書いてないのでクロール対象にならない