There are a lot of really great reasons to use TypeScript, but we’ve occasionally encountered some hesitancy from programmers not sure how much of an adjustment it will be. Learning Typescript is not as complicated as say learning Elm and I’d argue it’s more enjoyable to use than Flow. But the hesitancy is understandable. Many front-end developers have learned JavaScript and Ruby or Python, but have not had to dig into typed languages. Learning to program with types and think about your type system in advance can elevate your programming style and eventually be easier than not using types. However, there are many different ways to be good at programming, and I have seen a range of programming styles that might make the learning curve of TypeScript steeper. Everyone eventually adjusts to TypeScript on their own and most come to love it. From those of us who have already made the change, here are some super simple tips and hacks while you’re getting your sea legs in TypeScript.
First of all, if you’re having trouble adjusting and just want to spike, go ahead and put it in JavaScript first and then once it’s working, convert the file to TypeScript and add in the types. When you want to spike on a story to see if your idea even works, TypeScript can be a bit of an unnecessary slow-down, and that’s where most of the early frustration with TypeScript comes from. This is a method you’ll want to move away from later (it’s got some overhead), but if you just want to spike on an implementation, feel free to do it in plain-old JavaScript and then transfer it. You can even leave the occasional .jsx
or .js
file in place if it’s appropriate. After all, they can co-exist.
If you just want to spike on a single function or maybe a configuration issue across your files, a tried and true, and also highly controversial, suggestion is shifting your types to any
. Just put “any” as your type and slowly backfill once you have your code working.
This is honestly a just plain super useful method of spiking when you’re new to TypeScript, but this method’s got some detractors. If you put off the hard work of rereading TypeScript documentation and training your brain to think about the input types first, then the worry is that you’ll never end up really learning it. Spend some time early on with TypeScript, learning those types and trying to think in a TypeScript way. And then if all else fails and you’re just trying to see if your stupid Redux setup works, shift all the types to any
and just remember to clean up before code review.
You want the computer to carry some of the load for you and getting your tools to play well with TypeScript is a big part of that. If you’re not married to your editor and/or trying to defend it across all comment sections of the Internet, consider VS Code. It’s got a lot of niceties like automatic imports, showing type errors, and autocomplete. Webstorm is also highly recommended. For vim, people here recommend yats when you use TypeScript. For emacs, people here recommend tide and typescript-mode
.
Really, you should always have a linter in your life. You will not be getting half the benefits of Typescript if you do not have a linter for your project and if your text editor or IDE isn’t set up to pop up with helpful advice. Being able to hover over that offending red line telling me something is wrong is so much easier than spinning up my app only to find out it won’t compile. Right now, Palantir is producing tslint
, but in the future, this should all be a part of eslint
.
Additionally, when doing fiddly stuff like map-fold-reduce, you can use your linter to tell you what type it expects. Bind an expression to a variable with a deliberately-incorrect type like void
to see what is inferred. Maybe it’ll give you clues to program your way through the collection pipeline chaos.
No really, I do want my debugger, thank you very much TypeScript. There’s a lot of times where TypeScript will actually let you know what’s wrong with your code. But sometimes you just need to stop and debug something! TSLint by default enables no-debugger
and no-console
and this will stop your files from compiling. Just turn it off and make sure you don’t commit the change.
For the top of files:
// tslint:disable:no-console
// tslint:disable:no-debugger
Or just in your config file for the project.
By default, null
and undefined
are assignable to all types. Do yourself a favor and enable strictNullChecks, so you know when you have nulls and when you don’t. This is the majority of JavaScript bugs I feel like TypeScript catches when enabled.
If you’re used to ES5 and you’re now using transpiled ES2018, you can’t test out even a simple ES2018 loop your browser console anymore, but you can iterate through a loop on your perfectly good Node console. This is no surprise for Node programmers, but sometimes Rails-or-Python-stack-heavy folks forget, myself included. Just type node
in your terminal.
Additionally, if you want a TypeScript-specific REPL, there’s ts-node, which lets you try out your TypeScript on the fly. Wut! Amazing, right?
Sometimes it’s hard remembering the types when you’re writing something out. Copy and paste the relevant types into your file and comment it out or just keep that type file open in a different window when you’re writing your implementation.
Sometimes you really do need to tell the compiler that this is the type you think it is.
If this throws an error:
this.span = document.createElement(‘span’);
Then make it this:
this.span = <HTMLSpanElement>document.createElement(‘span’);
What’s wonderful about the TypeScript ecosystem is that you can import types for just about anything, from Mapbox to HTML Elements. If you are working extensively with a library, Definitely Typed almost definitely has a type for that. When you import types remember that you can extend
them if you’re adding on values not originally there.
There’s some admittedly weird syntax for typing destructured assignments. Work on also getting your string literal types and enums in good shape. You’ll use them a lot.
// String literal example
type Easing = “ease-in” | “ease-out”;
Finally, don’t worry. You’ll eventually sort all of your keys alphabetically by default because TypeScript has trained you to do that (we call this machine->human learning). You’ll add in the types in advance and be proactively thinking of your inputs before you write. You’ll change your coding style in small ways and become a better programmer.
And you’ll (mostly) stop using any
when you spike.
Interested in more software development tips and insights? Visit the development section on our blog!