-1

ローカル マシンでシングル ページ アプリ (SPA) を作成していますが、ドキュメント ルートから数レベル下にあります。したがって、たとえば、私のインデックス ページは になりますhttp://localhost/projects/foo/index.html。

私はDavis.jsを使用して履歴 API でクライアント側のルーティングを行っていますが、ルートには絶対 URL を使用することを推奨しています。たとえば、ルート<a href="/hello/world">をトリガーします。/hello/world

にあるリンクをクリックするとhttp://localhost/projects/foo/index.html、URL が に変更されるため、これは問題http://localhost/hello/worldです。アプリは通常どおり続行されますが (実際にページを離れたことがないため)、これは明らかに正しくありません。ただし、ページを更新すると、ファイルhttp://localhost/hello/worldが存在しないため、404 エラーが発生します。

相対リンクを使用<a href="hello/world">すると、マークに近づくようになります。そのリンクをクリックすると URL が に変わりますが、ルートはトリガーされhttp://localhost/projects/foo/hello/worldません。/hello/world同じリンクをもう一度クリックすると、http://localhost/projects/foo/hello/hello/world(double hello) が表示されます。繰り返しますが、望ましくない動作です。

現在、Davis はドメインのルートからルートを照合しているため/hello/world、URL が の場合にのみトリガーされhttp://somewhere.tld/hello/worldます。/hello/world しかし、ドキュメント ルートから直接サービスを提供していたとしても、実際には存在しない問題がまだ残っています。

現時点で、私の現在の解決策は、デイビスにパスベースの代わりにハッシュベースのルーティングを使用させることです: http://localhost/projects/foo/index.html#/hello/world. ブラウザは常に読み込まindex.htmlれ、Davis には常に/hello/world. さらに、ユーザーが Javascript をオンにしていれば、そのハッシュ フラグメントを含むリンクは常に機能します。（その場合は気にしていません）

私が見ることができる 1 つの解決策は、ベース URL をhttp://localhost/projects/foo/にし、サーバーにそのディレクトリ内のすべてのリクエストを に書き換えさせindex.html、すべてのリンクとルートがベース URL + フラグメント (のような) を指し、一致させることhttp://localhost/projects/foo/hello/worldです。したがって、技術的には、これらの URLはすべて存在し、すべてが同じファイルを指しているだけです。ただし、これには、(a) URL 書き換えが可能なサーバーが SPA を提供し (URL ハッシュ ソリューションはサーバーを必要とせず、ブラウザーのみを必要とする)、(b) SPA がその「場所」を追跡する必要があります。ドキュメントルートに相対的です（これは私にとって非常に悪いことです）。

だから私の質問は、サーバー上のアプリの場所にとらわれず、できれば静的ホスティング以外のサーバー側のテクノロジーを必要とせずに、クライアント側のルーティングを行う正しい方法は何ですか。

4

2 に答える 2

1

シングル ページ アプリとクライアント側ルーティングで同様の経験をしたことがあります。

この問題を少し検討した後、最終的には、SEO の観点から、Davis が提案している絶対 URL でサーバーにコンテンツを実際にレンダリングさせる必要があることに気付きました。こうすることで、Google クローラーは、Web サイトが単一ページのアプリではないかのように、Web サイトを実際にクロールし続けることができます。

サーバー側のテクノロジーをまったく実行できないと言う場合、問題ははるかに困難になります。あなたが提示した解決策はすべて合理的です。

クローラに関する Google の仕様については、このリンクを参照してください。

于 2012-08-10T00:56:00.730 に答える
1

最善の方法は、Davis で定義しているクライアント側のルートをサーバーでも利用できるようにすることだと思います。したがって、クライアント側のルートがある/foo/bar場合、サーバーは理想的には同じルートに適切に応答できる必要があります。

これは思ったより単純なことが多く、mustache などの言語にとらわれないテンプレート言語を使用している場合は、多くの重複を伴​​う必要はありません。

これが不可能な場合は、サーバーがクライアント側のみのルートに対して 404 以外の値を返すようにするための回避策があります。ただし、これらは常に解決策ではなく回避策のように感じます。明らかに、答えは、構築しているアプリケーションの種類によって異なります。

相対ルートで Davis を使用することに関しては、これは私が使用したことがないものであることを認めます。したがって、それがどれほどうまくサポートされるかはわかりません。Davis の設計上、動作を妨げるものは特にありません。

ただし、ここでブラウザーで pushState API をいじっているだけで、相対パスに奇妙な点があるようです。

于 2012-09-02T21:50:06.760 に答える