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.