Enhance type predicates / Enhancing typescripts ability to handle state

[TrevTheDev]

Suggestion

Provide a way to tell the Typescript Compiler that an object's state has changed - enabling Typescript to model state, and state machines well.

🔍 Search Terms

state

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

One solution could be to enhance type predicates to include syntax for instructing the compiler the new type of a variable and all variables sharing its reference after that call, become the new type.
E.g.

const fooBar : Foo|Bar = { ...
   set changeStateToFoo(value:string): fooBar is Foo { ... }
} as Bar
const otherRefToFooBar : Foo|Bar= fooBar  // type is `Bar`
fooBar.changeStateToFoo = 'hello' // after this call fooBar is now type `Foo` otherRefToFooBar  is now also type `Foo`

This is similar to manual reassignment, but would produce more readable and understandable code. A downside is that this could unintuitively mutate the type of a variable causing the code to be harder to reason about- but as it would produce better code than is currently the case, this remains a better solution what is currently available in Typescript.

📃 Motivating Example

The ability to manual change a variable or this type, would significant enhance Typescript's ability to model state and state machines.

Despite this being a fairly typical use case, Typescript current doesn't handle the following code well:

type Bar = {
    type: 'bar'
    changeStateToFoo: string
}
type Foo = {
    type: 'foo'
    sayHello: ()=>void
}

let fooBar = ():Bar=>{
    return {
    type: 'bar',
    set changeStateToFoo(value:string) { 
        delete (fooBar as any).changeStateToFoo;
        (fooBar as unknown as Foo).type = 'foo'; 
        (fooBar as unknown as Foo).sayHello = ()=>console.log(value)
        //fooBar should now change to type `Foo`
        }
    }
}
const fooBarA = fooBar()

fooBarA.changeStateToFoo = 'Hello, Foo' // after this setter, fooBarA should be type `Foo`
fooBarA.sayHello()

Implementing this code in typescript would likely require one of the follow sub optimal solutions:

/**
 * Workaround One: Type Union
 * Con: types become a fuzzy merge of multiple types addressing multiple concerns. Causing incorrect type checking in some cases
 * and requiring superfulous if(exists) checks in other cases. 
 */
type FooBar = {
    type: 'foo'|'bar'
    sayHello?: ()=>void
    changeStateToFoo?: string
}

let fooBarB = fooBar() as FooBar

fooBarB.changeStateToFoo = 'Hello, Foo'
if(fooBarB.sayHello) fooBarB.sayHello() // con: if required!
fooBarB.changeStateToFoo = 'Hello, Bar' // con: still valid - oops! 

or

/**
 * Workaround Two: Manual Reassignment
 * Con: requires arbitrary reassignment and requires writer of this code to know
 *      and manually assign the correct type which may be hard to know or complex.
 */
let fooBarC: Foo|Bar = fooBar()

fooBarC.changeStateToFoo = 'Hello, Foo'
fooBarC = (fooBarC as unknown as Foo) // con: requires superfluous reassignment and requires writer of this code to know
                                      // and manually assign the correct type which may be hard to know or complex for built up generic types.
fooBarC.sayHello()
fooBarB.changeStateToFoo = 'Hello, Bar' // pro: correct type checking!

code

💻 Use Cases

Any code that uses a state machine, or transitions objects between states would significantly benefit from this.

[MartinJohns]

Sounds like a duplicate of #41339.

[RyanCavanaugh]

This is already possible with a slightly different variation

interface FooBar {
    type: 'foo'|'bar'
    sayHello?: ()=>void
    changeStateToFoo(): asserts this is { sayHello(): void }
}

let fooBarB: FooBar = fooBar() as FooBar

fooBarB.changeStateToFoo();
fooBarB.sayHello();

I don't think the principle of modifying one property via a setter and causing spooky action at a distance on other properties in the object is common enough to warrant additional modelling.

[TrevTheDev]

@RyanCavanaugh Thank you for the third work around - it is a valuable addition to the two I proposed. A key downside is that it only allows narrowing - so it doesn't allow for example an unplacedOrder to become a placedOrder (rather than UnplacedOrder & PlacedOrder) or for a placedOrder to revert back to being an unplacedOrder. I.e. like the other workarounds it also doesn't model state well.

I don't agree with your characterisation of property setters as "causing spooky action at a distance on other properties" being not common. It's kinda the point of setters that setting them changes the object and typescript modelling that well would be valuable and make it a better language.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.