TypeScript at One Year: How I Learned to Love Front-End Development
I’ve worked heavily with TypeScript over my first year coding professionally and my entire experience has been colored by my happy foray into typed languages. My first job out of code school has been at AdHawk, on a dev team of 5 (including me) with one designer. Over the past year I’ve learned an enormous amount about the wild west of JavaScript, and yet have only begun to scrape the surface of what’s out there. At the Turing School of Software & Design (which I attended back in 2015–16), I learned vanilla JavaScript and basic object-oriented programming, with a more solid foundation in OOP gained primarily through Ruby on Rails. At AdHawk, we use TypeScript, a statically typed superset of JavaScript created by Microsoft that makes JavaScript a true pleasure to write and maintain. I’ve worked with this React/Redux/TypeScript stack as my primary toolset for front-end work, consuming a Rails API we also build internally.
Oftentimes, particularly in my first professional role in software, I feel quite a bit of imposter syndrome, compounded by the fact that I work remotely, from home in Denver, for a New York-based startup. TypeScript has alleviated an immense amount of stress from me through the magic of static type-checking and writing error-free code. When I’m often pressed for time and stuck on a bug that I have no patience or clue how to tackle, the TypeScript compiler swoops in and pinpoints my typos and simple coding errors, warning about them live as I type throughout my codebase. I often feel like I’m pairing with a machine, a boon that I can’t understate in a remote job as someone newer to the field of programming.
Static Code Analysis Catches Your Stupid Human Errors
Static analysis of my code has corrected countless errors and given me insight into the endless series (RE: hundreds) of dependencies and modules we use in our complex applications, as well as insight into our frameworks. In the below example, we have a simple view for our admins in our internal business application called Sledge, which I primarily manage and develop for in my daily work and which supports our business teams.
Our app is a React/Redux/TypeScript front end with a Ruby on Rails back end, and particularly with Redux I faced challenges early on learning how to manage our app’s state via their paradigm, which in this case uses an “Action Creator” to gather all admins from the back-end API. In this case there’s a clear interface for props in this React component which expects all dispatch props to include `getAllAdmins` as a prop available. By my making the simple typo of `getAllAdmin` which just misses the plural ‘s’, the compiler immediately catches my error and tells me where it is, underlines it in red, and gives an obvious error for me to know what to fix.
TypeScript Schemas Give You Wings (Like Red Bull, Without the Insomnia)
TypeScript is built on schemas like the one below for one admin, all stored in simple ‘.ts’ extensions files. The AdminBase is the core schema we use, with almost the same exact format as the admin would have in our postgres database from our Rails API, with an ID, email, access_token and more. We store all of our various admin-related schemas in Admin.ts shown below, which includes schemas for the basic AdminBase, a single Admin (used for our logged in Admin/the current session’s user), a collection of Admins (for our various endpoint response from our Rails API) and an AdminCreate for when we do a post request to create a new Admin when we onboard a new Account Manager or other internal user at AdHawk.
With these schemas, anywhere where I write a function that uses an admin or related schema listed, I know what attributes I have available to me and how I can parse various objects as they change. Throughout my codebase as an object is used in functions and other places I can expect to receive data of specific types. With React where we’re often breaking components down into smaller pieces, if I pass down a function prop using an admin-schema argument, I can detect errors instantly via the compiler if the function is receiving the wrong data when used in the child component. If any one piece of the puzzle falls out of place, the compiler will point to all places that need help or additional work.
TypeScript Makes Refactoring Easy
TypeScript allows me to write functions and build views much more quickly than I would otherwise given the inherent errors in a typical code-writing loop where we write, find errors, and refactor. Below, we wrote a quick function to find admins by their id for our comments view in our app Sledge, in order to both display the admin writing a comment in the footer of a panel. This function takes an admin ID as a string, and an array of included admins, and finds the matching one via Lodash’s find function.
If we pass the wrong prop (in this case a comment list prop with the schema listed below), a common error where I forget to pass the proper exact prop, the compiler immediately tells us it expects an array of AdminBase schema objects, which both tells me what’s missing and what form of data I should be sending. It’s almost like having documentation via schemas and the compiler for every specific part of our codebase, data models, relationships, and the exact problem I’m experiencing when I’m experiencing it. In this case I know to quickly consult the CommentListProps schema below and see that I just needed to change `props.comments` to `props.comments.included` and the error goes away.
TypeScript: Puts the Super in Superset
While TypeScript can seem annoying and overbearing at first via the compiler and the Microsoft Word-esque spell-checking error underlining, once you get in the habit of using clear schemas and quickly are able to correct errors the absence of red errors gives you incredible momentum over the course of a typical day of front end code. I find myself much less confused and stuck on small bugs with TypeScript. While I could write much more about how TypeScript works, what the editor integration has been like with Visual Studio Code, and more, these are some of my initial high-level insights. I’d highly encourage checking out Microsoft’s TypeScript documentation which is excellent and thorough. As you implement TypeScript too, realize that all modern JavaScript is valid TypeScript and you shouldn’t need to change a line of code to implement it.
One final note — TypeScript also helps us avoid a lot of unnecessary testing and provides a lot of the benefits one might see from for example model testing in Rails or other simple validations. It makes front-end testing, which can be notoriously complicated and overdone at times, a much smoother journey. While static type checking will never change how the code runs when starting up the server and checking your app’s features and usability in a development environment, it is always on the lookout to warn you as you’re writing code and before shipping. We even use the TypeScript compiler as part of our continuous integration workflow, and we don’t allow code to pass CI and merge into production without the compiler giving no errors. At AdHawk, overall TypeScript has been the highlight of my experience as a software developer so far and a great foundation for codebase. I look forward to learning more about TypeScript over the coming years.
