3

Backbone.js には、標準の HTTP 動詞を使用して変更をサーバーに同期できる優れた機能があります。

たとえば、モデル オブジェクトと get を実行するコードがあるとします。

var coolModel = Backbone.Model.extend({url:'mysite/mymodel'});
var myCoolModel = new coolModel();
myCoolModel.fetch({error:processError});

サーバーが 4XX または 5XX を返す場合、エラー関数 'processError' が実行されます。これは素晴らしいことです。適切な方法でエラーを処理できます。

backbone.js は jQuery を使用して GET を実行するため、Jquery はエラーを報告します。4XX は有効なエラーであり、回復する必要があります。クライアント側のアプリは壊れていません。動作が少し異なるだけです。

私の質問は - ブラウザーのコンソール ウィンドウまたはステータス バーに表示される jQuery からこのエラーを発生させることは悪い習慣と見なされますか? エラーが回復可能な場合に、本番環境のユーザーがブラウザーによって報告されたエラーを表示しないように、このエラーを何らかの形で抑制すべきですか? それともHTTPの世界ではそのままでいいのでしょうか？

4

2 に答える 2

2

Backbone でのエラー処理は非常に興味深いトピックであり、いつか書きたいと思っています。目立たない方法でユーザーにエラーを視覚的に示すことは非常に便利です。考慮すべき事項は次のとおりです。

  • ユーザーはステータスバーや開発者ツールを見ていません
  • ユーザーは、アプリケーションから特定の動作を期待しています
  • アプリケーションが正しく動作しない場合、視覚的な問題インジケータが重要です

失敗がユーザーの意図にどのように影響するかを検討することをお勧めします。たとえば、最初のページのデータをフェッチしていて、そのデータが正しく返されない場合は、取得したデータの失敗を表示してエラーを処理する必要があります (または、キャッシュから以前にロードされたデータにフォールバックすることをお勧めします...それが存在します）。アイテムを保存することが目的で、返されたエラー コードが 400 の場合、これは間違いなく成功ではなく、ユーザーが保存を再試行する必要があることを示す必要があります (または、間隔を置いて再保存を試みることもできます)。

エラーを表示せずに黙って無視することもできますが、ユーザーは混乱し、予期しない問題が発生する可能性があります。完璧なエラー処理を使うように説教することはできません。

于 2012-06-28T22:12:33.843 に答える
1

HTTP ステータス コードには理由があり、その理由が有効である場合は完全に有効であると言えます。そうです、そのまま使用してください。ただし:400はBad Request、入力が構文的に間違っていることを意味します。より適切なヘッダーを送信する必要があります(競合、前提条件の失敗など)。の有効な使用方法を考え出すのに苦労していますが、いつか成功するでしょう..409428418 I'm a teapot

あなたのサイトの内部の仕組みに興味のある人なら誰でもコンソールを見ることができますが、それで問題はないはずです。

于 2012-06-28T21:49:35.297 に答える