Modern Full-Stack Development

 A Quick Detour: TypeScript-Type Assertions
As in many object-oriented languages, typecasting is sometimes necessary. Typecasting, 
in general terms, is when you assign a value of one type to a variable declared as another. 
That will sound weird if you’ve never seen it before, but in terms of object-oriented 
languages, it makes sense.
Imagine you define a class called Shape. You then define a class called Circle 
that extends from Shape. Object orientation tells us that all Circle instances are 
also Shape instances due to that inheritance relationship. Therefore, you can have a 
variable declared as type Shape that points to an object of type Circle. There’s a bit 
more to casting in some cases, but for our purposes here, this is enough to give you 
the basic idea.
Casting isn’t purely about objects and classes, though. You can also type primitive 
types. For example, in most languages, a variable of type double can reference an int 
value because a double can fully contain the value of an int.
In TypeScript, these situations are called type “assertions,” but it essentially means 
the same as casting. It’s a purely compile-time mechanism as it has no effect at runtime 
(it does no special type checking or data restructuring or anything like that), and it’s a 
way for you as the programmer to tell the compiler “look, I know more about this type 
than you do, so trust me, this is what it is.” That is sometimes necessary because as good 
as tsc is, it can’t always determine the type of a reference, and sometimes it’s tricky for 
you to be able to tell it.
Such is the case with this layout property. The first problem is that because this is 
part of an object literal definition, which means that the colon is already used to separate 
the property name from its value, there’s no way to attach a type. In other words, this 
won’t work:
layout: number[][][] : []
Chapter 11   time for fun: BattleJong, the Client

---

332
It will yield a compiler error due to the ambiguous meaning of the two colons. So, 
from a purely syntactical point of view, we need something else. That’s where the angle 
brackets placed before the value comes in. This says to tsc: “this value is of the specified 
type, whether you know it or not!” Here, you know that the layout passed from the server 
is a three-dimensional array of numbers, so we need to express the same type here.
The other problem is that in this case, TypeScript has no way to know what the type 
of the value is. Without the cast, all it knows is that it’s an array, but it doesn’t know what 
the elements of the array are. Yes, we could, in theory, define it as any[][][], but we’d 
still need the cast syntax due to this being a property in an object literal.
Note that there is a second form of casting in TypeScript: using the as keyword. This 
line could have been written:
layout : [] as number[][][]
There’s no technical difference between the two forms – they mean the same thing – 
so it’s a matter of preference. However, note that in a .tsx file, you must use the as 
keyword because the angle bracket approach can yield syntax errors in JSX when used 
with TypeScript.
Note  as a general statement, it seems that most typeScript developers have 
taken to favoring the as keyword approach. i’m an old Java guy, so my brain 
automatically goes to angle brackets. the bottom line is that it’s up to you, but you 
may be more in line with most other typeScript developers by sticking with the as 
keyword approach.