You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
discriminated union, discriminated union with an optional discriminator, type inference in objects
🕗 Version & Regression Information
I have a simple piece of code (see the playground/below)
The runtime flow is very simple: whatever gets returned by the loader func gets passed as data to the handle's crumbBuilder method. If the loader is absent then data will also be absent
But when it comes to typing those behaviors then 2 issues arise:
At first, the discriminated union is not being resolved properly: in the second case it should be a string but TS cannot infer it and defaults to any
At second, we still have to explicitly annotate or assert the data type, however from the loader definition it is possible to infer its return type. Is there a syntax way to say 'the type of data is the whatever awaited type the loader function returns?. I have tried to achieve that behaviour using generics and the satisifies` keyword but failed to
typePathSegment=object[];typeHandle<TData>={crumbBuilder: (data: TData)=>PathSegment[];}typeLoader<TData>=(args: {params: Record<string,string>})=>Promise<TData>;typeRouteHandler<TData=any>=|{handle: Handle<never>;loader?: never;}|{handle: Handle<TData>;loader: Loader<TData>};constrouteHandlerWithoutLoader={handle: {crumbBuilder: (data)=>[],//data is correctly inferred as never}}satisfiesRouteHandlerconstrouteHandler={loader: async(args)=>{returnargs.params.userId;},handle: {crumbBuilder: (data)=>[]//data is not inferred as string}}satisfiesRouteHandler<string>
🙁 Actual behavior
data is not inferred as string
🙂 Expected behavior
data should be inferred as a string
there is no need to explicitly annotate or assert the data type , and it must be inferred from the loader return type
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered:
According to discriminateContextualTypeByObjectMembers the function expression used for the loader isn't possibly a discriminant value. So it's not discriminated based on that. When it comes to the optional property in the contextual type... the type is discriminated based on that only when your node doesn't have that property - but you have the loader property.
🔎 Search Terms
discriminated union, discriminated union with an optional discriminator, type inference in objects
🕗 Version & Regression Information
I have a simple piece of code (see the playground/below)
The runtime flow is very simple: whatever gets returned by the loader func gets passed as
data
to thehandle
'scrumbBuilder
method. If the loader is absent thendata
will also be absentBut when it comes to typing those behaviors then 2 issues arise:
any
data
type, however from theloader
definition it is possible to infer its return type. Is there a syntax way to say 'the type of data is the whatever awaited type the loader function returns?. I have tried to achieve that behaviour using generics and the
satisifies` keyword but failed to⏯ Playground Link
https://www.typescriptlang.org/play/?#code/C4TwDgpgBACghsAFgZQgcwLYQHbCgXigHsAjAKwgGNgBtAXQG4BYAKFdEigAk5sATADYQAPABUAIgjgA+AlADerKMqiUATgFcMJAEIaAlgL4Q1ALigAKPlPMSpASgKz4SVJhy1GrAL6t24aAAZIjhjNTFJYBk5Czg1NABnc3koMDi4DCSoACUqIjU+YQTgNX1sNAAaKGLS8tlvR3xnNSIMfQSROyjpZjYWDmhsog1gCB5+IXCuuDleEFl8JRUAHwUllRVEXkEIc3Gd4WwIADcTHvWNqAEQsIB+cyPTtV6N3xYN1cV3y+Utid3uNshBEpOdvj9rqETOZglCppEZBdvL1WJQiNhilAWiMxkCTAB1fRIYbAWFhORfDZ-HbJC4bdRaXQGIzQyzWKKNWT0KoAeh57Jm7VU+TUVGAAhAUDKADMTKK+FA4AkoI8TEifNUEO1pfoIMqhjj9pM-Cw0Ri8NjRkaTBSLpCwuYlSBsJRLHFEpy1uDLqLgBo1NhFfEEgA6NJqDKhjQdNQAST4LxU3gqF2pQlp3vpmm0ekMDrZDicUHoUD5AqlyuwRDwMrlEAVSuqJTKaHVLG8muA2t1+pJuP+4RqLekQA
💻 Code
🙁 Actual behavior
data
is not inferred as string🙂 Expected behavior
data should be inferred as a string
there is no need to explicitly annotate or assert the
data
type , and it must be inferred from the loader return typeAdditional information about the issue
No response
The text was updated successfully, but these errors were encountered: