Typescript Support not working with Async-Stack #353
-
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
Looks like it's working if I add a variant to the stack, but not if it's a "custom" StackItem. Is there any trick to get it working as I do not want to define all dialogs I have in my application and would like to call them dynamically? |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so I just went ahead and defined all my application dialogs, to get the typings right, it has some minor performance impacts, because the application is now loading all dialogs beforehand, but the bigger problem is, that HMR is breaking, because some dialogs are themselves referencing the dialog-stack and opening other dialogs, which causes HMR to detect a circular dependency and break. I think the easiest way would be to get the actual return value type for a custom component, is this somehow possible, maybe even with a wrapper function? |
Beta Was this translation helpful? Give feedback.


Hi @lecramr, apologies for the late response. Defining variants will indeed create overhead and often targeted for use cases where multiple variants reuse the same components, e.g. notification toast. For dialog / modal, I recommend sticking with
custompush.I just pushed a patch that should improve the type inference for custom push, available in async-stack@1.0.1. Please give it another go and let me know if that helps. FYI typescript may yield misleading error about the variant until you have passed in the necessary props for the custom-pushed component.
The inference wasn't working previously because dts-buddy didn't seem to be able to output the correct type for the overloaded metho…