Transcript from the "Converting to TypeScript" Lesson
[00:00:49] It's like rewriting something from Ruby to Rust. That is like apples and oranges, right? So I'm gonna lead you down a three-step process that will make it so this change can be made incrementally on a couple of files at a time. Or in multiple passes where you get to the endpoint you are looking to get without potentially running into creating extra work for yourself or disruption for people who depend on that code.
[00:01:45] Is this truth versus check whether this value is undefined, no zero and empty string are gonna be handled differently. So you want to avoid even those kinds of functional changes if you can. You don't want to try this kind of conversion if your test coverage is really low.
[00:02:02] Because after each of our three steps run a test sweep like your test sweep for this piece of code, and ensure that not only have we converted to TypeScript, but the library still works the way we want it to work.
>> Mike North: You don't want to let the perfect be the enemy of the good.
[00:02:24] And in this sense what I mean is don't try to type things too strongly, too early on. Your goal is to get converted, and you'll start to see some benefits of the strong typing, but don't chase those benefits by trying to type things up prematurely. You want to get converted over and then start applying stronger typing where things make sense.
[00:02:52] The reason for this is, particularly if you convert a few files at a time, and you have some very strongly typed things. As soon as you convert some of the other files that interact with your already strong code, you don't have a chance to start out with sort of weak types.
[00:03:08] Cuz your constraints are already very tight, right? In one part of your app. So you kind of want to remember the goal is, get converted and then we'll ratchet things up. Don't forget to add tests for your types. Again, dts lint is the way you write tests that's specifically are for type information only.
[00:03:31] And also particularly for libraries, don't try to publish types for consumer use until you're happy with them. Because people take type information that comes along with the library as an indication of a public API. What you should do and what you shouldn't. Remember, it's developer intent. If you wrote this code in TypeScript in the first place, those types would express what you can do and can't do with piece of code.
[00:04:00] So if you prematurely have people using this stuff, and there's a bunch of looseness all over the place, you can lead them on a wild goose chase where they're assuming things should be doable and valid. And in fact that's not the case.