More time coding, less time debugging. Interfaces in TypeScript applications

The goal of this article is to deepen your understanding of what interfaces are, not just how to build them. Building a solid foundation of programming concepts will strengthen you as a developer, better preparing you for interviews and your career

If you've happened to come across an application written in Typescript you've probably ran across something like this...

 interface Person {
  hairColor: string;
  height?: number;
  [prop: string]: any;
}

We call this an interface and they're great because they allow us to define the structure of our objects an input, preventing unwanted properties or methods from creeping into our data. Interfaces do this by checking that the input our code is receiving adheres to the data types we've set inside the interface. This helps our applications to run as expected.

However, if you're like me and never really worked with a strict data types, like those found in Java or C#, programming to interfaces can present a challenge. After all, dynamic languages (duck typing) like JavaScript don't require us to declare data types, which makes them easy to learn. So if programming to strictly typed interfaces can be difficult, why use them at all? Let's explore this idea.

Where do interfaces come from?

Now, while I think it's pretty important to understand the full reasoning behind programming to interfaces, I will briefly summarise it as a) there's a lot to cover, which would it's own post and b) many a greater developers than myself have written said as articles on this very thing. In a nutshell, the language we write in is a set of instructions for our computer to run our applications. These instructions can only be handled between 4 or 8 bytes at a time so declaring which data types are in our code before its compiled does some of the leg work already, allowing the computer optimally perform.

Concatenating two different data types, a string and a number for example, make it more work for our computer; especially if these different data types were actually meant to be of the same type. By declaring our data types as we code, we cut down on the amount of time it takes our computer to read our instructions. This is why strictly typed languages exist.

Why should I use interfaces?

Spending time debugging code or trying solve issues QA has found in your code can be a major headache. For me, the only thing worse than being stuck on a problem, is having a feeling of relief finishing a new feature, only to have to go back and fix a load of bugs in said feature.
If you're in an environment using sprints, the time spent debugging isn't usually considered in the initial estimation to develop said feature. Structuring your code around interfaces will take more time, but that's more time coding allowing you and your team to better estimate new features in the sprint plan.

So I should always use interfaces then?

No, like any language or framework, there's a time and a place for strict typing with JavaScript. If you're working on a smaller project with a two month deadline and no backend, then strict typing will probably just slow you down. While projects like these wont be bug free, unless you've added maintenance into the budget, time isn't on your side here.
However, less time fixing bugs means more time implementing new features so ultimately consider how much time you have vs. how long you think it'll take to yourself and you team to become productive with strict types.

Personal preference is another consideration although you can't build a preference without first trying the alternative. I'll admit that I get frustrated programming to interfaces (this was especially true early on), but they're growing on me the more I use them. Still, strict typing isn't for everyone just like dynamic typing isn't either and that's totally fine. Multiple languages exist for a reason, but I've you haven't tried strict typing yet, I recommend giving it a chance.

Comments

[Marwan El Boussarghini]

Thanks a lot for the article 👏🏽 I didn't know you could actually implement interfaces in TS.
I must reckon I'm not a huge fan of OOP in general since it adds a lot of boilerplate to the code, how often do you interfaces?

[Andrew McKeever]

currently there are several applications utilising TS where I am, most of our interfaces are applied to form input, however there is legacy react components using objects for state handling that are also constructed with interfaces.

[JoelBonetR 🥇]

It's not about how many lines of code you write, it's about code quality so there's OOP to give you a more secure implementation. Tests adds a lot of boilerplate too but with unit tests and end to end test you could ensure your application still works after an update, which leads to less time loss seeking for bugs, more application quality to your customers and more efficient team work...

You can emulate OOP features on JS such interfaces and static typing using Typescript or writing it with Kotlin and compile it to js, this last option i think is best so it leads you to a more maintainable and scalable project.

[Theofanis Despoudis]

The interface declaration for Typescript is:

interface Person {
  hairColor: string;
  height?: number;
  [prop: string]: any;
}

[Andrew McKeever]

thanks for noticing the typo

[Alexey Novikov]

Please, update the title - while JS and TS are very close relatives, in no way JS is a statically typed language. Weak minds can take it seriously.

[Andrew McKeever]

Wasn't my intention as I mention JS was dynamic in the article. However, I think you're right that confusion could be caused.