Repository navigation
Probable bug: Contextual inference does not work in "object-like" scenariosΒ #44999
Description
Bug Report
π Search Terms
Contextual inference
π Version & Regression Information
tested with 4.4.0-beta
β― Playground Link
π» Code
createMachine({
context: { foo: 1 },
entry: {
type: "xstate.assign",
exec: c => ({ foo: c.foo + 1 })
}
})
createMachine({
context: { foo: 1 },
entry: assign(c => ({ foo: c.foo + 1 })) // c is unknown but should be { foo: number } instead
})
declare const createMachine: <C>(defintion: Machine<C>) => {}
type Machine<C> = {
context: C,
entry: {
type: string,
exec: (context: C) => unknown
}
}
declare const assign: <C>(f: (context: C) => C) =>
{ type: "xstate.assign", exec: (context: C) => C }π Actual behavior
assign infers type parameter C as unknown
π Expected behavior
assign should infer type parameter C as { foo: number }
Filing as Ryan said here. Fwiw I think a more minimal repro would be this.
Activity
devanshj commentedon Jul 17, 2021
Ryan Cavanaugh (@RyanCavanaugh) I remember you said "I knew it'd be interesting (usually implies time-consuming, but not this time)" so is this a trivial fix? Because if so and if possible I'd love to have this in 4.4 or maybe the next milestone (this directly impacts the xstate types I'm working on at this very moment and the workaround I use is pretty nasty). Thanks!
ahejlsberg commentedon Jul 20, 2021
Yeah, this is a tricky one, and effectively a design limitation. The issue is captured in this comment in
resolveCallExpression:The comment also explains why your workaround works--adding a call signature to the return type of
assigncauses us to defer processing of the inner call.devanshj commentedon Jul 20, 2021
Thanks a lot for your answer Anders Hejlsberg (@ahejlsberg)! Yeah I totally understand TypeScript's problem and even agree that the heuristic it applies is a good one (xstate just happens to have some very corner case scenarios), heck that's what made me come up with the workaround because intuitively I knew what's going on haha.
Though if I were to make a critic, I think the foundational problem is TypeScript (to put it naively) doesn't leverage or understand that some functions are essentially "sugars", it can be very easily identified if I write assign as
<F>(f: F) => { type: "xstate.assign", exec: F }. The fact that inliningassigncompiles says that compiler doesn't really understand fully thatassignis essentially just a sugar. I also lay this out in depth in #45035 (I would LOVE it you can share your thoughts on it, it's a little messy in the beginning because I couldn't point my finger on it but later in the comments it's clear).It would be cool if TypeScript perhaps uses some heuristic to identity sugar-like functions, or if I were to propose a solution it would be that TypeScript provides a type that allows the user to mark an inference site to be of lesser priority so that we can type assign like
<F>(f: LowInfer<F>) => { type: "xstate.assign", exec: F }. (It's important that it'sLowInferand notNoInferI'll add a comment in #45035 (edit: here you go) to point out how it's different)Thanks again for your time!
Andarist commentedon Feb 23, 2022
Anders Hejlsberg (@ahejlsberg) being able to inform TS, even "manually", with some kind of annotation which path do we want to take here would be super lovely for some libraries (like XState π ). This would be a powerful tool for library authors.
I'm slightly unsure how to treat this issue now because it has been classified as a Design Limitation but it has not been closed. Is this something that is still under consideration but perhaps it has a super low priority? I just wonder if you might ever revisit this kind of thing.
RyanCavanaugh commentedon Feb 23, 2022
We haven't updated the automation to automatically close these. Anything classed this way is in an indefinite "hope we can figure it out eventually!" state; things are revisited naturally as people continue to encounter them.