-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
RFC Interactor#perform Cycle #291
Comments
Thank you for sketching it. I like the new approach. It solves the issue of rolling back interactors that were never performed #214. But this got me thinking if we can break the cycle into even more smaller states.. something like I have not thought about all the scenarios yet, but that is a quick sketch of the idea. |
@mohameddiaa27 could you clarify how it differs from the proposal? |
I just realized I sketched a wrong flow. I tried to sketch a detailed version of what I had in mind here (Without zooming into the rollback) Now I see that the main difference is how we define a |
@mohameddiaa27 since most of this logic lives in the |
If you'd like to start writing issues to tackle this epic I'd be more than happy to offer feedback on the stories. |
Elevator pitch, describe and sell us your feature request
As a contributor,
I want to refactor the perform cycle of an interactor
so that debugging issues with interactors become easier to manage, and we can further reduce responsibilities of objects in the perform cycle.
Is your feature request related to a problem
Currently the interactor perform cycle is a bit confusing and hard to follow. We also carry the same context object throughout the entire cycle even though it really has 3 states: input, runtime, and output. The current interactor cycle looks like this:
However the code base doesn't really reflect this cycle neatly. In this epic we should revamp the performance cycle to be easier to follow, and reduce the responsibility of the context object even further by instead creating 3 context objects. We will create an context object on input, runtime, and output.
As we can see from the diagram when an interactor calls
.perform
we will:.perform
#perform
#perform
has called!fail
we initiate rollback on the runtime object#perform
is successful we validate the output objectStates
Based on this diagram we can separate concerns into two types of objects and a total of 3 instances. The first type of objects are simply a collection of attributes. This would accurately describe the purpose of the input and output objects. No operations are ever actually performed on these two objects and they can be considered stable or frozen.
The second type of object is more volatile and is meant to be mutated during the
#perform
operation. This would accurately describe the runtime object. It is also never validated. This object should never actually be returned to an end consumer.Object Generation
We should generate the input object with arguments provided to
.new
or.perform
on an instance ofActiveInteractor::Base
, after we run validations that do not specify avalidation_context
and validations that specify theon: :calling
validation_context
we would then use a valid input object to generate our runtime object. Once the#perform
method has completed we would then use the runtime object to generate the output object and run validations on it that specify theon: :called
validation_context
Additional Comments
The code should reflect this diagram as closely as possible to ensure subsequent refactoring and debugging is an easy task.
Issues in this epic
The text was updated successfully, but these errors were encountered: