Check out this sentence:
Me am eating spaghetti 🍝
You can probably easily identify that the sentence is wrong. And you might even know enough English grammar to explain why.
If not, the short version is that the rules of English grammar create places in sentences for subjects and places for objects. “Me” is grammatically an object while “I” is grammatically a subject. So the problem is that we’ve put an object into a place where subjects are supposed to go in the sentence.
Even with this mistake, our brains are smart enough to figure out what meaning the sentence is conveying. Unfortunately, the TypeScript compiler is not quite as clever, which means we have to be careful about our code or risk spending another day battling Red Squiggly Lines of Doom.
Statements and Expressions in JavaScript
Programming languages also have underlying grammatical rules. And if you’ve written even a small amount of JavaScript, you’ve probably internalised some JavaScript grammar without realising.
For example, can you see what’s wrong with this code?
const flag = isEnabled && !isError() || const result = fetchResult(); // ❌
If you “speak” JavaScript, you probably intuitively recognise that something is wrong here, just as you probably intuitively recognised the incorrect sentence above.
Even the mistake here is roughly similar to “me” versus “I” in English. In this case, we’ve put a statement where only an expression can go.
JavaScript Statements vs Expressions
Statement: A unit of code which provides a whole instruction.
Expression: A bit of code which resolves to a value.
Some people find it easier to think of these as “statements are things you can correctly wrap in curly braces, while expressions are things you can correctly wrap in parentheses”.
For example: { const result = fetchResult(); /* this is a statement / } ( isEnabled && !isError ) / this is an expression */
Of course, the grammar of JavaScript is more complex than just these two elements. But understanding—even without being able to explain!—the difference between statements and expressions is a skill that JavaScript developers tend to pick up quite quickly.
👀 Notice also that expressions can combine together to create more complex expressions.
Both isEnabled and !isError() are themselves simple expressions. We can combine them together using operators such as && to create the expression isEnabled && !isError
Enter TypeScript
Along with statements and expressions, TypeScript adds an extra kind of thing that can appear in our “code sentences”. Unsurprisingly, this new thing is called types and is essential building block of beginner TypeScript.
Now we can open up places in our code where we can add a type:
const result : /* 🫵 TYPE GOES HERE 🫵 */ = fetchResult();
Or:
function computeTotalCost(products : /* 🫵 TYPE GOES HERE 🫵 */)
{ /* function definition */ }
We’re opening up a spot in the code where only a type can go by using the colon (:) operator. There are a couple of other ways to open up these type-places, such as the satisfies operator, but the colon is by far the most common.
These type-places are like a parallel universe—the Land of Types—living in our code. A place where the only thing that is understood is types. If we want to refer to something from the Land of JavaScript, we have to convert it into a type, somehow. For example:
const someVariable = getData();
const result : someVariable /* ❌ NOT A TYPE */;
const result : typeof someVariable /* ✅ WE CONVERTED IT TO A TYPE! */;
The basic rule is that whenever we’re visiting the Land of Types, we can put anything into that type-place… as long as it’s a valid type.
👉 It could be a simple type, like string or Array.
👉 Or it could be a type we’ve defined elsewhere, like Product or User, or one based on the typeof some variable.
👉 It could be an object, like { name: string; email: string; postCount: number; }
👉 Or—like how expressions can combine to create other expressions—it could be a complex type that combines other types, like Product | Error | undefined
💡Defining Things in the Land of Types
This helps to make sense of the type and interface keywords. Just like the colon operator, whenever you use one of these keywords you’re visiting the Land of Types.
Think of these two as the Land of Types equivalent to let and const: Just as let and const define variables in the Land of JavaScript, type and interface define types in the Land of Types.
⚠️ OPINION ALERT ⚠️
When practicing beginner TypeScript, people often worry about type versus interface. Which should you use?!
With let/const there’s a clear winner: CONSTantly use const, LET yourself use let.
But the differences between type and interface are comparatively minor. When starting out, it’s easier not to worry too much. Pick one and stick with it, or mix-and-match—it’s up to you! Once you’ve got more comfortable with TypeScript, you can come back and understand those small differences.
💡 If you’re really struggling to choose, the TypeScript playground recommends you use ‘interface’ to get slightly easier-to-read error messages in some cases.
🤔 Why does this matter?
TypeScript programming is all about declaring your assumptions about what’s happening at that point in the code.
By opening up these type-places in your code, you’re effectively telling TypeScript: “Hey, when I reach this line, I should have an Array of Users – can you make sure that that’s always true?” If TypeScript then spots a way for you to reach that line of code where that assumption ISN’T true – for example, perhaps the data could be undefined – then it will show you an error.
TypeScript errors are famously hard to read, but they’re mostly telling you about these sorts of contradictions: “You’re calling this function with data that might be undefined, but you told me already that that function MUST have this data. Can you resolve that contradiction please?”
Becoming a good TypeScript programmer is all about finding the neatest way to encode your assumptions into those type-places in your code, which enables TypeScript to help you to keep your code bug-free! 💪
Fancy refreshing your JavaScript skills and diving into some beginner TypeScript? We have just the programme if you’re looking to return to tech after a career break. Visit our programme page to learn more!
