Okay, this is just a quick lesson to demonstrate the benefits of using TypeScript versus using JavaScript.
And I've replicated this project using JavaScript.
And this is an app.jsx.
And it's exactly the same code that I have inside the app dot TSX.
And I've made a small change because the demonstration doesn't really work because I did have a type
for this use state, but instead I've just put the name and the price inside.
Here.
You don't need to follow along.
This is just a quick demo to justify the use of TypeScript, if you will, because not all developers
love TypeScript, and some developers still to this day think that it adds unnecessary boilerplate to
our code.
But I disagree, and TypeScript has improved a lot over the years, so that the boilerplate that we
do need to add to get type safety in our code is quite minimal, really, in comparison to the time
it saves us when we make a typo.
And typos as a software developer are the enemy.
It's very easy to do, especially in configuration files, especially in JavaScript.
And it used to be a real problem, because a typo in a JavaScript file is not going to let you know
at compile time whether or not you've made a mistake.
TypeScript is going to fail, and it's going to fail very noisily.
So these two projects, they're effectively the same in the app.jsx.
In this case, and the app dot TSX in this case.
And just one other small change I've made is that the JavaScript project is running on port 3001.
The TypeScript one is still on port 3000, but to accommodate multiple origins inside our Cors configuration,
then we do just need to add both of those in there.
You don't need to follow along with this.
This is just a very short demo to demonstrate the benefits of using TypeScript.
So this is the TypeScript version of this application.
And this is the JavaScript version of this application.
Both going out to the same API endpoint, both receiving the products back.
Now the benefits of using TypeScript is if I was to make a typo in, let's say, the ad product, for
example, and for the name, instead of the correct spelling of name, I decided or I made a mistake
and called it names.
Then in this case, in the JavaScript world, we don't get notified that there's a mistake in our code.
And even without adding the TypeScript information, just the inference that we get from providing an
initial value to our use state without actually specifying any type information, then we get notified
very noisily that there is a problem if we hover over this error.
One of the gripes about TypeScript is these warnings or these error reporting inside the code editor.
These do admittedly look horrible.
And when you do encounter this, and you will encounter this because TypeScript can on occasions be
tricky to use.
My suggestion is to scroll down to the bottom of the error and take a look at what it says in the last
line or two, because typically this is going to give you the information you need, and specifically
it tells us that the property name is missing in type and then it tells us the type.
In this case names.
And it's required in type name colon string price colon number.
So in the last few lines we can kind of figure out what it is we're missing here, especially when it
comes to looking at the code.
Then we can say oh okay of course I've made a typo here.
But in the JavaScript world then we don't get notified what the problem is.
And this can go all the way into production without us noticing.
And the only time we see that we do have a problem is when we try and use it.
Then we don't get the desired effect inside the code in the TypeScript one.
This used to crash our application.
It doesn't do that anymore and we do still get the same.
We still can use the application and still get the same problem.
But the advantage is, we're told very noisily as we're writing the code that something isn't right,
and then we can make the desired correction.
Now, as it comes to using TypeScript in our code, we're going to create proper types for each of the
things that we're using.
So when it comes to hovering over the products, then we're going to have the full properties available
inside our products.
And what that gives us is much better.
IntelliSense and Autocompletion inside our code editor VS code is brilliant with TypeScript by using
TypeScript, even if we don't specify proper types, we do get decent intellisense and type safety because
if I start typing or try and use item dot something, I get the list of properties that are available
for this type that it's inferred from what we're using inside the state.
In JavaScript world, if I try and do the same thing and I say item dot, then sure it can guess and
it can guess pretty well because things have improved over time.
And we do see the name and price, but we've got all of these other things that we can select.
And I could say, yeah, sure, I want item dot JSON here, but guess what?
That doesn't exist.
And I don't get notified that there's a problem.
So these are a few of the reasons that TypeScript is beneficial to use in our application.
It doesn't have to mean that that we write a lot of extra code to get the benefits from it.
But the time savings is immense, because if you make a small typo in a large code base with lots of
functionality in just pure old, plain old JavaScript, and you have to track that problem down, it
is time consuming.
Whereas in TypeScript you're not going to make that mistake because you're going to be notified of the
problem as you're writing the code.
So it's a bit like insurance.
You don't appreciate it until you actually need it.
Otherwise it just feels wasteful to keep paying out for insurance that you don't need because you don't
crash your car.
But at that time where you do crash your car, you are very grateful when you've got insurance.
And TypeScript can be seen in the same way.
So we will be utilizing TypeScript.
And in the next lesson we're going to take a look at creating a type for our products.