随着时间的推移，我们发展了读写逻辑条件的技能，新的语言特性可以为我们提供新的解决方案。但并非所有解决方案都是平等的。让我们快速看一个例子。
设置
假设我们有一个可能存在于多个位置的属性，并且我们希望优先考虑嵌套实例。以下是一些可能的解决方案：
// 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 基本上是相同的。
- 如果config.user存在，则获取config.user.setting。
- 否则，获取config.setting。
选项 b 做了一些不同的事情。
- 如果 config.user.setting 存在，请使用它。
- 否则，获取config.setting。
差异很小，但直接关系到需求或技术设计决策：如果缺少用户，还是仅在缺少 user.setting 时，我们会回退到 config.setting？
两者都是有效的可能性，但如果我们做出错误的假设，当我们期望默认值时，我们可能会一无所获，或者当我们期望什么都没有时，我们最终可能会得到一些东西。
结论
除了问目标是什么之外，这里没有“正确答案”。我们需要更多背景信息。对于项目成员来说，要求澄清这些问题可能显得迂腐，但如果我们与期望不一致，这些小细节可能会产生非常微妙的错误。
对于这个项目或整个公司来说可能有一个正确的答案。我们甚至可能在一个项目中使用多个选项；一是聚焦价值；另一个重点是结构。也许没有人考虑过这些差异。也许团队认为他们是一致的，但实际上并非如此。
不问你就不会知道。
