Understanding the exclamation mark in TypeScript

Matt Angelosanto - Jul 13 '22 - - Dev Community

Written by Ibiyemi Adewakun✏️

The exclamation mark ! is known as the non-null assertion operator in TypeScript. We will be using these terms interchangeably in this article. But what does this operator do? In this article, we will take a look at:

What is the TypeScript exclamation mark?

The non-null assertion operator tells the TypeScript compiler that a value typed as optional cannot be null or undefined. For example, if we define a variable as possibly a string or undefined, the ! operator tells the compiler to ignore the possibility of it being undefined.

What the exclamation mark does in TypeScript

Let’s say a variable is defined as possibly null or undefined, like so:

let x: string | undefined
Enter fullscreen mode Exit fullscreen mode

Or, let’s say a function is defined to accept an optional argument, like so:

function printString (str ?: string) { … }
Enter fullscreen mode Exit fullscreen mode

In these cases, if we try to reference that variable as a definite type, then the TypeScript compiler would give us an error message, such as the following:

Object is possibly 'undefined'. ts(2532)
Enter fullscreen mode Exit fullscreen mode

We can use the non-null assertion operator to tell the compiler explicitly that this variable has a value and is not null or undefined. Let’s review a few examples to better understand the exclamation mark in TypeScript.

Example 1: Using a variable of type string | null for a function that accepts string

Let’s say we defined a variable word with the type as string | null. This means throughout our code, word can either hold a string value or a null value.

If we attempt to use a function only available to string types on word, TypeScript will reject it because there is a possibility in our code that word holds a null value type:

let word : string | null = null
const num = 1
if (num) {
    word = "Hello World!"    
}
console.log(word.toLowerCase()) // Error: Object is possibly 'null'.ts(2531)
Enter fullscreen mode Exit fullscreen mode

Using the ! non-null assertion operator, we can tell TypeScript we are certain word will never be null (or undefined), so it can confidently apply string functions to it:

let word : string | null = null
const num = 1
if (num) {
    word = "Hello World!"    
}
console.log(word!.toLowerCase())
Enter fullscreen mode Exit fullscreen mode

With this small addition, the compiler no longer believes there is a possibility that word is null.

Example 2: Assigning the value of an optional argument to a variable within a function

In another example, let’s say we created a function printName that accepts an optional argument personName.

Note that defining a function argument as optional using ?: is the same as defining type as possibly undefined. For example, arg?: string is the same as arg: string | undefined.

If we try to reassign that optional argument personName to another variable of type string, the following would occur:

function printName(personName?: string) {
    const fullName: string = personName 
/** 
 * Error: Type 'string | undefined' is not assignable to type 'string'. 
 * Type 'undefined' is not assignable to type 'string'.
 */
    console.log(`The name is ${fullName}`)
}
Enter fullscreen mode Exit fullscreen mode

We can fix the TypeScript errors thrown in our snippet above using the ! operator:

function printName(personName?: string) {
    const fullName: string = personName! 
    console.log(`The name is ${fullName}`)
}
Enter fullscreen mode Exit fullscreen mode

Now, the compiler understands that personName cannot be null or undefined, making it assignable to type string.

Example 3: Printing the attribute of an optional object argument within a function

In our final example, we will define a type Person and a function printName that accepts an optional argument of type Person. Let’s see what happens if we try to use printName to print the name attribute of Person:

interface Person {
    name: string
    age: number
}

function printName(person?: Person) {
    console.log(`The name is ${person.name}`) // Error: Object is possibly 'undefined'. ts(2532)
}
Enter fullscreen mode Exit fullscreen mode

Let’s fix this TypeScript error using our ! operator:

interface Person {
    name: string
    age: number
}

function printName(person?: Person) {
    console.log(`The name is ${person!.name}`)
}
Enter fullscreen mode Exit fullscreen mode

Note that TypeScript has an alternative for referencing attributes and functions on objects that might be null or undefined called the optional chaining operator ?. . For example, person?.name or word?.toString() will return undefined if the variable is not defined or null.

However, the optional chaining operator ?. cannot solve the TypeScript errors in our second example, in which we tried to assign the value of a variable type string | undefined to a variable type string. Learn more about optional chaining in the last section of this article.

Popular use cases for the TypeScript exclamation mark

As we’ve seen in our examples, the ! operator is very useful when we would like TypeScript to treat our variable as a solid type. This prevents us from having to handle any null or undefined cases when we are certain there is no such case.

Now that we have seen some examples to gain a better understanding of the TypeScript exclamation mark, let’s look at some popular use cases for this operator.

Performing lookups on an array

Let’s imagine we have an array of objects and we want to pick an object with a particular attribute value, like so:

interface Person {
    name: string
    age: number
    sex: string
}

const people: Person[] = [
  {
      name: 'Gran',
      age: 70,
      sex: 'female'
  },
  {
      name: 'Papa',
      age: 72,
      sex: 'male'
  },
  {
      name: 'Mom',
      age: 35,
      sex: 'female'
  },
  {
      name: 'Dad',
      age: 38,
      sex: 'male'
  }
]

const femalePerson = people.find(p => p.sex === 'female')
Enter fullscreen mode Exit fullscreen mode

In our snippet above, TypeScript will define the type of femalePerson as Person | undefined because it is possible that people.find yields no result — in other words, that it will be undefined.

However, if femalePerson has the type Person | undefined, we will not be able to pass it as an argument to a function expecting type Person.

When we are performing lookups on these arrays, we are often confident that they have defined values, and we therefore don’t believe any undefined cases exist. Our ! operator can save us from additional — or unnecessary — null or undefined case handling.

Add the non-null assertion operator, like so:

const femalePerson = people.find(p => p.sex === 'female')!
Enter fullscreen mode Exit fullscreen mode

This would make femalePerson have the type Person.

React refs and event handling

React refs are used to access rendered HTML DOM nodes or React elements. Refs are created using React.createRef<HTMLDivElement>() and then attached to the element using the ref attribute.

To use React refs, we access the current attribute, ref.current. Until the element is rendered, ref.current could be null, so it has the following type:

HTMLDivElement | null
Enter fullscreen mode Exit fullscreen mode

To attach an event to ref.current, we would first have to handle possible null values. Here is an example:

import React from 'react'

const ToggleDisplay = () => {
    const displayRef = React.createRef<HTMLDivElement>()

    const toggleDisplay = () => {
        if (displayRef.current) {
            displayRef.current.toggleAttribute('hidden')
        }
    }

    return (
        <div>
            <div class="display-panel" ref="displayRef">
                <p> some content </p>
            </div>
            <button onClick={toggleDisplay}>Toggle Content</button>
        <div>
    )
}
Enter fullscreen mode Exit fullscreen mode

In the snippet above, we had to handle a type check of displayRef.current using an if statement before calling the toggleAttribute function.

In most cases, we are sure that if the button onClick event is triggered, then our elements are already rendered. Therefore, there is no need for a check. This unnecessary check can be eliminated using the ! operator, like so:

const displayRef = React.createRef<HTMLDivElement>()

const toggleDisplay = () => displayRef.current!.toggleAttribute('hidden')

return (
        <div>
        ...
Enter fullscreen mode Exit fullscreen mode

The downside of using the exclamation mark in TypeScript

The ! operator does not change the runtime behavior of your code. If the value you have asserted is not null or undefined turns out to actually be null or undefined, an error will occur and disrupt the execution of your code.

Remember, the difference between TypeScript and JavaScript is the assertion of types. In JavaScript we do not need or use the ! operator because there is no type strictness.

A JavaScript variable can be instantiated with string and changed to object, null, or number during the execution of the code. This leaves it up to the developer to handle the different cases.

Using the ! operator takes away TypeScript’s “superpower” of preventing runtime type errors. Therefore, it is not the best practice to use the ! operator.

Alternatives to using the TypeScript exclamation mark

You could use optional chaining or type predicates as alternatives to non-null assertions.

Optional chaining is a TypeScript shorthand that allows us easily handle the cases where the variable is defined or not. When the variable is not defined or null, the referenced value defaults to value undefined. Here’s an example of optional chaining:

interface Person {
    name: string
    age: number
    sex: string
}

function printName(person?: Person): void {
    console.log('The name of this person is', person?.name)
}
Enter fullscreen mode Exit fullscreen mode

In our example above, if person is undefined, our print output would be as follows:

'The name of this person is undefined'
Enter fullscreen mode Exit fullscreen mode

Using type predicates in TypeScript is done by defining a function that performs a boolean test and returns a type predicate in the form arg is Type. Here is an example:

interface Person {
    name: string
    age: number
    sex: string
}

function validatePerson(person?: Person) person is Person {
    return !!person
}
Enter fullscreen mode Exit fullscreen mode

Using this type predicate, we can first validate the object before performing any further operations, like so:

function printName(person?: Person) {
    if (!validatePerson(person)) {
        console.log('Person is invalid')
        return
    }

    console.log(`The name is ${person.name}`)
}
Enter fullscreen mode Exit fullscreen mode

Conclusion

TypeScript’s power over JavaScript is the type safety it provides our code. However, we may sometimes want to disable TypeScript’s strict type checks — for example, for the sake of flexibility or backward compatibility. In such cases, we can use the non-null assertion operator.

Though a useful feature, I encourage you to explore safer type assertion methods instead. You can go a step further to prevent use of this operation in your project and with your team by adding the typescript-eslint package to your project and applying the no-non-null-assertion lint rule.

Writing a lot of TypeScript? Watch the recording of our recent TypeScript meetup to learn about writing more readable code.

Write More Readable Code with TypeScript 4.4

TypeScript brings type safety to JavaScript. There can be a tension between type safety and readable code. Watch the recording for a deep dive on some new features of TypeScript 4.4.

Image
Make Wezterm Mimic Tmux

linux, cli, productivity, ubuntu
Image
Streamline your WordPress development with Bedrock 💥
Image
I need your help
Image
Total bill
Image
Building a QR Code Generator with React

react, css, javascript, qrcode
Image
Running a Docker Swarm on Raspberry Pi 5

raspberrypi, docker, devops, containers
Image
CSS Positioning – Absolute, Relative, Fixed, and Sticky.

webdev, beginners, css, frontend
Image
Sunpump: Where Memes Meet Community and Cryptocurrency

sunpump, memeculture, cryptocommunity, nftmarketplace
Image
How to Run FLUX1 for Free: A Step-by-Step Guide

ai, tutorial, python, fastapi
Image
C# Streams Explained with Real-Life Analogies

csharp, dotnet, filestream
Image
Understanding Array Mutation in Redux: A Common Pitfall with useSelector

redux, react, learning, frontend
Image
Buy verified BYBIT account

webdev, javascript, beginners, programming
Image
Project Management in Software Engineering
Image
Imposter Syndrome: A Focus on Tech Developers
Image
Why Your Flutter App Feels Slow and How to Fix It?
Image
Wings Engine and interior design: creating an interactive design experience
Image
How to Add MinIO as a Service in a GitLab CI Job

gitlab, s3, cicd
Image
🚀 Unlocking the Power of Databases with Amazon RDS: Features, Benefits & More! 💡

cloud, database, rds, aws
Image
Follow Your Favorite Web Dev Topics With Frontend Dogma’s Topic Feeds
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player