Conditional Logic Quick Bits: Requirements & Edge Cases

We develop skills for reading and writing logic conditions over time, and new language features can provide us new solutions. But not all solutions are equal. Let's take a quick look at an example.

Setup

Let's say we have a property that might exist in multiple places, and we want to prioritize the nested instance. Here are some possible solutions:

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

Spot The Differences

These look pretty similar in functionality, but there are subtle differences. Depending on our business requirements or data design, some of these might cause bugs.

Take a look at the three options and see if you can identify the different scenarios in which the result will differ. What assumptions are we making with each version?

Operator Analysis

First, consider the specific operators at play.

• Ternary - uses a truthy check to decide which expression is used.
• Optional Chaining - returns undefined if the object is nullish but not if it is just falsy.
• Nullish Coalescing - uses the second expression if the first one is nullish.

Not Nullish

The ternary operator stands out, here. For most practical purposes it will behave the same way when we're talking about objects. The differences come down to what we expect the values to be when things aren't working.

An unassigned object is usually undefined or null. But if our project uses false or 'Not an object, yet!', the assumption made with the ternary could produce unwanted results. It's a pretty unlikely edge case, though.

Understanding Intent

If we ignore the unlikely "non object" scenario, Options A and C are basically identical.

1. If config.user exists, get config.user.setting.
2. Otherwise, get config.setting.

Option B does something different.

1. If config.user.setting exists, use it.
2. Otherwise, get config.setting.

The difference is small but speaks directly to a requirements or technical design decision: Do we fall back to the config.setting if the user is missing, or only if the user.setting is missing?

Both are valid possibilities, but if we make the wrong assumption, we may end up with nothing when we expect the default, or something when we expect nothing.

Conclusion

There is no "right answer" here other than to ask what the goal is. We need more context. Asking to clarify these questions may seem pedantic to project members, but these small details can make very subtle bugs if we don't have alignment on the expectations.

There might be a right answer for this project, or for an entire company. We might even use several options in a single project; one to focus on the value; another to focus on the structure. Maybe nobody considered these differences. Maybe the team thinks they aligned when they aren't.

You won't know if you don't ask.