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
Is there a way to automatically generate PayloadAction type unions from an AsyncActionCreateBuilder instance to facilitate writing custom epic generic templates
#212
Open
dcs3spp opened this issue
Nov 20, 2019
· 0 comments
Is your feature request related to a real problem or use-case?
I have written a generic epic that accepts an async action as a parameter:
exportconstgenericHandler=<TRequestTypeextendsstring,TSuccessTypeextendsstring,TFailTypeextendsstring,TModel,>(asyncAction: AsyncActionCreatorBuilder<[TRequestType,RequestPayload<TModel>],[TSuccessType,SuccessPayload<TModel>],[TFailType,FailurePayload<TModel>]>,)=>{constepic: Epic<// epic input action types union - manually specifying.....|PayloadAction<TRequestType,RequestPayload<TModel>,>|PayloadAction<TSuccessType,SuccessPayload<TModel>>|PayloadAction<TFailType,FailurePayload<TModel>>,// output action types union - manually specifying|PayloadAction<TRequestType,RequestPayload<TModel>>|PayloadAction<TSuccessType,SuccessPayload<TModel>>|PayloadAction<TFailType,FailurePayload<TModel>>,RootState,Services>=(action$,state$,{ apiService })=>{// some source code ....}
The type of the aysncAction parameter is AsyncActionCreatorBuilder.
In the redux-observable Epic<...> generic I manually specify the PayloadAction types for Input and Output actions in the stream.
Describe a solution including usage in code example
Is there any way to automatically generate the PayloadAction types to reduce complexity?
Is it possible to derive the PayloadAction union types from AsyncActionCreatorBuilder to reduce complexity....
// imports for RequestPayload, SuccessPayload, FailurePayload etc.exportconstcustomEpicCreator_A=<TRequestTypeextendsstring,TSuccessTypeextendsstring,TFailTypeextendsstring,TModel,>(asyncAction: AsyncActionCreatorBuilder<[TRequestType,RequestPayload<TModel>],[TSuccessType,SuccessPayload<TModel>],[TFailType,FailurePayload<TModel>]>,)=>{constepic: Epic<// Payload type union automatically generated for input and output types from AsyncActionCreatorBuilder objectGeneratePayloadActionTypes<asyncAction>,GeneratePayloadActionType<asyncAction>,RootState,Services>=(action$,state$,{ apiService })=>{// some source code ....}exportconstcustomEpicCreator_B=<TRequestTypeextendsstring,TSuccessTypeextendsstring,TFailTypeextendsstring,DifferentRequestObject,DifferentSuccessObject,DifferentFailObject,>(asyncAction: AsyncActionCreatorBuilder<[TRequestType,DifferentRequestObject],[TSuccessType,DifferentSuccessObject],[TFailType,DifferentFailObject]>,)=>{constepic: Epic<// Payload type union automatically generated for input and output types from AsyncActionCreatorBuilder objectGeneratePayloadActionTypes<asyncAction>,GeneratePayloadActionType<asyncAction>,RootState,Services>=(action$,state$,{ apiService })=>{// some source code ....}
Who does this impact? Who is this for?
Typescript users
Describe alternatives you've considered (optional)
I tried using ActionType<typeof asyncAction> but this generates type
Is your feature request related to a real problem or use-case?
I have written a generic epic that accepts an async action as a parameter:
The type of the
aysncAction
parameter isAsyncActionCreatorBuilder
.In the redux-observable Epic<...> generic I manually specify the
PayloadAction
types for Input and Output actions in the stream.Describe a solution including usage in code example
Is there any way to automatically generate the
PayloadAction
types to reduce complexity?Is it possible to derive the PayloadAction union types from AsyncActionCreatorBuilder to reduce complexity....
Who does this impact? Who is this for?
Typescript users
Describe alternatives you've considered (optional)
I tried using
ActionType<typeof asyncAction>
but this generates typeI think this is because I am passing in the parameter type as an
AsyncActionCreatorBuilder
.Additional context (optional)
The text was updated successfully, but these errors were encountered: