-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🚀[FEATURE]: Add option to specify Lifecycle Point to @Action() decorator #488
Comments
I like this idea and have thought about it a few times. We could look at options over the api because I think there are a few ways to go here. |
I like this! Lets blow out the API ideas! |
Just throwing out some question coming in my mind: What are the lifecycle events we want/ when are they called? Is there a way to pass data along from one handler to another? (I guess the action object should be immutable) |
For the API, how about functions similar to the operators for the Action stream: @Action(dispatched([FeedAnimals]))
//...
@Action(cancelled([FeedAnimals]))
//...
@Action(errored([FeedDucks, FeedPigs]))
//...
@Action(successful([FeedAnimals]))
//... What do you think? |
I might be delusional but wouldn't this also help fix the issue #139? |
It would be handy to do s.th. like this:
I am not sure how exactly the API should look like, or whether it would also be useful to add another lifecycle hook for completed. Also, it would be handy to have to result of the Promise / Observable on the action.
I know it is possible to subscribe to the action stream and do this manually and this is just syntactic sugar. However, I feel like this would be a nice addition since for me it is more readable than having subscriptions on the action stream while at the same time reducing Action definitions (e.g. a separate
SyncDatabaseDone
).What do you think?
The text was updated successfully, but these errors were encountered: