I'll proceed with the blog assuming you have previously worked with JavaScript. Knowing JavaScript would have you catch on to TypeScript concepts pretty easily.
Typescript has gained a lot of popularity over the years since it was made.
credits: The State of the Octoverse
Looking at issues you might run into in JavaScript
Let's start with a simple problem. Say we have a object that has these properties.
const person = {
name: 'John',
age: 30,
hobbies: ['Sports', 'Cooking']
}
After writing plenty of code we wanted to access a property of this object. We forgot the object doesn't have a property called "lastName" but we tried to access it anyways.
const lastName = person.lastName;
JavaScript won't throw an error but it will return undefined
. Now imagine, the variable getting passed through multiple layers of functions .
Locating the point of error would drain the life of our finitely mortal life.
We can solve this problem by using TypeScript.
being able to access a variable not present.
multiple null.
fixes JavaScript problems with types.
Types
Types are basically the kind of data that a variable can hold. Some primitive types of types are: Integers, Strings etc.
If anyone comes from a C++, C or a Java background, they would know about types.
In JavaScript when we declare a variable
let name = 'John';
const age = 30;
Here in both age
and name
any kind of data can be stored. While this may seem convenient to a developer in the beginning is a nightmare while debugging if you input a wrong type of data.
Static type checking
Typescript is what we call a static type checker. It
checks for errors relate to types before we run our code.
TypeScript doesn't really run our code. It performs this type checking before we run our code using JavaScript.
After compiling Typescript is compiled to JavaScript which can be executed as usual.
If we take the above example in TypeScript we can see the compiler warn us before even running our code.
Running TypeScript
TypeScript cannot be run directly through the browser or node. TypeScript is compiled to JavaScript. To do so, we install typescript globally using npm.
npm i -g typescript
Once we have installed TypeScript globally, we get access to the tsc
command.
We'll look at running TypeScript and it's many features in the next blog.
Top comments (19)
TypeScript is not a superset of JavaScript. This perfectly valid JS throws an error in TS:
it error because it does not pass the type check (that is the purpose of typescript: type check)
doesn't mean typescript is not super set of javascript
a valid JS code that does not pass typescript type check only throw error on compilation but not run time
simply expect the error and you can run the code
playground
Instead using
Add a dynamic type and defined possible types for value
the reason i use
// @ts-expect-error
is because I want to show that untyped code is a valid code in TSalso
[key: number | string]
in unnecessary because it is equivalent to[key: strting]
dev.to/tylim88/typescript-caveat-1...
True Sorry my mistake. Object keys is always a string.
ts-expect-error will report if there is no error.
Unused '@ts-expect-error' directive
Which can be solved with
// @ts-ignore
Itโs a choice of course.
which is why you should only use it on line that has error
normally
// @ts-ignore
is not desirable because it is not granular, it will just ignore everything and will ignore thing that you don't want to ignore (but is ok in this case)and because of granularity
// @ts-expect-error
is very useful in type testingobject key can be numeric, it will be converted to string on runtime
type wise key type of both
{[x:string]:unknown}
and{[x:string | number ]:unknown}
arestring | number
which is why I said it is unnecessary, not incorrect
TS expect / ignore
The ideas which when to use, have you points to add? Or other advice?
a good analogy is something like const and let vs var
in what case you need var? almost none
so I never use ts ignore, I only use ts expect error
if you find yourself in need of ts ignore, you probably need refactoring or you have compatibility issue
If some valid JS throws an error in TS, then - by definition - TS cannot be a strict superset of JS
I am not sure where did you get that definition
here is the definition from wikipedia
TypeScript is a programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript and adds optional static typing to the language.
en.wikipedia.org/wiki/TypeScript
I'm going by the definition of 'superset' - a set that contains another set. So if the set of valid JS contains things that are not in the set of valid TS, TS CANNOT be a superset of JS.
The key part of the wikipedia definition is 'syntactical' - the JS example given is syntactically valid in TS, but will cause an error. This is an important distinction. Far too many people believe all JS code will run just fine in TS because 'TS is a superset of JS' - but this just isn't the case.
I've also seen examples of valid JS that will do something quite different in TS.
I want to clarify that JS code is indeed valid in TS, TS understand the JS which is why it is able to point out the type mistake (which is the purpose of TS)
and you can by pass the error(ignore it or type cast it), the compiler will still emit the same code where you type it correctly or not
it is like TS saying: "Heh man I know what you are trying to do, and I and not quite happy with it, but if you insist to go on, I will just let it pass"
If JS is not a valid TS code, TS wont even able to understand it at all and respond it with error like invalid syntax
not saying typescript compilation is completely fine, but this is something that common outside of typescript, for example babel plugins that compile same JS code differently, there is just too many way to compile JS
You mean it will leave the JS unchanged? This is not true either (I believe even the TS docs mention this) - some valid JS will be altered by the TS compiler.
Going back to the superset thing - if you take out 'syntactically', then it is possible to argue that TS is actually a subset of JS (or contains a subset of It). Why? Because it's possible to do things in plain JS that it isn't possible to do in TS (without modifying the JS to please the compiler, or turning off TS error checks - but then the code is compiled back to JS anyway)
I mean the properly typed and improperly typed will still produce the same code
the type notation will not affect the final JS code emitted
for example If TS decide to compile
a
tob
, with or without the type annotation, the result will still beb
whether
a
should beb
, whether it makes sense or not, is another storyTS will mangle this valid JS code - making it do something different:
this should be counted as deficiency, bug, or todo
ya like I said, whether 'a' should compile to 'b' is another story, even babel itself has many way to compile the same JS code, and by this logic should we say JS itself is invalid JS?
It really depend on the understanding of the author, they could be right, they could be wrong
Yep, the problem is (as I said) - the widespread misunderstanding of what 'TS is a superset of JS' actually means. I've lost count of the number of times I've heard people say that 'all your existing code written in JS will run with no problems in TS, you can just add the types gradually' - and then watching the ensuing chaos.
I've written libraries for JS that some really good TS developers I know have tried to make compatible with TS... they gave up!
TS can certainly be the right tool in some situations, but other situations it actually blunts the power of JS.
The misunderstanding is people think by copy and paste think will work
No, by superset it means the compiler understand JS syntax
it has nothing to do with the effort of the developer, it is not about the developer!
I wouldnโt recommended to install TS global, I would recommend to install it as dependacy. So you will be sure all teammembers will use the same TS version
You can use is as follow with npx