Transcript from the "Course Agenda" Lesson
[00:02:03] So that's when I was learning this language a couple of years back, this is something that I missed. You'd read a TypeScript book or you'd go through a tutorial and there would be no sense of this is where the regular language ends and this is where the typed stuff begins.
[00:02:48] If you see the blue TS logo in the top right corner, that's something that you have to run to the TypeScript compiler in order to get new JS or browser to understand, usually that will involve types. So today, we are going to do a couple of isolated exercises that aim to kinda get our feet wet.
[00:03:07] Right? Help us tackle a few challenges where types can really make things simpler and more expressive. Tomorrow, we’re going to deal with a larger project that involves handling a synchronous code flow and React components. So we're gonna work with TypeScript and React. Don't worry if you don't know React yet.
[00:03:30] We're gonna be using it in a very simple way, but it is a great example of a library that has used the concept of types to add some structural where previously, you know it was sort of a free for all. At least the way I wrote React, it turned out I would add something to props, or something to state.
[00:03:51] And I would add it as needed and the rest of my code would not be aware that, hey this new property is available, because there's no clearly defined structure.
>> Speaker 2: The type definitions used for TypeScript, are there similar definitions using flow or some of these paradigms could they be translated into flow?
>> Mike North: Conceptually, all of these should carry over, one of the, so something you can check out if you choose there's a video visual studio code course I taught earlier this week and the video should be online now. You can even use JS Doc comments to use TypeScript looking types in inert comments.
[00:04:56] The difference here, of course is, this is not inert code. This is a different language, right, and as a result I think personally, given the choice, someone said write me some code for a browser that has type information. I would choose TypeScripts simply because with comments you're limited to sort of wrapping your types around the code as best you can.
[00:05:41] Anytime you've written a function that takes in, like, as arguments, two objects, that's not, that is not expressive. What are those objects? What properties are allowed on those objects? What's optional and what's required? And so now, we can say, we can basically say upfront, what's the form of this objects that I wish?
[00:06:01] What's the form I want them to take? And we can catch that at compile time, right? Rather than catching it up run time feel via bug report we'll get a build time, red squiggle under a line of code. One of the common mistakes people run into when starting out with TypeScript is they kinda add types everywhere.
[00:06:23] And it's important to understand that a type system is designed around, it is a way of expressing constraints. And there is a way to go to far. It's like I would say the defaults path will lead you to going too far and you basically can sort of lock yourself in and find that you're wrestling against these types rather than letting them you know help you put guard rails in the right places.
[00:07:15] So we will see how we can incrementally start shifting towards a Type Script code base. This isn't, I don't want you to think of this as, we're going to rewrite everything in something like CoffeeScript, which is a totally different syntax. Coffee Script is not really a super set of anything.