Having considered porting a lot of code from saga to listeners, I've noticed that I am reaching for the same pattern which is a bit verbose in order to have deeply nested forking:
When in reality, the ForkedTaskApi could just include things from the parent, like getState(), dispatch(), and fork(). Not only would this make the code easier to read api.fork(doAnotherThing)), but it would also mean the type API for both the fork and the task is the same.
Having considered porting a lot of code from saga to listeners, I've noticed that I am reaching for the same pattern which is a bit verbose in order to have deeply nested forking:
Example:
When in reality, the
ForkedTaskApi
could just include things from the parent, likegetState()
,dispatch()
, andfork()
. Not only would this make the code easier to readapi.fork(doAnotherThing))
, but it would also mean the type API for both the fork and the task is the same.