-
Notifications
You must be signed in to change notification settings - Fork 92
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
Passing event arguments to guards #39
Comments
I also have some use cases where it would be helpful if the guard received arguments passed to the event. Right now I have a work around but it isn't very clean. From my perspective and use case Proposal 1 seems like a winner. Is this something that is still on the table? |
Definitely, if you want to PR it, we will review it. The codebase is quite stable so it will need adequate tests to accompany any change. |
I take this is dead in the water as of now, would love to have this capability. |
@joegaudet do you want to contribute to it ? |
If you have some guidance as to how to do it, could consider it. |
This would be a great feature, much needed, but here's a workaround for now: Vehicle
def initialize
@condition = nil
@argument = nil
end
state_machine :state, initial: :start do
event :stop do
transition start: :stopped, if: :stoppable?
end
after_transition to: :stopped do |vehicle|
vehicle.handle_stop_event
end
end
def update(event, condition, argument)
@condition = condition
@argument = argument
fire_state_event(event)
end
def stoppable?
@condition
end
def handle_stop_event
do_something(@argument)
end
end Then call it like: vehicle = Vehicle.new
vehicle.update(:stop, true, 'my argument') |
TLDR;
Currently, arguments passed to an event are not passed to the guard, only the model object. I'm wondering if there is a reasoning behind this (i.e. is it poor practice), or if this is something that I could PR?
Rationale
For our subscription model, currently, we have two events
start_trial
andstart_active
. We just found out we needstart_future_active
and the nomenclature was a dead giveaway that we instead need onestart
event with not necessarily deterministic paths through the state machine.I say not necessarily because there is one deterministic case where we want to
start
but we want to force it to skip the trial (trial is the default start behavior). In looking at this, I've found that a guard cannot inspect the arguments passed to an event, and that seems like exactly what we need. For example:Details
Relevant existing code
event.rb
Existing implementation that needs refactored
With PR proposal 1
This would appear to be simple to implement based on the code involved:
With PR proposal 2
This would require more significant changes, but still not too much. The transition would be initialized first then passed to the guard:
Conclusion
@seuros - do you think this is a good addition? Is there an argument against allowing this?
/cc @bmcdaniel11
The text was updated successfully, but these errors were encountered: