The first of a series of articles about TypeScript
On this page:
- What is a type system?, go to section.
- Why do we use type systems?, go to section.
- Do they replace tests?, go to section.
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 (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.
“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.
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 about
- Helps developers workflow since the very first line
- Is a form of self-documentation
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 code base 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.
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.
Free learning resources
Signup and learn about cutting-edge React and GraphQL plus the latest news on our courses...
Looking to unsubscribe?
Share this on:
This website is built using Gatsbyjs. Curious about how this blog is implemented? It's open source so you can check the source code
Comments? Shoot me a tweet @reactgqlacademy !