The Value of a Strongly Typed Projects 💪

One the first things you're going to encounter working with TypeScript is this idea that it's prohibitive or it's a lot of setup. I've been there. Then I remember this quote:

TypeScript shines not on day 1, but on on day 100, and becomes a freaking supernova on day 500. -- Jared Palmer

As you start working in a codebase you don't have a lot there. Then add some community types for the libraries you're using; that's one level of productivity, the libraries you're using are now showing where you're using their API wrongly, and that's sort of helpful on a level but we can do better.

Then you have more code and more requirements in your project and those types you're adding accrue by a magnitude. At this point your application has certain models or pieces of UI or concepts that you want to make discernible, like in a chat app you might have a type interface for the message and one for the thread of messages.

interface IMessage {
  content: string;
  attachments: IAttachment[];
  sender: IUser;
  dateSent: Date;
}

interface IThread {
  messages: IMessage[];
  isTyping: boolean;
  pollingInterval: number;
}

Now let's image the IMessage interface changes, your code to add a message or poll for new messages is likely to be broken because of that. Because you introducted this interface and can now see where your application was using, you can see with a small change the impact of that change. That to me this is one of the key values of using strong types and it's not one you see you day one, it's one you see when you're deep into a project and adding new features.

Strongly Typed?

You might've heard people throw around this term "strongly typed" (like I just did), a strongly typed project or a strongly typed language. When I first heard it, I wasn't quite sure what it meant. To answer that we need to define what a "weak" types are; weak types are type annotations that don't break compliation or in some way permissible where by contrast, strongly typed projects or languages fail compliation if a type error exists. Using TypeScript's "strict mode" can be a method for building a strongly typed project.

Anyway, if you're feeling the pain or the tedium of migrating to TypeScript or getting start with it, trust me from experience, it pays off, especially when you get to a point where you have to make bigger refactors in your project or need to build more features, from experience you can do that with my more confidence embracing a strong types in your project.

Wherever you are in your journey with TypeScript, follow me on Twitter @charlespeters or find me at charlespeters.net, I'm working on some resources to help.

Links 📝

These are some seriously cool things I encountered while I was working the last couple of weeks.

• Formik 2 in Hooks: Formik, like React Router or is one of those tools you just grab when you're building a project of any real size. With the latest release, you can now ditch the Render Props pattern for hooks and components and I got the rare chance to role this out on a branch in my current sprint and I couldn't be happier with how much code I got rid and how much easier it was to work with.
• Effective TypeScript: 62 Specific Ways to Improve Your TypeScript: I heard Dan Vanderkam speak at TSConf this year and I am ridiculously excited for the giant company that delivers things quickly to my house, to quickly deliver his book to my house.