It's not always obvious when creating abstractions – such as Typescript – that the language can create pitfalls that weren't originally there. Take this code for example:
export enum Status {
Disconnected,
Connected,
Ready,
Downloading,
Error
}
export default class Downloader {
public status: Status
constructor() {
this.status = Status.Connected
}
}
You would assume that a Developer would write the following and it would work as intended.
const downloader = new Downloader()
let workingStatus = downloader.status in [Status.Disconnected, Status.Error]
But you would be wrong. Don't worry if you don't spot the error right away.
Enum's resolve down to Integers after being compiled, and the above implimentation can be re-written as
let workingStatus = 1 in [0, 4]
workingStatus // True
Where 1
is the index 1
is present in the array... Yea.
Again, probably a symptom of not testing thoroughly enough if you miss the error when programming.
I'm probably still of the opinion that the in
operator should never test for index location. A very strange behaviour indeed.
Why it's important to learn Javascript before Typescript
And why it's always important to not be afraid to learn the underlying stack.