DEV Community

Cover image for Why React + TypeScript Nullability Slowly Becomes Exhausting
i-am-killvish
i-am-killvish

Posted on

Why React + TypeScript Nullability Slowly Becomes Exhausting

#react #typescript #webdev #opensource

One React + TypeScript Pattern That Slowly Turns Into Workflow Fatigue

One React + TypeScript pattern I keep seeing everywhere looks like this:

const [user, setUser] = useState<User | null>(null);
Enter fullscreen mode Exit fullscreen mode

A few minutes later, the component becomes:

user?.name
user?.email
user?.profile?.avatar
user?.settings?.theme
Enter fullscreen mode Exit fullscreen mode

Repeated across the entire component tree.

Individually, none of these lines feel like a huge problem.

But repeated hundreds of times across a codebase,
they slowly become surprisingly exhausting.

The Interesting Part

The frustrating thing is:

TypeScript is not wrong here.

React state often starts as null because:

  • data is loading
  • async requests haven't completed
  • auth state is unresolved
  • server data hasn't arrived yet

So the compiler is being intentionally conservative.

And honestly, that safety is useful.

But From The Developer Side...

After a while, it can start feeling like this:

user?.name
user?.email
user?.profile?.avatar
user?.settings?.theme
user?.preferences?.language
Enter fullscreen mode Exit fullscreen mode

over and over again.

Especially in larger React applications where nullable async state exists almost everywhere.

Async Fetching Makes It Worse

A very common pattern looks like this:

const [user, setUser] = useState<User | null>(null);

useEffect(() => {
  fetchUser().then(setUser);
}, []);
Enter fullscreen mode Exit fullscreen mode

From TypeScript’s perspective:

user might still be null
Enter fullscreen mode Exit fullscreen mode

which is technically correct.

But mentally, developers often already understand the lifecycle flow:

loading → data arrives → component renders
Enter fullscreen mode Exit fullscreen mode

That creates an interesting tension between:

  • compiler safety
  • runtime understanding
  • developer ergonomics

The Real Friction

I’ve started noticing that many TypeScript frustrations are not huge architectural problems.

They’re usually:

  • repetitive
  • mechanical
  • mentally interruptive
  • individually tiny
  • but exhausting when repeated constantly

Things like:

user?.name
Enter fullscreen mode Exit fullscreen mode

or:

if (!user) return null;
Enter fullscreen mode Exit fullscreen mode

don’t feel huge in isolation.

But repeated across hundreds of components,
they slowly create workflow fatigue.

React + TypeScript Has A Unique Kind Of Friction

What makes React especially interesting is that:

async UI state naturally creates nullability everywhere
Enter fullscreen mode Exit fullscreen mode

Unlike many backend systems where data may already be validated before use,
React components constantly deal with:

  • loading states
  • delayed async data
  • partial renders
  • optional props
  • unresolved context values

which makes defensive rendering patterns extremely common.

Why This Became Interesting To Me

Recently I’ve been exploring these React + TypeScript friction patterns more deeply while working on compiler-aware tooling and AST-based fixes in my CLI project fixmyfile.

And honestly, the deeper I go into TypeScript ecosystems,
the more I feel developer frustration often comes from:

small repetitive safety patterns
Enter fullscreen mode Exit fullscreen mode

not massive technical failures.

Final Thoughts

I don’t think TypeScript is wrong here.

The compiler is intentionally conservative.

But I do think there’s a growing opportunity for tooling and developer workflows that reduce:

  • repetitive defensive rendering
  • cognitive interruptions
  • mechanical nullability friction

without sacrificing type safety.

And honestly, React + strict TypeScript has become one of the most interesting ecosystems to study from a developer ergonomics perspective.

If you work heavily with React + TypeScript, I’d genuinely be curious:

what repetitive friction pattern annoys you the most?

Top comments (0)