Best Practice: null vs undefined vs defaultValue in State when using TypeScript

[felix9ia]

I'm seeking advice on a common architectural dilemma regarding "empty" state values when using Zustand with TypeScript

Questions

1. Is using null the recommended way for nullable state in Zustand to satisfy the persist middleware, despite the TS friction?

2. How do you handle the impedance mismatch? Do you simply accept the ?? undefined boilerplate in every component, or is there a cleaner pattern (e.g., a selector utility)?

3. Nullable vs. Default Objects: For object states, is it better to initialize with a "default empty object" (e.g., { id: '', ... }) to strict-type the state and avoid null entirely? I'm concerned this makes "empty checks" harder (can't use if (!shopInfo)).

// Store definition
interface ShopState {
  selectedFulfillmentCode: string | null; 
}

or 

interface ShopState {
  selectedFulfillmentCode: string | undefined; 
}

or 

interface ShopState {
  selectedFulfillmentCode?: string; 
}

or 
interface ShopState {
  selectedFulfillmentCode: string; 
}
const defaultState = {
selectedFulfillmentCode: DEFAULT_CODE
}

Handling Strict Object Initialization: For object states that strictly require a value (non-nullable), I considered initializing them with default empty objects (e.g., shopInfo: { id: '', name: '' }) to avoid the null/undefined mess entirely. However, this makes it harder to check if the data is actually "loaded" or "empty" (since if (shopInfo) will always be true). Does the community prefer using Nullable types (ShopInfo | null) or Default Objects for persisted data?

Consumption Layer / UI (Expects undefined): However, the vast majority of React Hooks and UI libraries (like AntD, custom hooks, etc.) define optional parameters as string | undefined (or param?: string), not string | null.

The Pain Point

This creates a pervasive type mismatch (Type 'null' is not assignable to type 'string | undefined'). To bridge this gap, I find myself having to manually convert null to undefined in almost every component:

// This feels verbose and "hacky" to do everywhere
const { selectedFulfillmentCode } = useShopStore();

<CartActionBar 
  // 3rd party UI component
  code={selectedFulfillmentCode ?? undefined} 
/>

useCustomHook({
  // Custom hook
  code: selectedFulfillmentCode ?? undefined 
});

Questions

Is using null the recommended way for nullable state in Zustand to satisfy the persist middleware?

How do you handle this impedance mismatch with UI components? Do you simply accept the ?? undefined boilerplate, or is there a cleaner pattern (e.g., a middleware, a selector utility, or specific strict types)?

I'd love to hear how others handle this "Storage vs UI" type conflict in large applications.

Thanks!

[dbritto-dev]

You can read it like this

• null: defined as empty
• undefined: not defined