So we're using the core types of no boolean and string.
And here in the list of parameters of dysfunction we're always explicitly assigning to types with a
colon.
Often the parameter name and then the name of the type.
So here the names are no boolean and string.
And in case you were wondering these are now special identifiers.
This overall here is a special syntax which is added by typescript.
It's not part of the compile javascript code.
If we check that code here these type assignments are gone because javascript does not support them.
Does colon thing after a variable or after a parameter and then number and boolean and string these
special keywords.
This is introduced by typescript the typescript compiler understands it.
The idea e here supports TypeScript and therefore doesn't complain about these special keywords.
Javascript does not understand the syntax it doesn't understand a colon after a parameter where a colon
after a variable and then the special number or string keyword javascript doesn't understand this and
therefore does is not part of the javascript output.
It's really just use but it types with compiler and then well it is a compiler because it converts this
code to JavaScript code.
Side note you also see it switches concept for Wah but that's something I'll come back to later.
So we have our explicit type assignments here and it's only understood by typescript right.
Why don't we have them down there.
I don't have explicit type of assignments here and by the way also not here when we calculate the result
for example because typescript has a built in feature which is called Type inference This means that
typescript does its best and it does a pretty good job there to understand which type you have in a
certain variable or a constant.
And here for example it understands that no one will always be of type no in the end because you initialize
it with a number.
Now this actually is a constant.
So it's even more specific than that.
And the type it identifies here is not just any number it's the number five because you'll not be able
to assign a new number or a new value to a concept value anyways.
If you what changed is to a variable.
So if you would use let instead then of course this would not break anything we can use a variable there.
It might be best practice because there's value never changes but it's also not horrible.
But now if we hover over this we see typescript doesn't say okay.
This has to be a 5.
But still it detects that the type here is a number.
Now we absolutely could write this code here on our own.
We can add a colon after the variable name on the left side of the equal sign and then the name of the
type.
So basically the same we did in the parameters of this function but does this redundant and it actually
is also not considered to be a good practice because typescript is able to perfectly infer this type
from there.
So assigning this is not a good idea.
This only changes if you would create this variable in a unassigned way.
Like this if you don't initialize it immediately then it's a good practice to tell typescript which
value will eventually be stored in there so that when you later assign a value to it.
And of course it's a bit redundant here to split this in two lines.
I'm just doing this for demo purposes but now if I assigned this here this works because I told typescript
in advance that this will be of type No you don't have to do that.
It also works if you don't do that but now you could also add this 5 and you wouldn't get an error because
you're not telling typescript anything about the type which will be stored in this variable and therefore
typescript allows any type.
If you instead add code a number here you're telling typescript hey eventually a number will be stored
in there and hence if you later stored something else and there like in this case where we store a string
you'll get an error here in the idea.
And of course also if you compile your code we'll get the error.
We already saw before so this is how you can assign types.
Now even if types just inferred a type and let me fix this it will yell at you if you break that inferred
type.
Actually it's wrong to say even because of course it does.
Why would it not do that type and for instance dare for you to save you code to a why did you manually
have to assign a type of course typescript yells at you if you then use a wrong type a type that it
did not infer.
For example here if resolve phrase is created with left so that it's variable then type code here infers
that this will be of type String because we initialize it with a string.
So this is basically the equivalent to not initializing it and setting the type on our own and then
assigning a value later.
Now if we change result phrase to let's say 0 here for whatever reason we might want to do that well
then we get an error here.
That type 0 is not a signal of type String and that makes sense right typescript inferred that we want
to store a string.
We're now trying to store a number we get an error.
That's the job.
The core task of typescript checking typos and yelling at us if we're using them incorrectly.