ホームページ >ウェブフロントエンド >jsチュートリアル >条件付きロジックのクイックビット: 要件とエッジケース
私たちは時間の経過とともに論理条件を読み書きするスキルを開発し、新しい言語機能が新しいソリューションを提供します。しかし、すべてのソリューションが等しいわけではありません。例を簡単に見てみましょう。
複数の場所に存在する可能性のあるプロパティがあり、ネストされたインスタンスを優先したいとします。考えられる解決策をいくつか示します:
// Option A: Ternary const setting = config.user ? config.user.setting : config.setting; // Option B: Optional Chaining and Nullish Coalescing const setting = config.user?.setting ?? config.setting; // Option C: Destructuring and Nullish Coalescing const { setting } = config.user ?? config;
これらは機能的にはかなり似ていますが、微妙な違いがあります。ビジネス要件やデータ設計によっては、これらの一部がバグを引き起こす可能性があります。
3 つのオプションを見て、結果が異なるさまざまなシナリオを特定できるかどうかを確認してください。各バージョンではどのような前提を置いていますか?
まず、使用されている特定の演算子について考えてみましょう。
ここでは三項演算子が目立ちます。ほとんどの実用的な目的では、オブジェクトについて話しているときと同じように動作します。違いは、物事がうまくいかないときに期待される値に起因します。
未割り当てのオブジェクトは通常、未定義または null です。しかし、プロジェクトで false または「まだオブジェクトではありません!」を使用している場合、3 項で行われた仮定により望ましくない結果が生じる可能性があります。ただし、これはかなりありそうもない特殊なケースです。
可能性の低い「非オブジェクト」シナリオを無視する場合、オプション A と C は基本的に同一です。
オプション B は何か違うことをします。
違いは小さいですが、要件または技術的な設計上の決定に直接関係します: ユーザーが見つからない場合、config.setting にフォールバックしますか、それとも user.setting が見つからない場合にのみフォールバックしますか?
どちらも有効な可能性ですが、間違った仮定をすると、デフォルトを期待したときに何も得られず、何も期待しなかったときに何かが発生する可能性があります。
ここでは、目標は何かを尋ねる以外に「正しい答え」はありません。より多くのコンテキストが必要です。これらの質問を明確にするよう求めることは、プロジェクト メンバーにとっては衒学的に見えるかもしれませんが、期待に沿った調整が行われていない場合、これらの小さな詳細によって非常に微妙なバグが発生する可能性があります。
このプロジェクト、または会社全体にとって正しい答えがあるかもしれません。 1 つのプロジェクトで複数のオプションを使用することもあります。 1つは価値に焦点を当てること。もう1つは構造に焦点を当てることです。おそらく誰もこれらの違いを考慮しませんでした。おそらくチームは、一致していないのに一致していると思っている。
聞かないと分かりません。
以上が条件付きロジックのクイックビット: 要件とエッジケースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。