Good morning, everyone. Second time for me at Fostem. Wow, it's incredible. I've been giving talks for a few years already, but I find you guys are a tough, tough crowd.

I'm going to do my best to give you whatever I need to give you today about TypeScript. My name is Davy. I'm a software engineer, and I love JavaScript. You love JavaScript too, right? If you love JavaScript, you do this.

Now look around you. If you hate JavaScript, you do this. Now you can squeeze a little bit the room for the people. Just press them in the middle. I have a bold title, so it was a title to get you in the room, so I'm happy that you're all here.

Write safer JavaScript. What does that mean, safer? I'm just quickly going to go through the agenda. We're just going to see JavaScript versus TypeScript, getting to love TypeScript, and migrating from JavaScript to TypeScript. But I need to answer this question first. What safer means? Sorry?

Undefined is not a function. Say someone? No bugs. Ooh, I like that. That's very ambitious, man. I like that. Say again?

Easier debugging. How many people here in the room do JavaScript really? Very good. Now keep your hands up. How about TypeScript? I don't have to convince you, really. I'm just going to make sure that at the end of the session,

when I say TypeScript, everyone raises their hands, and they want to do that every day. Yeah, that's the problem. You know that, right? Cannot read property bar often defined, or null is not an object, or you're trying to call a function, cannot read property value often defined.

That's really common. Foo is not a function. Cannot read property length of undefined. That's the safer part I'm talking about, right? I'm not talking about security and all this stuff. I'm just talking about the fact that you can write code that doesn't crash in production.

That's run times error, right? We have two things. Run times errors and compile time errors. While you're writing your code, you'll be able to see this with TypeScript.

You'll be able to detect that up front. JavaScript versus TypeScript. JavaScript is yellow. You know that color, right? That's JavaScript. TypeScript is blue. JavaScript is, whoever is doing JavaScript only in the room is already doing TypeScript.

Okay? Because TypeScript is a superset of JavaScript. The way I introduce TypeScript to teams that we coach, I tell them TypeScript is a documentation tool.

I'm going to show you why I'm calling it a documentation tool. Yeah, it looks like a programming language, but as you start using it, you're going to realize that it is more documentation tools than a programming language.

That yellow thing, all of you are doing it, and the blue part is what TypeScript brings on top of the table. TypeScript is a superset of JavaScript. The way it's described on a Microsoft website is JavaScript that scales.

Small demo time. I'm just going to take a thing called TypeScript Playground. You can follow with me on this one if you want.

It's a small... Can you see this? Let me put it full screen. Let me remove this. Keep in mind that what I'm about to show you is the fact that JavaScript... TypeScript is a superset of JavaScript.

In JavaScript, we have class. Let's say user. As you can see on the left, on the left here is TypeScript. On the right is JavaScript. The only difference between the two is just the use strict so far. We're still in the yellow zone.

Everyone, you write TypeScript, you're basically having 101 JavaScript on the other side. That's the yellow zone. Then you want to write, let's say, a variable called user.

We're still in the yellow zone, right? So far, so good? Then you will say, what is user? In TypeScript, you can express documentation. You can express that user is a user.

It's a class type user. Guess what? I'm using type, right? I'm using this to document that line. I'm using that class. I'm using a class. I'm going to show you in a few seconds that you shouldn't be doing it. You shouldn't do that.

Stay with me for a second. I'm still having 101, but I don't have this anymore. I don't see this thing here, that typing. Documentation. I'm just documenting my code. But look what's going to happen. Here, now, I'm going to say user has login, which is a string.

By having login here, right away here, this isn't working anymore. On the other side, we still have the same translation, but this isn't working.

That won't stop your program to work, but at least you see it right away. That's what we were talking about. Compile time. Now, if I want to fix it, I'm just going to have to add a login here that says Devi. Fix it. We're still in the yellow zone.

Now, I'm going to take you to the blue zone. Why aren't you happy? There again. Yeah, it just asked me to give him a default value. That's it. That's what he wants, which is a good thing.

Now, I'm going to take you to the blue zone. Instead of using a class, I'm just going to use an interface, and then I don't need to. If it's an interface, it's a contract. I don't need to initialize that anymore. But look left and right. On the right, I only have the cost, and on the left, I have this interface here on the left

and only the user translation on the right. See, I use an interface to type my object, but I don't overload the final JavaScript that is rendered.

The only thing I really did right here, I documented this. Documentation. I'm going to show you another example of documentation that you can do. It's to say I want the user to go toward a certain direction.

Right away, you can see that he's not happy because you just had a property like you would do in JavaScript. Let me just add that property quickly. The property you just had has an impact all the way in the chain because people are using,

or they don't expect that property, but you just had that, and then in production, boom, direction of whatever is undefined. But I want that direction here to come from an enum. Or I can say a numeration, let's say direction.

As you can see here, I had a numeration, and then right away, I have this magic happening here, this line. Then I would just add left and then right, for example.

There is a one-on-one translation from enum to something that looks like this. If you don't understand that part of the code, it's okay. It's just they're using some closure to create a variable, and then they encapsulate the entire thing,

and then that gives you a way to assign a left and right property on an object dynamically. Now here I can say this thing is a direction that is left, but I'm still having a problem here. What I'm going to do, just to add a direction property, and then say this one is of type direction.

It's just an enum. It's documentation. Here I'm expressing the fact that you can go left and right. I could have used an object, const, object, direction, and then left and right. That would have yielded the same result.

But see how you can make it much more appealing here? I'm just going to say const. You see what happened there? It all disappeared. There is no more overload of JavaScript that you're going to give to your customer,

because that's the part your customer will use in their app, in the final app they run. But you, in your code, you express something to make the work of your team easier.

That's the message I want to pass here, the fact that TypeScript is documentation. We good so far? Let me quickly go back here. Getting to the law of TypeScript, I'm going to take something quickly here for you.

I have this function, setValue. When I say setValue, I'm going to receive this value, and I say if value, var, realValue, and then value here.

If I call it, can you all see this? If I call setValue, and I do this, and then I say setValue to be... Here I actually need to say this, and then this.

That would probably be much more realistic. Here I say Devi, and then here I say number 12. Guess what is happening here?

What do you think is going to be yield here on line 9? That doesn't work. That won't work. See, now we're already talking about the fact that hosting is going to be into play here.

It's going to enter into play here. There is already kind of understanding JavaScript, but as well understanding the fact that are we going to enter here?

Is this code written in a sense like this can enter here? First line, 9. Is it going to enter here? No. Then the two other cases will enter, but regardless we're going to have undefined here, and then Devi, and then 12.

I'm going to have to open the code source and then start making sense of what you're trying to do. I can make it much easier by saying value could be either a string or number.

See? By doing those, these two already are solved. But how about this part? I can communicate via documentation that this part is sometimes optional.

I'm just documenting my code. That's all I'm doing. Once you reach that part, there's some magic that's going to happen here. You can use a good let here that will make your life much easier, but if you do so, you see the scope going to enter and play, and that's not TypeScript.

That is just raw JavaScript. Let me just move it here. Then it doesn't crash, and then I can set the value right here. Now it's not over because I still need to do something that looks like what is the possible return value?

If you give me a string or number, I can also have as return value a string and a number. I'm just expressing what my code is supposed to do.

Here is the thing. The day I discovered what I'm about to show you, I discovered that in TypeScript, and I was like, there is no way I'm doing JavaScript again. I'm going to show you that line of code. I was here, and I said value dot. Because I already said string or number, when I say value dot, I only get to string or value, right?

But then one step further, I realized that if I have an if condition like this one, and I can say type of value is equal, let's say, string.

Now inside here when I say value dot, that at this moment my brain just did,

there is no way you're not doing TypeScript in your life. Just that. Just with that, all the screen I've shown you functioned as an exist and disappeared entirely. Yeah, some cases won't work entirely, but this gives you what I'm trying to show you.

I can go much further. I'm happy to talk about it right after. What I'm saying here, TypeScript is a documentation tool. It is a documentation tool. The next question will be, if you have a huge JavaScript project,

how can you go from JavaScript to TypeScript? There are three steps. Three. The first one is super easy. Just make it work. You know what I mean here?

You generate a TS config file, TS config, which is a TypeScript configuration. Then you add set implicit any, which is just a property in your TS config. You just put it at false. What does that mean? It means any JavaScript, it just makes sure that you're still in the yellow zone.

That's it. That's all it does. It doesn't yell at you, but TypeScript is already there. So you're still in your JavaScript project, not TypeScript. TypeScript is just behind watching everything at first. Then you rename all your JS file to TS or TSX if you're using React and Preact and all these tools.

That's it. Don't force that onto your team. Just do this. They won't see it. They will see the TS thing, right?

But for them, that won't really change in terms of the code they write every day. Right? That's one step. Second one, now be explicit. Don't turn the any to, instead of false, put it at true.

You know what's going to happen? It will just put some red line between the things that don't have types. That's it. That's all it's going to do. Everything is still okay. You can put that on your team. They'll be okay. They will just be like, we have new red flags.

What is happening here? Then you tell them, let's just take all the types, the common types. Like if you're on a Node project, just do npm install at type node. Just do that. This is a common type. They're all known. Once they're in your project, most of the red things will just vanish

because it will recognize that node typing, it's there. That's it. Well, don't do that in two days. Just do the first step, then you wait three months, then you do this part. Then you add typing for third party tools.

The library you're using and stuff like that, you add typing for that. Now, that part, you should leave that for a few months. I'm not kidding because the third part is where you get into war. The third part is be strict. It means that you just go in the TypeScript config file,

and then you put strict to true. What does that mean? It means that your project isn't working anymore. It just means that now you're going to have to type everything. You're going to have to express every single line of code in your application.

That's what it means. I have a repo for you. I have a repo for you where I have those three steps. It's in the resource part, and you can just take the three steps. With that, I hope that you'll be able to play with TypeScript a little bit more.

I'm going to be outside answering questions. If you want to drink TypeScript, I'll be here. If you want to think TypeScript with React, I'm going to help. TypeScript with Vue.js, I'm going to help. I know those things. TypeScript with Angular, I'm not going to help because it's already there.

Just go and do it. Voila. Questions? One question over there. There's someone at the back of the room.

Who had the question? Hi. Thank you for your presentation. I would like to know, there are a lot of libraries that don't have types for TypeScript.

I would like to know how you can generate this. You have tools that can basically scan those libraries and then generate generic typing for them. That's going to facilitate the work.

On GitHub, there is a GitHub repo. Define the type, something like that, where you're going to mostly find whatever you need. In 2012, 2013, 2014, TypeScript was a nightmare. Guess what? Today, it's top of the game.

On top of the game, literally, from the React team to the Vue team, they all used that to write Cephra code today. You have tools that can generate types for you. Don't be shy. It's recorded, but we don't know your name.

Just your voice. Exit is this way, if you are in rush. Thank you, people.