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
It would be really handy if methods decorated with @dispatch() decorator could be async methods (return a Promise). It would allow to use RxJS pipelines (with .toPromise()), or use various dialogs or after effects and whatever one would imagine.
The implementation would be pretty trivial and wouldn't touch the actual dispatcher, just the decorator. The result would be checked for being a promise (simple instanceof could be used, however to make it compatible with bluebird and similar, a more complex check should be used). If it's not a promise, continue with what is done at the moment, otherwise execute current behavior inside the .then callback.
If you guys have not much time to take care of that task, I could do it myself and make a PR, just want to know what you think of that and eventually agree on the specs.
My proposal would only modify the wrapped function and is as follows (untested, if you spot an error do let me know, I will test it before PR though):
I'd appreciate any feedback on this, should I PR it? Or would it not even be merged? Is this concept good enough, or should I make it different? Seriously the 3 weeks of total silence on this issue makes me believe this project is more dead than alive and pushes me towards competitors like ngrx. I am sure I am not the only one feeling so...
This is a...
It would be really handy if methods decorated with
@dispatch()
decorator could beasync
methods (return a Promise). It would allow to use RxJS pipelines (with.toPromise()
), or use various dialogs or after effects and whatever one would imagine.The implementation would be pretty trivial and wouldn't touch the actual dispatcher, just the decorator. The
result
would be checked for being a promise (simpleinstanceof
could be used, however to make it compatible with bluebird and similar, a more complex check should be used). If it's not a promise, continue with what is done at the moment, otherwise execute current behavior inside the.then
callback.If you guys have not much time to take care of that task, I could do it myself and make a PR, just want to know what you think of that and eventually agree on the specs.
My proposal would only modify the
wrapped
function and is as follows (untested, if you spot an error do let me know, I will test it before PR though):And the usage:
So, any thoughts on that?
The text was updated successfully, but these errors were encountered: