Adjusting to TypeScript 101

Super Simple Hacks While You’re Figuring Out Your Workflow

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.

1. Put the file in extension `.jsx` or `.js` first

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.

2. Make all the types “any” when spiking and then backfill

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.

3. Get your text editor or IDE to do the work for you

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.

4. Always be linting

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.

5. Relatedly, turn certain lints off when debugging

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.

6. strictNullChecks

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.

7. Remember that Node gives you a perfectly good console

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?

8. Keep the types visible to cross-reference

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.

9. Casting is totally a thing in types

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’);

10. Import your types, don’t create them from scratch

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.

11. Spend some time on a few tricky elements

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”;

12. Don’t worry

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!