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
// With template literal typesexporttypeAction=|{type: `${string}_REQUEST`;}|{type: `${string}_SUCCESS`;response: string;};exportfunctionreducer(action: Action){if(action.type==='FOO_SUCCESS'){console.log(action.response);}}// WITHOUT template literal typesexporttypeAction2=|{type: 'FOO_REQUEST';}|{type: 'FOO_SUCCESS';response: string;};exportfunctionreducer2(action: Action2){if(action.type==='FOO_SUCCESS'){console.log(action.response);}}
🙁 Actual behavior
In the example with template literal types in the reducer function, it seems like TypeScript is not able to narrow the type of action down, since accessing action.response results in the following error:
Property 'response' does not exist on type 'Action'.
Property 'response' does not exist on type '{ type: `${string}_REQUEST`; }'.(2339)
While in the example without template literal types TypeScript is able to narrow down the type of Action correctly to the one with type: 'FOO_SUCCESS' and correctly recognizes that action.response can be safely accessed as expected.
🙂 Expected behavior
In the example with template literal types I expect TypeScript to be able to narrow the type of action down in the same way as it does in the example without template literal types, and not seeing any errors.
Thanks for your efforts, you found an interesting solution that works. Unfortunately, as soon as I change the string to have multiple underscores (which occurs a lot in our application), an error shows up again:
if (isType(action, 'HELLO_WORLD_SUCCESS')) {
console.log(action.response);
}
However should someone else only have the need to support one underscore, this would be fine.
Also while I feel like while in this example the overhead / added complexity would be acceptable, I wouldn't be so sure if that would still be the case when I would use it in our application where the things are already a lot more complex (since this is just a very minimal example of what we're trying to do).
So I still feel like if this was either easy to add to TypeScript itself so that it could be used natively, as is the case in the example without template literal types, or if this is a bug which is easy to fix it would be much better.
That is right, not a ideal solution, just a workaround.
Yes I think TS compiler should handle this case of narrowing the type depending on the template literal type.
Activity
anuraghazra commentedon Sep 25, 2021
Interesting! This one caught my eye.
I was just playing around with the problem trying to solve it.
Seems like I found a solution by using a type guard
https://tsplay.dev/wgLV9N
martinfrancois commentedon Sep 27, 2021
Hi Anurag Hazra (@anuraghazra)
Thanks for your efforts, you found an interesting solution that works. Unfortunately, as soon as I change the string to have multiple underscores (which occurs a lot in our application), an error shows up again:
However should someone else only have the need to support one underscore, this would be fine.
Also while I feel like while in this example the overhead / added complexity would be acceptable, I wouldn't be so sure if that would still be the case when I would use it in our application where the things are already a lot more complex (since this is just a very minimal example of what we're trying to do).
So I still feel like if this was either easy to add to TypeScript itself so that it could be used natively, as is the case in the example without template literal types, or if this is a bug which is easy to fix it would be much better.
anuraghazra commentedon Sep 27, 2021
That is right, not a ideal solution, just a workaround.
Yes I think TS compiler should handle this case of narrowing the type depending on the template literal type.
Cross fingers 🤞, Hope to see this land in 4.6
martinfrancois commentedon Oct 1, 2021
Thanks Anders Hejlsberg (@ahejlsberg) for the quick implementation!