X



+ JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2015/03/22(日) 16:19:45.75ID:nW67tQ7U
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です)
0851デフォルトの名無しさん2018/02/15(木) 10:45:25.62ID:6MYE6XLg
いつ404を返すべきかはさておき

返し方はとりあえず >>841 に書いた
静的ファイルならApacheやnginxが勝手に返してくれるし
PHPやほかの言語ならそれぞれの言語のスレに行ってくれ
0853デフォルトの名無しさん2018/02/15(木) 12:40:11.35ID:8SUVFt/S
>>851
> 返し方はとりあえず >>841 に書いた

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

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

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

ついてこれてないぞw
0855デフォルトの名無しさん2018/02/15(木) 13:05:22.69ID:8SUVFt/S
独立したページ?それは曖昧な言い方だな

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

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

一見複数のページが有るように見えても実際は
一つのページになってるように作るのがSPAだ
0856デフォルトの名無しさん2018/02/15(木) 13:10:14.71ID:1CgTZOOO
> 複数のURLを持っているものなんだよ。

持ってないよ。複数のURLどれでも同じページ返してjsでパスに応じて内容切り替えてるだけだよ。
0857デフォルトの名無しさん2018/02/15(木) 13:16:17.44ID:8SUVFt/S
> 複数のURLどれでも〜内容切り替えてるだけだよ。

それ複数のURL持ってますねwww
0859デフォルトの名無しさん2018/02/15(木) 13:34:00.16ID:8SUVFt/S
で、話を戻すと

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

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

URL直接入力だったらサーバーが介在する余地があるからまだどうにかなるが、
存在しないページに対してSPAからアクセスした時に
そのページ(URL)をどうやって404にするのか?という話がでてくる
0860デフォルトの名無しさん2018/02/15(木) 15:32:52.51ID:9pb3TF19
>>849
別もんじゃないよ
動的なアプリケーションの場合
所在地としてのURLとコンテンツの在り処には最早関係がない

逆に別にx.cgiが存在してもそれに対するクエリがコンテンツ検索のためのものなら
場合に応じてcgiが404を返したって問題ないんだから
Googleの挙動だって最初期の論文や日記くらいしかなかったWebではありえないことなのよ
今や重要なのは定義でなくどう使われてるかの意図
0861デフォルトの名無しさん2018/02/15(木) 15:43:52.20ID:xvxGqpCI
ひとまず
https://stackoverflow.com/questions/37334220/how-do-i-return-a-http-404-status-code-from-a-spa
上記リンクの情報に従うと
404 page にリダイレクトさせることでステータスコードを返すって方法しかない
ということでいいでしょうか?

js側でステータスコードを返したようにブラウザに認識させる方法とか
あるのかなーと期待していたんですが、、、
0862デフォルトの名無しさん2018/02/15(木) 15:55:44.81ID:8SUVFt/S
俺としてはまあ答はでてるんだが
ほかの人、もう少し頑張ってみてくれw
0863デフォルトの名無しさん2018/02/15(木) 16:33:58.37ID:ilr6oKXN
どうせSEOのために仕方なくでしょ。
ソフト404でいいと思うんだがSPA推してるくせにgoogleマジなにやってんの。
0864デフォルトの名無しさん2018/02/15(木) 17:23:29.73ID:6MYE6XLg
サーバー側の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で移動する方法はあまりいい方法とは思えんけどな
0865デフォルトの名無しさん2018/02/15(木) 18:15:02.91ID:aKcpIhES
SPAでも、ルーターで判定するだけじゃないの?
俺はそうしてるけど。
SPAなんだから、誰がどうその404と言う情報が欲しいかというと、多分エンドユーザだよ。
となると、ごく当たり前のように404に相当するコンポーネントを出すしか出来ないだろ。
それが正しく404として扱われてるか、はGoogle Search Consoleで確か確認できる。
むしろ404として扱われていないかを確認するためにも、Search Consoleは見るべきかと。
0866デフォルトの名無しさん2018/02/15(木) 19:02:16.42ID:6MYE6XLg
>>864 に書いた
> //たとえばalert()して終わり
> //responseTextやあらかじめ用意しておいたエラーページを表示してpushState()
> //locationでそのURLに移動する
この部分の書き方にどんな種類があるのかを知りたいのではなく、
サーバーは404を返したけど、クライアント(フレームワーク・ルーター)が反応しないということであれば
フレームワーク・ルーターには
if( xhr.status === 200 ){
}
これしか書かれてないわけだから、
あきらめて200で処理する(いわゆるソフト404)か、フレームワーク・ルーターを作り直せという返事になる
0867デフォルトの名無しさん2018/02/15(木) 19:49:37.33ID:lFngoqEs
>>864
返ってきたコードをどう扱うかは自由だが
locationで移動しない場合、検索エンジンなどに404を伝えるにはどうするんだよ
0868デフォルトの名無しさん2018/02/15(木) 19:53:50.40ID:aKcpIhES
>>866
サーバが返すも何も、SPAで、fetchのレスポンスがなんて話なら、そりゃアプリケーション内部の話であってユーザには全く関係が無いかと。
そんな台所事情でエラーメッセージを出すのは404でもなんでもなく、デスクトップアプリで予期できるexceptionを吐いたときにexceptionをそのまま出力しちゃうぐらい悪手では?
かつ、少なくとも、その場合はサーバ側のロジックも結果なしという結果、にすべきなんじゃないかな。
本当にそのリソース(API)がデグレなりクライアントのキャッシュなりでバージョン不一致なりの理由で存在しない場合との切り分けが難しくなる。
RESTのAPIだから、なんて場合は404を返したいのはわかるんだけど、危険な原理主義ではないかなぁ。
0869デフォルトの名無しさん2018/02/15(木) 20:57:04.69ID:6MYE6XLg
>>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のほうがいいかもしれないけど

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

検索結果0件(コンテンツのない、またはSEOの重要度が非常に低いURLが存在する)のと、
URLそのものが存在しないのとは区別すべきというのが自分の考え方だから
0870デフォルトの名無しさん2018/02/15(木) 21:03:46.64ID:fKqsgF6j
どんなURLでも同じページをサーバーが返して
そのページがデータをフェッチして表示するようなもので
クローラからのアクセスの時のみ404レスポンスを返すのはありなのか?
Googleは特別扱いするなとか言いつつ、クローラを考慮した仕様も出してるから
どうしたらいいのか難しい
0871デフォルトの名無しさん2018/02/15(木) 21:05:43.22ID:fKqsgF6j
つまり検索エンジンに載せたくないという理由で
実際ページが表示できるかに関わらず404を返していいのかということ
SPA用のスマートな方法は用意されているのだろうか
0872デフォルトの名無しさん2018/02/16(金) 09:40:25.43ID:kN3UBOMP
>>869
自分が言いたいのはURLを動的に解釈している場合は多かれ少なかれ
URLはコンテンツの静的な住所という大原則からは外れてしまっているということ
つまり「URLそのものが存在しない」という判定が自明でなくなる
0873デフォルトの名無しさん2018/02/16(金) 10:54:49.83ID:ijGXrmYh
さて、むそろそろ俺の登場かな?
この問題はね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にはならないんだけどね。
でも検索エンジンには関係ない話
0874デフォルトの名無しさん2018/02/16(金) 11:13:52.52ID:PV55M7JN
>>873
今現在はサーバサイドレンダリングは不要で、GoogleBotはちゃんとjsを解釈してくれます。
但しchrome41相当なんでES2015はダメでES5にトランスパイル必須ですが。
0875デフォルトの名無しさん2018/02/16(金) 12:12:33.62ID:ijGXrmYh
> GoogleBotはちゃんとjsを解釈してくれます。

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

解釈していると主張しているだけで、何をどう解釈しているかは
非公開のはずですが? どうして問題ないと信じられるのでしょうか?
0877デフォルトの名無しさん2018/02/16(金) 12:34:28.83ID:ijGXrmYh
>>876
それで今はサーバーサイドレンダリングの話なんですか?
404にサーバーサイドレンダリングなんか関係ないでしょ
0878デフォルトの名無しさん2018/02/16(金) 12:37:37.23ID:PV55M7JN
>>877
>SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
>それは他のページから辿った場合で、直接 http://example.com/foo/1
>アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
>なぜかって? ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ?
>だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
>最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
>データが見つからない時に404を返すことも容易

ここに対するツッコミをしただけですよ。
0879デフォルトの名無しさん2018/02/16(金) 12:49:30.63ID:L6Zw5BDk
>>873
それはSSRする場合というごく少数のSPAの場合であって、
大体はpathinfo効かせて、htmlにリダイレクトさせると思うんだが。
悪手よ。二種類のルーターの同時保守は。

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

なので、404というステータスはhtmlに対してはユーザが見れうるが、各パスに対しては見ようがない。
SPAのAはApplicationのAだからね。
0880デフォルトの名無しさん2018/02/16(金) 12:54:41.12ID:ijGXrmYh
>>878
突っ込みになってないよ?
パフォーマンスの点から、最初から表示に必要なデータを
HTMLに埋め込むって言ってるんだから
0881デフォルトの名無しさん2018/02/16(金) 12:57:19.71ID:6wcMGkCt
pathinfo?
pathnameのこと?

ApplicationのAだから?
railsやexpressやspringでサーバーサイドで作ったものはApplicationではない???
0882デフォルトの名無しさん2018/02/16(金) 13:01:32.14ID:ijGXrmYh
>>879
> 悪手よ。二種類のルーターの同時保守は。

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

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

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

汎用化できるから保守の必要はない
0883デフォルトの名無しさん2018/02/16(金) 13:04:20.87ID:ijGXrmYh
/api/foo/1と書いたけど、もちろん /foo/1 でもよい。

その場合、Ajax(Content-Type: application/json)からのリクエストか
どうか判別してそのページのデータのみを返すか、
HTMLを返すか切り分ければいい
0887デフォルトの名無しさん2018/02/16(金) 16:23:26.06ID:ijGXrmYh
しないならしなければいいだけだろ?
何を言いたいのか分からん
0888デフォルトの名無しさん2018/02/16(金) 17:56:44.52ID:L6Zw5BDk
>>887
だから、>>882の通りにはいかないでしょ。
リクエストのURIと同じURIのリソースを呼び出すこともあれば呼び出さないこともあるSPAだと。
アプリケーションのなかで一意なURIと、Webサーバとして配信してるURIは混同するほうがおかしい話で。
クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。
0889デフォルトの名無しさん2018/02/16(金) 18:24:29.38ID:ijGXrmYh
>>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を返すだけの話だろ
0890デフォルトの名無しさん2018/02/16(金) 18:31:57.24ID:ijGXrmYh
>>888
> クライアントサイドだけが生成するものの404は、クライアントサイドだけでさばくべきかと。
> クライアントサイドだけが生成するものってのは、サーバに持ち込まない事がセキュリティ上の担保になるようなブラウザで生成するものになるだろうけど。

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

まさか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があることは必須
0892デフォルトの名無しさん2018/02/16(金) 19:30:14.75ID:PV55M7JN
>>891
React-router-dom触ってると
onclickで遷移する仕組みがチュートリアルで紹介されてないんだよね。
(よく探すとあるけど。)

GoogleBotが辿ってくれるためにはAnchorである必要があるってことで
そのためにonClickじゃなくてLinkタグを使って遷移処理するようにするってことだね。
非同期通信を介してレンダリングすると一々Stateに保存してLinkタグを書くのがシンドいと思ってたんだけどSEOのためだったんだなぁ
0893デフォルトの名無しさん2018/02/16(金) 19:33:28.56ID:ijGXrmYh
なってるといいよねw

どちらにしろURLがないコンテンツは
クロールしてくれないことに変わりないんだがな
0894デフォルトの名無しさん2018/02/16(金) 19:36:08.89ID:ijGXrmYh
>>892
リンクタグを使った所で、そのリンクを
アドレスバーに入れて表示されないと意味ないからね

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

そこからクリックして変化したものまでクロールしてくれない
(普通に考えれば当たり前だが)
0895デフォルトの名無しさん2018/02/16(金) 19:45:34.13ID:uCgPr+rC
クリックじゃなく遅延して表示してるのはどうなるんだろ?何秒か適当にwaitしてから取ってんのかな?それとも
0896デフォルトの名無しさん2018/02/16(金) 19:54:10.08ID:ijGXrmYh
>>895
運次第だろ?

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

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

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

クロールされるのは指定したURLを表示して(JavaScriptで)
レンダリングした最初の画面ぐらいに思っておいたほうが良いよ
そこからのonclickは動かないとみなした方がいい
もちろんレンダリングした結果に含まれるリンクにはURLが書いてあるので
新たなクロール対象になる。
onclickの場合はURLが書いてないのでクロール対象にならない
0899デフォルトの名無しさん2018/02/16(金) 23:25:00.48ID:wAiK151t
とりあえず、404って書いた画面表示しときゃいいだろ。
それで不満だって言うのなら何が気に入らないのかちゃんと挙げて議論。
0900デフォルトの名無しさん2018/02/16(金) 23:57:21.24ID:ijGXrmYh
>>898
あるURLに対してクローラーがアクセスしてくる場合には
サーバーサイド側で404を表示できる。

なぜならサーバーサイド側でそのリクエストを処理するから
その時にデータがなければ404を返せる

Ajaxを使ってアクセスする場合は、そのリクエストで404を返せばいい
0901デフォルトの名無しさん2018/02/17(土) 00:03:35.35ID:NuxITAVF
何を怒り狂ってるかわからんが、クローラがちゃんとクロールしてるかどうかの調べ方は書いただろう。

>>889
ページ内部の話だから、むしろ関係ないんだよ。
SPAなんだから。
ウェブページ豪華版みたいな扱いされても困るわ。
SPAが重いって問題とは別問題。

>>890
URLじゃなくてURIとしては持つだろうね。
持つって言ってるでしょ。
それはユーザにとっての識別子であって、クローラに対してどうするかは、クローラがクライアントとなってどうするかによる。
その調べ方は書いた。

なんか大きめの勘違いしてない?
SPAはwebページとは限らないよ。
0902デフォルトの名無しさん2018/02/17(土) 00:06:15.35ID:NuxITAVF
ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。
そのURIの情報をDOMごと貰えばいい話になる。
どこのClassicASPのUpdatePanelの話なのかわからんレベルで無能じゃん。
アプリケーションだよ。
0903デフォルトの名無しさん2018/02/17(土) 00:49:10.87ID:RdZUuX+v
> ajaxを使って、同じURIから同じリソースを使うなら、クライアントで描画する必要無いよね。

あ、なるほどwwwww

そううかお前、サーバーサイドでレンダリングするって思っちゃってるんだwwww
SPA初心者だな。

クライアントでレンダリングするのに必要なデータをJSONでHTMLで埋め込むんだよ
そしてクライアントサイドでレンダリングするんだよ。
>>889のリンク先にもそう書いてあんだろ

で、クライアントでレンダリングするためのデータがなかったら、
404を返すだけの話だよ。
0904デフォルトの名無しさん2018/02/17(土) 00:49:44.01ID:RdZUuX+v
>>901
> SPAはwebページとは限らないよ。

え?なに? お前のSPAはF5押したら
初期画面に戻っちゃうの?
使いづれぇなぁw
0905デフォルトの名無しさん2018/02/17(土) 02:40:20.72ID:+Fv80jjb
F5押しても戻らないよ。
ルーターが処理してるから。

お前アホなんだろ。
0906デフォルトの名無しさん2018/02/17(土) 02:48:01.65ID:+Fv80jjb
そもそも、pathinfo使ってリダイレクトさせるのは別に動的なphpやサーブレットなんかだけが対象じゃなくて、htmlでも良いんだよ。
そのhtmlはサーバから取らなくてもサービスワーカーなりなんなりでブラウザ内で処理しちゃえるから、トラフィックは発生しない。
ブラウザ内でindexedDBなり使って復帰すればそれでいいんだから、同じURIにリクエスト投げる必要もなく、ブラウザ外に問い合わせて表示データを取る必要もない。

アプリケーションなの。APIが返す値を表示するだけのブラウザじゃないのよ。SPAと言うのは。
0908デフォルトの名無しさん2018/02/17(土) 11:50:05.04ID:+Fv80jjb
>>907
URIはあるけど、それがサーバのURLと一致してるわけじゃないよ。
理解してなくない?
0909デフォルトの名無しさん2018/02/17(土) 12:10:00.79ID:W+GNXAq+
F5で完全に戻らないとしてもURLだけで
そのアプリケーションの全ての値が復元できるとも限らない
0910デフォルトの名無しさん2018/02/17(土) 13:29:52.85ID:+Fv80jjb
それはURIだけで、サーバがすべての値を返すとは限らない、と同じ意味だよね。
0911デフォルトの名無しさん2018/02/17(土) 13:39:20.93ID:Q9uAGfUQ
クローラーはURIだけでアクセスしてくるので
URIから読み取れないデータはクロールされません。

またGoogleの検索結果にSPAのJSONが
クロールされた形跡は見られませんね。
もしそのJSONがクロールされていれば
検索結果に出るはずですから
0912デフォルトの名無しさん2018/02/17(土) 14:18:23.54ID:W+GNXAq+
その理屈は正しくない
もしJSONも認識できて人並みの知能があった場合
それを検索結果に出さないという判断をすべきだから
0914デフォルトの名無しさん2018/02/17(土) 14:54:23.92ID:QcCOFhat
SPAのJSONという時点でダム端みたいな使い方しかして無いとわかってしまう悲しさがあるな。
ブラウザは単なるレイアウトエンジンじゃないぞw

うちのログにはSPAだけがルーティングしてるアドレスに向かってのクエリはあるから、逆にajaxしてるからクローラにそこで諦められてんじゃないの?
0915デフォルトの名無しさん2018/02/17(土) 17:47:46.20ID:QcCOFhat
よくよくこいつがなんで馬鹿な事言ってるか考えてみたんだが、URIだけでアクセスしてくるが、その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリングできてしまうがある事を想定してないんだろうな。
URIで指定されたコードをバーコードとして画面に表示するとか色々作ったが、そう言うのは多分想定外なのかなと思ったわ。

HTTPとしてGETするリソースと、ブラウザにあるコンテンツを求めるために示されるURIはイコールじゃない。
だからHTTPサーバはindex.html/jsに相当する内容をいつでも同じように返すし、サービスワーカーが動いてればそのサーバへの問い合わせすらしない。
いつでも、そのhtmlやjsが、自身に与えられたURIから、コンテンツを作る。
0917デフォルトの名無しさん2018/02/17(土) 18:27:57.81ID:nikLB5DZ
>>915
いや、そうじゃなくて
「その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリング」
という処理をするためには、

1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする

の3〜4のサーバーへのリクエストの処理について考察できてないんでしょ?

そしてSPAでは2回サーバーにリクエストを投げるのが当たり前で解決できない問題だと思い込んじゃってる。
まともなSPAだとここを1回にする。理由は2回リクエストを投げるとパフォーマンスが落ちるから。

2回サーバーにリクエストを投げる方法だと2の時点で200が返ってきてしまい、4の時点で404を返すことになるが、
リクエストを1回にした場合は、2の段階でindex.html/js相当+画面と内容を表示するためのデータを貰うことになるので
この時点で404を返すことができる。
0918デフォルトの名無しさん2018/02/17(土) 20:48:04.60ID:QcCOFhat
>>917
違うよ。3は、必ずしも存在しないって言ってるの。
SPAでは2回リクエストを送ることもあるだろうし、リクエストを送らない事もあるって言ってるの。
まともなアプリケーションでは、一回も送らなくて済むならば送らない。
htmlやjsをサービスワーカーでキャッシュしてれば、そもそももっと話が変わってくる。
(特定のURI以下へのリクエストをサービスワーカーでキャッシュから解決するだけ)
さらに、URIの中身で画面が作れる場合、アプリケーションから見てそれは本当に唯一無二のURIだよ。Locatorではなく、Identifier。

お前は、最低一回リクエストするはずだ、という思い込みというか、それ以外の方法を知らないんだと思うよ。
要はウェブページプラスαの考え方。
0919デフォルトの名無しさん2018/02/18(日) 02:19:09.25ID:dp9S/ZRw
>>918
今、話をしてるのはクローラーの話だって分かってない?

クローラーはクッキーやローカルストレージは使わない
https://www.suzukikenichi.com/blog/googlebot-uses-a-web-rendering-service-that-is-based-on-chrome-41/
ページレンダリング中に一時的に使ってるかもしれないが読み込み時に毎回クリアされる

クローラーっていうのは、HTMLを取得(ページをレンダリング)する処理と、URLをかき集める処理が別れている
そしてクローラーは自分が知ってるURLに対してGETリクエストを送る
だから一回もリクエストを送らないということはありえないんだよ。

クローラーはブラウザじゃない。ブラウザのように前の状態というのを持たない。
だからアプリの作りが例えサーバーと通信しない作りであっても
知ってるURLに対して初回アクセスと同じようにかならずGETリクエストを送ってくる
そしてクッキーやローカルストレージは持たない

クローラーは必ずSPAのアプリケーションの特定のURLに対して直接GETでアクセスしてきており
(アクセスしない = 最新の情報がわからないのだからクロールされてるページ内容の更新を行わない)
なおかつ初回アクセスと同じようにデータは空なのだから、状態は200か404のどちらかに決定することが可能
(まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる)

クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ? それなにもクロールしてないからw クローラーの使命を果たしていない
0920デフォルトの名無しさん2018/02/18(日) 11:26:35.43ID:S5M53+XI
それって今のGoogle Botの話でしょ?
クローラが一般的にそうである必要はないよ
Google Botも重要なサイトでは高機能長時間のクロールをしてるって噂もあるし
0922デフォルトの名無しさん2018/02/18(日) 11:53:05.84ID:AYB00j0e
クソみたいな長文で自分の理解が及んでませんでしたって言い訳されても困るわ。
それも織り込んで話してる。
0923デフォルトの名無しさん2018/02/18(日) 13:52:18.73ID:dp9S/ZRw
>>920
長時間クロールっていうのはたくさんのページを
まとめてクロールしてるってだけ。動きは変わらない。

> クローラが一般的にそうである必要はないよ
個人的にしか使わないクローラーは別として
一般的なクローラーは、不特定の人が見るわけだから
このような動きになる。
0925デフォルトの名無しさん2018/02/18(日) 13:55:42.29ID:AYB00j0e
要はURIだけで画面が作れる画面ってのはあるんだよ。
URIがデータの時な。
クライアントサイドだけで(JSで処理される)リンクをたどる、のはやってくれてるよ。
リファラ見るとわかる。
そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。

ajax!json!ブラウザに上のURLと同じURLでAPIがjsonを返すんだ!と狂って叫ぶ前に、ちゃんと理解すれば良いのに。
ブラウザ上のURLと同じURLで実はJSONを返してる、とか、逆にクローラは無視しにかかるだろ。
クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
SPAなんにもわかってねえな。
0926デフォルトの名無しさん2018/02/18(日) 13:59:45.98ID:dp9S/ZRw
>>921
SEOの話とは違うね。
ページが見つからない時、どうやって404を返すべきかどうかの話

SPAがどうたらとか、サーバーにアクセスしないときがどうとか
言っているが、それらは全く関係ないってことを言ってる。

普通にサーバーにアクセスされた時にデータがなければ404を返せばいい
どんなページもURIを持っていればサーバーにアクセスされうる
(その典型的な例がクローラーってだけの話)

サーバーにアクセスしないときは〜なんて考える必要はない。
そもそもアクセスされないなら何も出しようがないだろ?
0927デフォルトの名無しさん2018/02/18(日) 14:07:51.73ID:dp9S/ZRw
>>925
> 要はURIだけで画面が作れる画面ってのはあるんだよ。
> URIがデータの時な。

URIがデータだったとしても、(そもそも全てのURIがそうなんだがw)
話は関係ない。

URIを持っていればサーバーにアクセスされうる
SPAの場合にサーバーにアクセスしない場合もあるってだけで

ブラウザでF5を押したりクローラーからアクセスされる。
だから必ずしも作る必要はないが、ちゃんと作るならば
サーバー側の処理は必要。その時にデータがなければ404を返せばいい
(URIの情報しか使わないというのならそれは200だろうけどな)


> クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
> SPAなんにもわかってねえな。

そもそもレンダリングする前に、クローラーはSPAであることもわすれて
URIに対してサーバーにアクセスする。ここでSPAのことを考えること自体が意味ないんだよ

ちゃんと作るならば、サーバーにアクセスされた時に必要なデータがなければ404を返せばいいだけ
データの有無の話でAjaxによるアクセスかどうかとかの違いも考える必要はない。
どんな内容を返すか?のために考えるのであって、データがないときは404
0928デフォルトの名無しさん2018/02/18(日) 14:17:14.66ID:AYB00j0e
>>927
だから、サーバにアクセスされても、indexと同じものを返すよ。サーバからのリソースは。
F5を押されたって同じだ。

そのURIにデータがあるか無いかは、クライアント次第なんだから、サーバが返すのは不可能。
もちろんデータのうち、ユーザが作るようなもの、クローラがそもそも「生成しようがない」ものは拾えなくて当然というか、
クローラには一生生成できないURIで表現されるので、検索結果には上がらんし、そういうデータの一覧画面は空として上がるだろう。上がらないようにしたけど。

ただ、アプリケーションだけがハンドリングする静的なコンテンツ、はクローラが拾う。
それはサーバリソースと全く関係なく、jsにバンドルした内容から描画してる画面なんかも含まれるわな。
OSSのライセンス一覧とロゴのaboutなんかとか、特定のコンポーネントだったり、色々あるだろうが。

お前が言ってるSPAはアプリケーションと言うより、ブラウザのレンダリング力を借りたダム端なんだろう。
ダム端知らないなら早めに言ってね。言い換えるから。
0929デフォルトの名無しさん2018/02/18(日) 14:20:48.05ID:F2O3xW/S
>>925
> そのサーバではindex.htmlと同じ内容を返してる、JSでレンダリングされた内容しか含まないURLもちゃんと検索結果に上がってくるんだよなぁ。

そういう話はしてないんだなぁw

SPAでページがない時に404を返したい。どうすればいいか。という話

答は、今までと何も変わらない。
サーバーにアクセスした時にページを表示するために
必要なデータがなければ404を返せばいい


反論としてSPAだとサーバーにアクセスされない場合が〜とかいうから
どのページでもURIを持っていれば、サーバーにアクセスされる可能性があります。
特にクローラーは必ずサーバーにアクセスしてきます。
その時に404を返せば良いのです。という話
0930デフォルトの名無しさん2018/02/18(日) 14:25:32.86ID:F2O3xW/S
>>928
お前、前提がおかしいぞ?

今は、サーバーにデータが無い場合に404を返すにはどうするかの話だ
そもそもHTTPステータスはサーバーが返すもの。サーバーでしか判断できない

ダム端も全く関係ない話。クライアントの端末がなにであるかとか
クライアントがブラウザとかクローラーとか、SPAか否かとか
そういったクライアントは完全に無視できる話なんだよ。

お前が言いたいのはクライアントが○○の場合には〜と
全部クライアントの話ししかしてね〜じゃんか
クライアントは関係ないんだよ。忘れていい。
0931デフォルトの名無しさん2018/02/18(日) 14:30:39.49ID:F2O3xW/S
クライアントが関係ないっていうのはクローラーの例を使っても説明できる。

つまり、あなたのクライアントと、私(クローラー)のクライアントはデータを共有していません。

あなたのクライアントでは何かデータが表示されるんでしょうが、
私(クローラー)のクライアントはあなたのデータなんか知りません。

あなたのクライアントでSPAが動いていようが
私(クローラー)のクライアントでは動いていません
ってことなんだよ
0932デフォルトの名無しさん2018/02/18(日) 14:42:23.81ID:F2O3xW/S
クローラーが高度なレンダリング機能を備えているから
JavaScriptが動くっていうのも、クライアントの話なんで関係ない
単にレンダリングするってだけ


ここでSPAが〜とか言ってくるやつは、
レンダリングされる=SPAとしてクローラーが動くって
考えちゃってるんだろうなって思う。

もう少し具体的にいうと

クローラーが、Aというページを読み込んで表示されたBというリンクをクリックして
(History APIでURIが変わった時に)A+Bとなった情報を保存する
と思い込んじゃってるんでしょう?

そういうクローラーを作ることは可能だが、そんなことはしない。
なぜなら、Bというリンクをクリックした時にサーバーにアクセスしないかもしれないから
それを許すとクローラーのマシンの中だけで無限にアドレスが作れる。
しかもそのアドレスは他人がアクセスできるとは限らない。
クローラーというクライアントが生成したクローラー専用のURIになる。

実際の動きはこう
クローラーが、Aというページを読み込んで表示されたBというリンクを巡回するURIとして記録する
別のタイミングでHistoryAPIなんか使わずにBというURIでサーバーにアクセスして表示されたものを保存する

で、ここで重要なのは クローラーの "例から" 分かる通り URIを持つならばサーバーにアクセスする可能性がある
サーバーにアクセスされた時に404を返せば良いんだよっていう話をしている。
0933デフォルトの名無しさん2018/02/18(日) 14:42:58.66ID:AYB00j0e
>>929
だから、結論を言うと、SPAで404にあたる場合に、表示するかなんてサーバが関与する事ではない。
ルータの二重管理にもなる。

だから、SPAでソフト404を出すしかない。

って言ってるんだが。
0934デフォルトの名無しさん2018/02/18(日) 14:44:45.48ID:AYB00j0e
>>931
>>932
その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。
お前は2010年あたりから進化してないのかよ。

あと、クローラのクライアントでもレンダリングされてるよ。
確認してこいよw
0936デフォルトの名無しさん2018/02/18(日) 14:48:58.99ID:F2O3xW/S
>>933
だからSPAなんて忘れろってw

SPAを使おうが使うまいが、サーバーにアクセスされる時に
データがなければ、サーバーが404を返せばいいだけだって言ってる。

URIを直接ブラウザで開くならば、そのタイミングで404を返せばいいし、
History APIでURIを変えただけならば、その時にAjaxでリクエストあればそのタイミングで404を返せばいい
(その時にAjaxでリクエストがなければそもそも404を変えしようがない)

404をどう返すかの話をしていて、404をどう表示するかの話はしてないんだよ。
0937デフォルトの名無しさん2018/02/18(日) 14:49:05.24ID:AYB00j0e
サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。
だから頭おかしい発想になってるんだと思うが。
404である、とか、一旦Webページの発想から離れられないもんか、
Dreamweaverでシコシコ画面作ってる「ウェブ屋」でもあるまいし。
0938デフォルトの名無しさん2018/02/18(日) 14:51:07.76ID:F2O3xW/S
>>934
> その「単にレンダリングするだけ」がダム端そのものだと言っとるんだよ。

https://www.nttpc.co.jp/yougo/%E3%83%80%E3%83%A0%E7%AB%AF%E6%9C%AB.html

> つまりダム端末は、自分で計算したりデータを保存したり出来ない“頭の悪い端末”という意味で、
>英語では dumb-terminal(ダム・ターミナル)という。それを日本語化して
>「ダム端末」、略して「ダム端」と呼ぶことも多い。

レンダリングする頭があればダム端にはならんが?w
0939デフォルトの名無しさん2018/02/18(日) 14:53:33.03ID:AYB00j0e
>>936
なんで忘れなければいけないんだ…?
>>834
が発端だろ。

URLをブラウザで叩いて、404であるかどうかって時点で違うよね。
ajaxがどうのと言ってるけど、ajaxなんか発生しない、単なる画面切り替えのhistoryAPI操作もあるよね。
それは、もとの画面が切り替わった状態、として扱われるべきだよね。リロードの時。
でも、使うのはSSR無しだと同じコンテンツだよね。だからpathinfo使うんだよね。
頭おかしくなってるのはこのへん。

で、画面切り替えではなく、手入力で変なアドレス入れられると、
「切り替えるはずの画面が無かった」なんて判断は、JS側にしか出来ないよね、って言ってる。
0940デフォルトの名無しさん2018/02/18(日) 14:54:06.49ID:AYB00j0e
>>938
ダム端もレンダリングしてくれるよ。
エスケープシーケンスで。
お前色々知らなすぎるだろ。
0941デフォルトの名無しさん2018/02/18(日) 14:56:10.32ID:F2O3xW/S
>>937
> サーバは、API以外同じコンテンツをどのURLでも吐くもんだろ。SSR無しのSPAなら。

コンテンツとHTTPステータスは別。

同じコンテンツを返しても、HTTPステータスは違っても良い。
極端な話、404を返しながら、コンテンツを返すことだってある

それからSPA(それはクライアントの話)によってサーバーが挙動を変えるわけじゃない。
サーバーにとってクライアントがなにでどうやって動いているかは関係ない

(サーバー側が手抜きだから)HTTPステータスが全部200を返してしまう。
ページがなくても200を返してしまう。って話だから
それならサーバー側をちゃんと作りましょうで終わる話
0942デフォルトの名無しさん2018/02/18(日) 14:56:39.90ID:F2O3xW/S
>>940
コンテキスト理解してないのか?
このスレで言うレンダリングとは、HTMLのレンダリングだよ
馬鹿かw
0943デフォルトの名無しさん2018/02/18(日) 14:57:37.94ID:AYB00j0e
SPAはアプリケーションであって、Webページの軽量版でもおしゃれ版でもリロードなし版でも無い。
一つの画面に1リクエストでもない。
アプリケーションなんだから。
こいつの頭の中でポップアップする子画面とかどう処理されてるのか謎過ぎる。
0944デフォルトの名無しさん2018/02/18(日) 14:58:27.50ID:AYB00j0e
>>941
違うよね。手抜きだからではなく、知り得ない情報だから、200何だよ。
お前バカなの?
0945デフォルトの名無しさん2018/02/18(日) 14:59:24.98ID:AYB00j0e
>>942
うん?
ただレンダリングするだけなら、ダム端と同じ、は

ただHTMLをレンダリングするだけなら、ただエスケープシーケンスをレンダリングするダム端と同じだ、と言ってるんだが。

コンテキスト読めてる?
0946デフォルトの名無しさん2018/02/18(日) 15:05:53.24ID:F2O3xW/S
>>939

> >>936
> なんで忘れなければいけないんだ…?
> >>834
> が発端だろ。

だから、SPAがどうのこうのって考えてる事自体が間違いなんだよ
>>834のリンク先のソフト404エラーの内容見てみ?
SPAの話であるとか全く関係ない

リンク先引用しようか?
> ソフト 404 エラーとは、サイトの URL にアクセスしたときに、
> ページが存在しないことを示すページと 200 レベル(成功)のコードがブラウザに返されることです

「サイトの URL にアクセスしたときに」って書いてあるだろ。
SPAでもなんでも構わないが、サイトのURLにアクセスしない時には全く関係ない話。

(SPAで)サイトのURLにHistory APIで変更すると、サーバーにアクセスしなくても画面に表示できる〜とか
いいだすから、おいおいってなる。前提が違うだろ。サーバーにアクセスしない時は考える必要がない。
サイトの URL にアクセスしたときの話なんだから

ただのa要素のリンクだろうがHistory APIで変更しようが関係ない。どちらも同じURLだ。
そのURLに対して「サイトのURLにアクセスした時に」404を返すのがソフト404対策なんだよ。

で、発端の>>834へのレスだ
> SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか?

「サイトの URL にアクセスされたときに」データがなければ404を返せばいい
SPAとか考える必要はない。
0948デフォルトの名無しさん2018/02/18(日) 15:08:12.87ID:AYB00j0e
>>946
だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。
お前が最初の時点から読み間違えてるの。
バカなの。
いいかげん認めて。めんどくさくなってきた。
技術者なら知らないことを知りませんでしたと言うのは大切だよ。
0949デフォルトの名無しさん2018/02/18(日) 15:09:00.51ID:AYB00j0e
>>947
ウキウキとダム端について間違った事語って、知らない事が出てきたらこうなる。
楽な生き方だな。
0951デフォルトの名無しさん2018/02/18(日) 15:10:43.79ID:F2O3xW/S
>>948
> だから、データが無いか知ってるのはアプリケーションになってしまうのが、SPAだから、問題になってるんだよ。

404ってサーバーが返すものだぞ?
サーバーがデータがないとクライアントに返すものなのに、
データが無いか知ってるのがアプリケーション?
サーバーと関係ない話なら最初から404とか200ですら出てこないだろ。
問題になるどころか、問題そのものがない
レス数が950を超えています。1000を超えると書き込みができなくなります。

ニューススポーツなんでも実況