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:
- Active (active)
- Away (away)
- Do Not Disturb (dnd)
- On Leave (leave)
- 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.
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.
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.
Now, let's update our useState
definition.
Now, let's try to update the status.
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:
- 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.
- 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.
Nothing seems different right now, but it is. Let's update the userStatus
value.
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.
Now, let's use this type in our useState
definition.
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.
Look at that,
- We can get the documentation of all the valid values by simply hovering over the
userStatus
and looking up its type definition. - 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.
- 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)