條件邏輯快速摘要：要求和邊緣情況

隨著時間的推移，我們發展了讀寫邏輯條件的技能，新的語言功能可以為我們提供新的解決方案。但並非所有解決方案都是平等的。讓我們快速看一個例子。

設定

假設我們有一個可能存在於多個位置的屬性，並且我們希望優先考慮巢狀實例。以下是一些可能的解決方案：

// 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;

找出差異

它們在功能上看起來非常相似，但存在細微的差異。根據我們的業務需求或資料設計，其中一些可能會導致錯誤。

看一下這三個選項，看看您是否能夠辨識出結果會有所不同的不同場景。我們對每個版本做了什麼假設？

營運商分析

首先，考慮起作用的特定運算符。

• 三元 - 使用 truthy 檢查來決定使用哪個表達式。
• 可選連結 - 如果物件是nullish，則傳回未定義，但如果它只是falsy。
，則不回傳未定義
• Nullish Coalescing - 如果第一個表達式為 nullish.
，則使用第二個表達式

不為空

三元運算子在這裡脫穎而出。對於大多數實際目的來說，當我們談論物件時，它的行為方式是相同的。差異歸結為當事情不起作用時我們期望的值是什麼。

未分配的物件通常是未定義或為空。但是，如果我們的專案使用 false 或“還不是物件！”，則使用三元組做出的假設可能會產生不必要的結果。不過，這是一個不太可能出現的極端情況。

了解意圖

如果我們忽略不太可能的「非物件」場景，選項 A 和 C 基本上是相同的。

1. 如果config.user存在，則取得config.user.setting。
2. 否則，取得config.setting。

選項 B 做了一些不同的事情。

1. 如果 config.user.setting 存在，請使用它。
2. 否則，取得config.setting。

差異很小，但直接關係到需求或技術設計決策：如果缺少用戶，還是僅在缺少 user.setting 時，我們會回退到 config.setting？

兩者都是有效的可能性，但如果我們做出錯誤的假設，當我們期望預設值時，我們可能會一無所獲，或者當我們期望什麼都沒有時，我們最終可能會得到一些東西。

結論

除了問目標是什麼之外，這裡沒有「正確答案」。我們需要更多背景資訊。對於計畫成員來說，要求澄清這些問題可能顯得迂腐，但如果我們與期望不一致，這些小細節可能會產生非常微妙的錯誤。

對於這個專案或整個公司來說可能有一個正確的答案。我們甚至可能在一個專案中使用多個選項；一是聚焦價值；另一個重點是結構。也許沒有人考慮過這些差異。也許團隊認為他們是一致的，但實際上並非如此。

不問你就不會知道。

以上是條件邏輯快速摘要：要求和邊緣情況的詳細內容。更多資訊請關注PHP中文網其他相關文章！