2022-04-27
1272
#typescript
Matteo Di Pirro
103746
Apr 27, 2022 ⋅ 4 min read

Optional chaining and nullish coalescing in TypeScript

Matteo Di Pirro I am an enthusiastic young software engineer who specialized in the theory of programming languages and type safety. I enjoy learning and experimenting with new technologies and languages, looking for effective ways to employ them.

Recent posts:

AI First Debugging

AI-first debugging: Tools and techniques for faster root cause analysis

AI-first debugging augments traditional debugging with log clustering, pattern recognition, and faster root cause analysis. Learn where AI helps, where it fails, and how to use it safely in production.

Alexander Godwin
Dec 29, 2025 ⋅ 6 min read

Container queries in 2026: Powerful, but not a silver bullet

Container queries let components respond to their own layout context instead of the viewport. This article explores how they work and where they fit alongside media queries.

Sebastian Weber
Dec 26, 2025 ⋅ 12 min read
Server Components Vs Islands Architecture LogRocket

Server Components vs. Islands Architecture: The performance showdown

React Server Components vs Islands Architecture: Learn how each reduces client JavaScript, impacts hydration and interactivity, and which trade-offs matter for production performance.

Muhammed Ali
Dec 26, 2025 ⋅ 4 min read

How to build agentic AI when your data can’t leave the network

Large hosted LLMs aren’t always an option. Learn how to build agentic AI with small, local models that preserve privacy and scale.

Rosario De Chiara
Dec 23, 2025 ⋅ 5 min read
View all posts

2 Replies to "Optional chaining and nullish coalescing in TypeScript"

  1. I think this article could potentially “misteach” people to create types like `nullableUndefinedString` when you could mostly use `argOrProp?: string | null`.

    Also, there’s no need to use strict types checks for null and undefined when you could check for both like `value == null`.

  2. Regarding nullableUndefinedString, you’re right and, as a matter of fact, it was just an easy way to define a single type used throughout the entire article without repeating it meaning every time.

    strictNullChecks, on the other hand, is recommended by the documentation itself. Hence, even if there are other ways in the language to achieve the same result, to me, the pros of that flag outweigh the cons.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now