Intersected type variable with a recursive constraint fails to infer #55645

Activity

1. Andarist commented on Sep 8, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 8, 2023

   ContributorAuthor

   More actions

   Perhaps this is a design limitation/working as intended since manual type parameters "suffer" from the same problem in this example:

   // 2nd constraint errors here
   createMachine<"foo" | "bar", { entry: "foo"; states: { a: { entry: "bar"; }; }; }>({
     entry: "foo",
     states: {
       a: {
         entry: "bar",
       },
     },
   });

   I guess it makes sense if we consider type arguments as assignments and the argument itself as a completely separate piece. From that PoV, it doesn't matter that the argument would succeed if we had used the "original" inferred type (available in inference candidates) and let it flow to the parameter type of the instantiated~ signature.
2. RyanCavanaugh commented on Sep 13, 2023

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Sep 13, 2023

   Member

   More actions

   I'd expect TConfig to infer successfully

   What is your definition of success here?
3. Andarist commented on Sep 13, 2023

   

   Mateusz Burzyński (Andarist)

   on Sep 13, 2023

   ContributorAuthor

   More actions

   I expected TConfig to be roughly inferred as the type of the argument. So whatever got gathered here as the inference candidate ({ entry: "foo"; states: { a: { entry: "bar"; }; }; }).

   Based on this late conclusion I don't expect this anymore. Or at least - not with the current model for how type arguments work in regards to this. I find it unfortunate that the final structural check of intersected candidates would succeed in this case and yet the candidate is rejected based on common property check failure against its constraint here. It makes it increasingly challenging to infer a recursive structure like this due to various current limitations.

   In a way, I don't even want to infer TConfig here but I'd love to have a way to "capture" the argument's type as-is. Inference seemed like a great tool for the job (it's definitely a very close approximation of what I want) but it turns off the excess property check and that's immensely useful in my case. I figured out some ways to preserve or mimic excess property check in simpler situations but they don't work for recursive structures like this. They also require workarounds and just add unnecessary complexity to my types.

   Another example of this need would be the queryOptions helper from @tanstack/react-query:

   import { useQuery, queryOptions } from "@tanstack/react-query"; // types: 5.0.0-beta.25
   
   const options = queryOptions({
     queryKey: ["foo"] as const,
     queryFn: () => Promise.resolve(5),
     staleTime: 10 * 1000,
   });
   
   useQuery({
     ...options,
     placeholderData: (previousData) => {
       previousData;
       // ^?
       return previousData;
     },
   });

   This is a helper that is needed~ to infer things within those "partial" options (especially the contextual parameter types between dependent properties). Its result i reusable and is later meant to be spread into useQuery - but since useQuery is also inferring things, it's best to use the narrowest possible type for options. When returning what might be used as the constraint of TOptions there it could return many optional properties that could accidentally be used as inference sources by useQuery. Inferring TOptions here:

   • turns off excess property check (undesirable)
   • breaks intra-expression inference (smth that could be fixed but it has to be challenging if a scenario like this was not fixed in 4.7 when improvements to that were introduced).

   Sorry for somewhat offtopic train of thought :P
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.This issue needs a plan that clarifies the finer details of how it could be implemented.

   on Sep 13, 2023
5. Ryan Cavanaugh (RyanCavanaugh)

   added this to the Backlog milestone on Sep 13, 2023
6. RyanCavanaugh commented on Sep 13, 2023

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Sep 13, 2023

   Member

   More actions

   I don't entirely follow tbh, but I'm open to a well-explained PR if that's what you're saying 😅