DEV Community

Cover image for Get Started With TypeScript in 2019

Get Started With TypeScript in 2019

Robert Cooper on January 20, 2019

Get Started With TypeScript in 2019 Originally posted on my blog Based on the Stack Overflow Developer survey in 2018, TypeScript is ...
Collapse
 
tomekbuszewski profile image
Tomasz Buszewski

Hey Robert, great article!

I am using TypeScript myself and, to be frank, at first I thought bad about it. But then I went to a project without any typing and I saw the benefits from static typings :)

One question though. When I work with large objects, for example a response from REST, and doing a model, should I write the entire interface for it? It can have many optional fields, given the quality of the API itself. How should I approach it?

Collapse
 
robertcoopercode profile image
Robert Cooper

That's a great question, and i'm not sure what the best approach is here. My intuition tells me that
the API response doesn't require an interface, but rather the model/object you create from the API response should be typed. The reason I say this is that you don't have control over fields the API returns, but you do have control over the properties on the model/object that you create from the API response.

Hopefully that wasn't too abstract of an answer and that it made sense.

Collapse
 
tomekbuszewski profile image
Tomasz Buszewski

Hey Robert, and thanks for your answer.

While I agree with you, when I create a model, I need to know on which fields I can operate. This is a very common problem for me recently as I work with a lot of CMS' and integrate them into our app via modeling.

Collapse
 
blindfish3 profile image
Ben Calder

You do of course need to type what you expect to get in the response and then use within your application. In my experience any unused data needn't be typed...

But this is one situation where IMO typings can give a false sense of security: API responses that are out of your control can (and often will) change unexpectedly - e.g. return null on a property where you don't expect it; so it's still important to have some guards in place to avoid responses that might crash your application.

Collapse
 
mouvedia profile image
G. • Edited

Is there a type that corresponds to () => any? Is it interchangeable with Function?

Collapse
 
cookavich profile image
Paul Cook

You could type a function like that:

function foo(): () => any {
  return 'bar';
}

I generally avoid using the any type, so, in that case I would type it like so:

function foo(): () => string {
  return 'bar';
}

Same goes for arguments.

I see many gifted devs default to any a lot when they're first getting into TypeScript. I think that is fine as a start, but as a goal I would want to have the proper types for arguments/return values.

I think a heavy use of any generally indicates a lack of clarity about your program, and if you have a lack of clarity than anyone who works on the code after you will be even more unclear.

Why don't you know what the types are? And how can you better figure them out?

Collapse
 
sagarb3 profile image
Sagar Bhattacharya

Good Point , whenever we are writing code we should be very sure of the input and output , which leads to clarity of logic as well as a good code-base , simple to read and simple to extend. When I started coding I was very poor about making this decision , but overtime I have learned that even if you cannot adhere to strict types in early phase , you must make sure to correct those things in self-review and make it a part of the code writing to be very clear about all the possible input and outputs.

Collapse
 
robertcoopercode profile image
Robert Cooper • Edited

Good question. There is no function type. When annotating types for a function, you must specify the types of the parameters and the return values.

Collapse
 
karataev profile image
Eugene Karataev

Thanks for the great article!
I'm new to TypeScript and couple of days ago I decided to convert my Node JS project to TS for better maintability. I heard many times that firts steps should be painless - just rename .js to .ts.

TypeScript allows you to easily convert a JavaScript file by changing the file extension from .js to .ts and all the code will compile properly as TypeScript.

Nevertheless, I faced couple of problems from the beginning.
Consider the most basic Node project:

// hello.ts
function hello() {
  console.log('hello');
}

module.exports = {
  hello
};

// index.ts
const {hello} = require('./hello');

hello();

JS version works as expected, but TS throws

error TS2451: Cannot redeclare block-scoped variable 'hello'.

I had to replace require to import across all project files to fix the issue.

Another problem popped up when I tried to compile TS files without types for 3rd party libraries.

Anyway, right now I'm in the middle of moving the project to TS and I feel much more confident with it's logic and data structures compared to the raw JS version.

Collapse
 
ant profile image
Ant

really great,I can't wait to use Typescript after reading your article.

Collapse
 
vladyn profile image
Vladimir Varbanov

great introduction - many thanks!

Collapse
 
stealthmusic profile image
Jan Wedel

Hi, great summary! Thanks for writing, I will keep it in my bookmarks.

Collapse
 
reisclef profile image
Richard C

Excellent summary. I just started with typescript a couple weeks ago and am enjoying working with it. I may refer back to this as "quick reference". ;)

Collapse
 
varmab profile image
Varma Bhupatiraju

Nice intro to TypeScript. Thank you.

Collapse
 
cagataysert profile image
Çağatay Sert

Thanks a lot. It was very helpful article for me :))

Collapse
 
mochfamir profile image
Mochamad Faishal Amir

Hi Robert this article very helpful, I learn Angular and also must have knowledge about Typescript.

Collapse
 
uf4no profile image
Antonio

Very good article, thanks for sharing.
Do you have any tips regarding debugging in TS?

Collapse
 
robertcoopercode profile image
Robert Cooper

Debugging TS errors can sometimes be tricky since they are not always straightforward. However, the more you work with TS, the more better you'll get interpreting the errors.