DEV Community: Jade Banks

Why Truthy Checks can Break on Zero in TypeScript

Jade Banks — Mon, 23 Mar 2026 06:03:00 +0000

JavaScript/TypeScript can treat non-boolean values as booleans in certain situations. Basically, there are a set of values which are defined as Falsy. All other values are considered Truthy.

When combined with Optional Properties, code can be more concise and easier to read.

Consider a system for filtering numerical values where each filter property is optional.

type FilterOptions = {
  greaterThan?: number,
  lessThan?: number,
};

/* Returns true if `value` satisfies the filter, false otherwise */
function isInFilter(value: number, filter: FilterOptions): boolean {
  if (filter.greaterThan && value <= filter.greaterThan)
    return false;

  if (filter.lessThan && value >= filter.lessThan)
    return false;

  return true;
}

/*
  Demonstrates the filtering function by logging
  the numbers between -5 and 5 that satisfy the filter
*/
function filterExample(filter: FilterOptions) {
    const results:number[] = [];

    for (let i = -5; i <= 5; i++)
      if (isInFilter(i, filter))
        results.push(i);

    console.log(results.join(','));
}

// No filtering
// Output: -5,-4,-3,-2,-1,0,1,2,3,4,5
filterExample({});

// Numbers above 2
// Output: 3,4,5
filterExample({
    greaterThan: 2,
});

This works fine, with and without the greaterThan property.

However if we apply the following, it will fail

// This fails
// Expected Output: "1,2,3,4,5"
// Actual Output: "-5,-4,-3,-2,-1,0,1,2,3,4,5"
filterExample({
    greaterThan: 0,
});

The bug is in this line

   if (filter.greaterThan && value <= filter.greaterThan)
     return false;

When filter.greaterThan is 0, it is considered falsy in the same way undefined is. So it behaves as if that filter property wasn't set.

The fix is to change the line to the following

   if (filter.greaterThan !== undefined && value <= filter.greaterThan)
     return false;

Same fix would be needed for the lessThan property.

Final Thoughts

When treating non-boolean values as booleans, make sure you've considered all the possible Falsy values that could apply in your application. The same issue could occur for an empty string "" or NaN for example.

If a value can be undefined or null, you'd need something like the following

    if (filter.greaterThan !== undefined && filter.greaterThan !== null && ...)

    // Note: single `=` to apply loose equality
    if (filter.greaterThan != undefined && ...

You can play around with this code in this Playground

React: Use 'Excess Property Checks' in setState() to avoid subtle bugs

Jade Banks — Mon, 09 Mar 2026 04:27:43 +0000

TL;DR

When using objects as state, annotate the return type on callbacks passed to setState()
e.g. Instead of setState(state => do setState((state): State =>

Overview

The Spread Operator is a JavaScript feature, it is particularly relevant however to React because State Objects should not be mutated.

Here we see a common pattern in the following code (parts omitted for clarity)

// Define app/component state
type State = {
  name: string,
  count: number,
}

// Declare initial state
const [state, setState] = useState<State>({ name: 'Unknown', count: 0 });

// Partial state updates made like this
function resetCount() {
  setState(state => ({
    ...state,
    count: 0,
  }));
}

Problem

Consider this code for setting the count property back to zero, while preserving the values of the other properties.

// This code doesn't trigger any errors, despite the mistake
setState(state => ({
  ...state,
  cont: 0, // typo of `count`
}));

The issue is the typo will not be picked up by the type checker. This is because the spread operator has given us a fully formed object of the State type, the incorrectly spelt cont is considered an additional (excess) property. The type checker is considering this valid.

Due to IntelliSense/Auto complete, it's not likely this would happen when writing new code but can occur more subtly when renaming.

If we decide, for example, after some time, that count should be personCount. Many references to the old name will be flagged in the IDE as errors, prompting us to update them. This won't be the case for setState() calls though. Not at build nor run time. We're now setting a property that doesn't exist in the State type (count) and the target property (personCount) keeps it's existing value. This refactor could introduce a breaking change.

There is a good chance this would not be picked up in code review either, due to the nature of code reviews focussing on the changed lines, and this error being on an unchanged line.

How can we fix this

Using the IDE Refactor > Rename feature would give us better coverage of the rename but we cannot be expected to remember this every time.

We want to force TypeScript to apply Excess Property Checks. This can be done by simply setting a return type on the function passed to setState(). In other words, we change state => to (state): State => and it would look like this

type State = {
  name: string,
  personCount: number, // Renamed from `count`
}

const [state, setState] = useState<State>({ name: 'Unknown', personCount: 0 });

// IDE error shown (as desired) saying that 'count' is not a known property
function resetCount() {
  setState((state): State => ({ // This line changed to include return type
    ...state,
    count: 0,
  }));
}

By specifying the return type explicitly, we now get build time checking on the properties we specify and can be more confident our code is what we intend.

useReducer()

The normal approach for complex state structures is to use useReducer() instead.

The same advice applies here, make sure to explicitly set the return type

// ✘ - Relying on inferred return type won't check excess properties
function reducer(state: State, action: Action) {
  ...
}

// ✔ - Setting the return type helps catch incorrect properties
function reducer(state: State, action: Action): State {
  ...
}

Other Approaches

Immer library

The Immer library provides a proxy object to do in place updates. We don't need to re-create objects ourselves, so can rely on TypeScript checking that the properties exist.

Use a 'Helper' function

I wouldn't suggest this as a general approach as it's not idiomatic React and may make the code harder to understand for other developers.

However it's worth showing as the Partial<Type> Utility Type can be very useful

// Helper function
function update(partial: Partial<State>) {
  setState(s => ({
    ...s,
    ...partial
  }));
}

function resetCount() {
  update({ cont: 0 }); // Error: 'cont' correctly flagged as not existing
}

Finally

You can read the Type Compatibility documentation if you want to learn in more detail about this and the reasoning behind the design decisions.

If you use AI tools and the code it generates doesn't follow the suggested fix automatically, then add this into your agents/rules file, giving it the correct and incorrect forms as an example.