DEV Community

Cover image for How TypeScript Makes React Better: Smoother Developer Experience, Fewer Bugs (With a useState Example)
Idris Gadi
Idris Gadi

Posted on

How TypeScript Makes React Better: Smoother Developer Experience, Fewer Bugs (With a useState Example)

Let's start with a scenario and a task associated with it.

We have a messaging application with a status bar that shows the user's current status and allows them to update it. We have to add a dropdown from which the user can change their status and use useState() to show and update the user's current status in the UI.

For simplicity, we will only focus on the useState implementation in this article, and by the end of the article, you will understand how even for a simple example TypeScript is a much more powerful option.

The Task

We have to define a useState() that stores and updates userStatus and is initialized with one of the five possible status options (let's say active).

All the possible options are:

  1. Active (active)
  2. Away (away)
  3. Do Not Disturb (dnd)
  4. On Leave (leave)
  5. Out Of Office (OOO)

JSX/JS

This is a very straightforward task, right? All we have to do is define a useState and initialize it to active and then use the set function to update the status and we are done.

Screenshot of useState definition in JS

But wait! What happens when someone is reviewing my code or visits this piece of code later (say after 1 week, 2 weeks, 1 month, 6 months, or whatever), how will they know what are all the possible/valid options?

Ahh! Yes, we can add a comment next to the useState to let them know that these are all the possible options.

Screenshot of useState definition in JS with possible options mentioned in the comments

But, this isn't a good solution, right? So, how can we improve it?

Object Lookup

Object lookup is a really nice solution to our problem. So, let's start with defining an object lookup called UserStatus and use it to set our userStatus value.

Screenshot of UserStatus object lookup definition

Now, let's update our useState definition.

Screenshot of userStatus useState initialized with UserStatus object lookup

Now, let's try to update the status.

Screenshot of using setUserStatus with object lookup and getting autocomplete

Ohh! Look at that, now we get autocomplete in our editor and can check all the possible/valid values of userStatus by looking at the definition of UserStatus.

The Issues with Object Lookup

Even though the object lookup method has seemingly solved our problem and is definitely a far better solution than just adding comments, it still has two major issues:

  1. For anyone visiting our piece of code later, they have to know that we are using an object lookup to set our state. This might seem trivial but imagine as our component grows and becomes more complex, then it becomes very easy for someone to be unaware of our implementation.
  2. It still doesn't prevent anyone from setting any random value to our state, even when they are aware of the object lookup.  

So, how can we solve these issues?
Answer: Typescript

TSX/TS

Let's start again with our solution, but this time in a .tsx or a Typescript file. We can start by defining a useState() function and initializing it with the value: active.

Screenshot of useState definition in TS

Nothing seems different right now, but it is. Let's update the userStatus value.

Screenshot of using setUserStatus function with some string valid/invalid and other type of values

Ahh! As you can see it is giving us that dreaded red squiggly error line around some set functions but not on ones where we are setting a string value. This is because Typescript is inferring the type of our state from its initial value (i.e. type string).

Yes, this will prevent us from setting any non-string values to our userStatus state, but it still doesn't prevent us from setting any random string value and we still have to use the object lookup for documenting all the possible options, you may ask.
 

Let's do some "One Stone, Two Birds".

Explicit Types and Generics

In Typescript we can create custom types and it also has support for generics which can be used in React for its hook definitions, in our case the useState() hook.

Let's create a new UserStatus type in our React component.

UserStatus type definition

Now, let's use this type in our useState definition.

Screenshot of useState definition in TS with custom type

Till now, everything looks similar to how we were doing it in the object lookup method, but the magic of Typescript is when we start using our set function and the state value.

  1. Getting the type definition of userStatus.
    Screenshot of hint box in editor showing the type of the state

  2. Autocomplete for the setUserStatus function.
    Screenshot of getting autocomplete for the valid values in setState function

  3. Getting proper validation for valid and invalid values.
    Screenshot of the editor showing that only valid values are accepted and all the invalid values are getting errors

Look at that,

  1. We can get the documentation of all the valid values by simply hovering over the userStatus and looking up its type definition.
  2. However, we don't need to look at the type definition of our state value when using the set function, as it automatically gives us the autocomplete for all the valid options.
  3. Now it not only gives us the error when setting a non-string value, but it also gives us the error for using invalid string values (i.e. it will always give errors for invalid inputs).

Conclusion

By now, you probably have got a good feel for how TypeScript can really enhance our development experience. We have only scratched the surface with a simple example here, but just think about the real-world applications we’re building, using TypeScript could mean way fewer bugs and a way better developer experience overall.

I hope this article encourages you to start using Typescript in all your React applications and build awesome web experiences.

If you liked this article and would like to connect, then you can connect with me on Linked and X/Twitter

Top comments (0)