A TypeScript tale - Episode I
The first of a series of articles about TypeScript.
Anyone learning programming for the first time will have to understand types early on. They are everywhere. After all, every value has a type. And what would it be a programming language without a value?
Apart from being a Software Engineer at Sainsbury’s Tech(UK), I’m also a coach at React GraphQL Academy
, where we teach professional developers from all over the world. Often we do an introduction to TypeScript
and many of our students end up making several questions that go beyond TypeScript and into a more general realm. And that’s the reason I thought about writing more in-depth materials for everyone. I could have gone straight to more advanced topics such as design patterns but I found it important to dig into the TypeScript fundamentals. Not that I’m going to write a dissertation about primitive types. For that, you’ve got the official TypeScript
documentation plus many other resources. But I’ll touch the subjects I find important for you to get off to a good start with the language.
What is a type system?
“A type is a syntactic method for enforcing levels of abstraction in programs. The study of type systems, and of programming languages from a type-theoretic perspective, has important applications in software engineering, language design, high-performance compilers, and security.” Benjamin C. Pierce
A type system is a set of rules that add a type property to many of the building blocks of a programming language such as expressions and variables. Its main goal is bug prevention in the codebase by expressing type errors at compile time.
Why do we use type systems?
I’m not going to try to convince you to use a type system. My feeling is that if you’ve read until this point, you’re thinking about it already or, at least, considering it.
A type system, opposite of what some might think, doesn’t keep you entirely safe from trouble. It doesn’t make you immune from making errors. However, it gives you more confidence in your code. Being explicit about your intentions when writing code, not only, increases your confidence, but also has the following advantages:
Makes your code easier to understand and reason aboutHelps developers workflow since the very first lineIs a form of self-documentation
Do they replace tests?
Not at all. For years we’ve been using (and very well) Mike Cohn’s Agile Testing Pyramid as a concept for Agile development teams. In a nutshell, this method allows projects to grow with confidence and minimise technical debt.
Mike Cohn’s Agile Testing Pyramid
But in 2018, Kent C. Dodds came up with a new representation of the classic pyramid where static types are at the base of it. It’s called “The Testing Trophy”.
Kent C. Dodds Testing Trophy
“Catch typos and type errors as you write the code.” Kent C. Dodds
A new layer was added to the traditional method. A new category of testing that spares the burden of writing verbose and inefficient unit tests that could be caught with a type system. The Testing Trophy challenged a set of rules that might not apply anymore to modern development techniques.
And what does Test Driven Development has in common with static typing? The fact that we must plan ahead. What arguments will this function accept? What will it return? Automating this whole process means you will have a better understanding of the codebase and a better basis for future features and possible refactors.
Two of the options are flow and typescript. Whilst both of them have their own buzz within the community, they are actually pretty different.
(guess who created it? Microsoft.) making it sometimes a life-saver with its intuitive integration.
I don’t want to say too much more about TypeScript in this introduction; there are lots of articles already about the history and development of TypeScript. I’d rather follow up with a series of practical guides on how to use it. Hope I see you soon.
Subscribe to get your daily round-up of top tech stories!