In this article, you'll learn all you require to begin using TypeScript along with React, and more critically we'll discuss why you should or why you should not be using TypeScript. There's a decent case to be made for both sides of that argument. In case you're new here, subscribe to my blog for more content relating to TypeScript.
How about we investigate two unique projects side by side, one with TypeScript and one without. There is a wide range of approaches to add TypeScript to a react application, however in this case I'm utilizing the "create react app" method and specifying the TypeScript format.
The create-react-app documentation also has instructions for adding it to an existing project. If we take a look at these two projects side by side the clearest difference is that the TypeScript project has files finishing off with ".ts" or ".tsx".
Does TypeScript reduce Bugs in code?
Now one thing you'll regularly hear TypeScript engineers say is that it assists them with catching silly bugs in the development before they become enormous debacles in the production. Let me give you an example to check whether that statement is true. Look at this nested invalid code below.
Although remember that it doesn't replace test-driven development workflow. TypeScript can detect inadequately structured code in advance but can't detect awful logic.
Generally speaking, this is an ambiguous "type" definition. In TypeScript, we can be much more explicit about what our code is. React has a built-in type called "FC" which represents "function component" and we can assign that type to the component utilizing a ":" followed by the "type" value. Take a look at this code.
This tells the compiler the structure of our expected code, which will toss an error for anything that is not a valid prop and autocomplete all the other things as well. By default, the only known react prop is "children" but we can characterize the structure of our props utilizing a TypeScript interface.
The following code is an example of how an interface is defined.
An interface permits you to characterize the structure of an object by giving a property name to each "type". Here, we have an interface called "CoolProps" that ought to be an object with two properties - count and name. One of which is a number and the other a string. In its current structure, the interface will make these properties required on the object. However, you can make them optional by adding a question mark after the property name.
We can now take this interface and pass it to the function component "type" by enclosing it with "< >". This resembles saying we have a function component that additionally includes props of its custom shape.
Now, we get truly helpful IntelliSense in Visual Studio Code on any props when working with this component and it additionally ensures that we use the correct props when working with this component in JSX.
Anyway, that came at a significant cost. We've added a great deal of boilerplate to the code base without adding any new functionality for the user. Now it is feasible to bypass type checking at whatever point you need by essentially adding the "any" type that permits you to quit TypeScript but in addition contradicts the entirety of its advantages.
It's additionally important to know that TypeScript can give automatic documentation to your code because your editor will automatically pick up the type definitions. So anyone utilizing your code will get IntelliSense on the shape and reason concerning it. And that is way far more efficient than going to read some documentation online. Now, in many scenarios TypeScript can automatically gather the type without you adding any extra code to the code base. For instance, you could firmly write the useState hooks "type" like given below.
However using "< >" may not be necessary here because, if you have a default value of a string, you don't have to give it an explicit type. it'll have a "string" type automatically. On the off chance that you attempt to change it to a value that is not a string, you'll get that prophetic error in VS Code. So that is quite useful.
So, is TypeScript truly awesome?
It is supervised by Microsoft, enterprises love it, debugging is easier, but anyway, some guy on the internet also said it only catches 15% of bugs and Airbnb said it catches 38% of bugs and so on. In the end, it comes down to - Would you rather write more code or would you rather be more confident in the code you do write now? Would you rather take a look at your documentation on an online site or would you rather have it be automatic in your editor? Would you rather write quicker code now or manage chaotic refactoring later? Do your friends love it or do they despise it? These are all trade-offs that you need to think about. However, as I would see it, the response to should you use TypeScript with react is clearly ..........