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.