How should organizers function?

[taylorthurlow]

With the more restrictive interface that interaktors provide over interactors, comes some uncertainty regarding how organizers should be treated.

My thought is to only allow organizers to specify a series of interaktors to organize and nothing more. The attributes that you pass to the organizer would be determined by the first interaktor in the organizer. This seems to fit the ethos of Interactor (per the README, "Its single purpose is to run other interactors.").

There is some uncertainty as far as to which interaktors your attributes apply, when calling the organizer. Additionally, it is not clear how the attributes should be passed between interaktors. In Interactor, the concept of a context is publicly exposed, and because that is no longer the case, it needs to be made clearer how the attributes are passed from one interaktor to the next. It could be possible to use the success attributes of an interaktor as the input attributes (required/optional attributes) of the next interaktor, but this might strong-hand the user into building interaktors which are only useful in the context of the organizer. I'm not sure if this is a good or bad thing.

[blafri]

Hey @taylorthurlow, I think this can be done by separating the concept of input params to an interactor/organizer and the context itself. If I understand properly what you are trying to achieve here with attributes is that you don't want people to be able to dump in a bunch of attributes to the context that just pollute it with crap that will never be used and, also to make sure that the params they enter is everything the interactor/organizer need to complete its work. If something is missing throw an error one time as the interactor will not be able to complete successfully. I think this is great as you can now open the interactor file and just a quick look the code you can determine all the params that the interactor needs to do its work.

In the case with organizers since organizer will take the input params and change them into a context object and then pass the context object to the individual interactors in the organizer we can let that happen with no filtering. The individual interactors will still have the attribute concept but only when supplying them with a hash. if you supply them with a context they just use the context. I think we can do this easily by changing a couple lines.

you currently check the attributes in the execute method here

interaktor/lib/interaktor/callable.rb

Lines 176 to 187 in 9413084

	def execute(context, raise_exception)
	unless context.is_a?(Hash) || context.is_a?(Interaktor::Context)
	raise ArgumentError, "Expected a hash argument when calling the interaktor, got a #{context.class} instead."
	end
	apply_default_optional_attributes(context)
	verify_attribute_presence(context)
	run_method = raise_exception ? :run! : :run
	new(context).tap(&run_method).instance_variable_get(:@context)
	end

I would say instead of checking there to check attributes in the build method for the context

interaktor/lib/interaktor/context.rb

Lines 20 to 22 in 9413084

	def self.build(context = {})
	context.is_a?(Interaktor::Context) ? context : new(context)
	end

we could change it to something like this

return context if context.is_a?(Interaktor::Context)

# check attributes here to make sure everyhting is good if it is not good
# then raise Interaktor::Error::MissingAttributeError if everything is good
# run the following line to build and return a Interaktor::Context object

new(context)

That would allow organizers to work the way they always did and allow for explicit attributes to be passed in. The organizer will be responsible for checking the params hash passed in and the individual interaktors will just do they work. Let me know what you think about this approach and if it makes sense for your project.

[taylorthurlow]

Wow, thanks for taking the time to suggest a solution! I'll take a look at this and how it would fit into the code as soon as I can.

[taylorthurlow]

@blafri Had some time today to go over all this, thanks again for taking the time on a random project like mine.

If I understand properly what you are trying to achieve here with attributes is that you don't want people to be able to dump in a bunch of attributes to the context that just pollute it with crap that will never be used and, also to make sure that the params they enter is everything the interactor/organizer need to complete its work

You nailed this one for sure, I see Interactor's permissiveness as a pretty significant negative in an otherwise useful pattern - I just wanted a little more structure.

I really like your idea regarding de-coupling the context object from the attribute verification. I've implemented it in a slightly different spot, given that Context#build like you have above doesn't have access to the interaktor's attributes. Nonetheless, it was easy to do it in Callable#execute, where it was happening before:

interaktor/lib/interaktor/callable.rb

Lines 176 to 191 in 1363b3c

	def execute(context, raise_exception)
	run_method = raise_exception ? :run! : :run
	case context
	when Hash
	apply_default_optional_attributes(context)
	verify_attribute_presence(context)
	new(context).tap(&run_method).instance_variable_get(:@context)
	when Interaktor::Context
	new(context).tap(&run_method).instance_variable_get(:@context)
	else
	raise ArgumentError,
	"Expected a hash argument when calling the interaktor, got a #{context.class} instead."
	end
	end

I spent a while making some changes to the organizer logic. Interaktors in an organizer will accept required attributes from:

• The required attributes of the the organizer
• The success attributes of any of the interaktors in the same organizer that come before the interaktor with the required attribute

This check will happen when you call the interaktor but before any of the interaktors have run. Optional attributes behave similarly, but there aren't any checks performed. I think this is fine, and I'm still thinking about edge cases, but I don't use many organizers in the projects that I've been using this gem in so I'll have to wait and see I suppose.

If you have any opinions or suggestions, let me know! Otherwise, thanks for giving me another kick start to make more progress on all this 👍

[blafri]

Now seeing context#build does not even have access to the attributes 🤦‍♂️. lol. Sorry about that. Looks like it was easy enough to do in Callable#execute though. Il pull down the changes and try it out in a project I have that uses organizers to see how it works. Should get some time this week or weekend for the latest.