This is some nice syntactic sugar.

I'm curious as to whether or not to_operation is necessary? Don't we have enough information if an object provides to_html and to_dom_id or to_dom_selector?

If we do need/want to keep it, I propose that we rename to to_operation_options or something a bit more pedantically explicit.

I'm open to and excited to see other ways of achieving the same end result, but I don't see how we can get to the same outcome through inference alone. The reason is simple: we don't know what options each operation needs; some want text and others want message. Even if we did have a mapping (which is impossible due to custom operations) providing a to_operation (or to_operation_options) gives the developer explicit control over which options are passed.

Consider this: depending on the internal state of an object, it might only want to provide a selector value in certain circumstances. The array result could be dynamically constructed to include or exclude :selector.

I'm generally not wild about making names longer than they need to be (would to_options suffice?) but there wouldn't be any argument, here: if we keep it, you'll tell me what the method name will be and I'll update all of the places. It actually started as to_cable and it's an easy change.

I'm a little fuzzy on the edge cases here… What if you want to pass the object for several different types of operations? Wouldn't each operation need a different list of parameters?

So maybe do something like params_for_operation(operation_name) and you could write a case…when or whatever to handle multiple operations, whether that's :inner_html or :text_content or whatever.

🙀

Sorry to keep you on the edge of your seat, I've been on the go, today. 🚄

I really don't want to over-engineer this PR. Even to_operation (or whatever it becomes) is a rare example of maximalism in a library that has traditionally been low fat, low carb. I'm just a sucker for making things short and magical when possible.

It is true that if you want a given object to be able to be passed to multiple types of operation - something you can't even remotely do in today's CR and wasn't even on the horizon until this PR - you'll need to have to_xxx methods defined for the options you need. If this breaks down because you need an object to behave differently depending on the operation it's being passed to, then the correct thing to do is to just pass in keyword parameters, like you already do today.

After all, if we implement some kind of lookup structure eg. params_for_operation(operation_name) then the next stop on the slippery slope is going to be "but my inner_html operations need different options depending on the context in which they are called in, like different controllers or Reflexes". It seems as though the path to hell is paved with good intentions here, doesn't it?

I already think that inner_html(selector: object, html: object) is seriously cool and a huge improvement on the status quo.

If you have an object with complex utility, it seems like to_operation might just be too magical. However, many objects will fit into the patterns proposed by this PR like a hand in glove.

I'd humbly suggest leaving out to_operation this go around…like you said, just being able to hand the obj off to the keyword args seems way cool. Beyond that it maybe gets more murky/confusing…

It's 100% opt-in - you don't have to define to_operation if you don't want this functionality.

Could you go into a bit more detail on the edge cases that you're concerned about? I'm really excited to use this...

@leastbad this looks really great! to_operations does take a minute to grok but is a really powerful way to give models full control of their destiny. I think it's worth going for even if not everyone feels comfortable using it. Like you said, it's optional and the keyword method will be a great choice too!

I'd like to also support a more explicit Hash return value for to_operation as well.

I also propose renaming this method to to_operation_payload given that an "operation" is really the combination of an identifier + payload.

# lets keep this shorthand syntactic sugar
def to_html
  "<p>neato</p>"
end

def to_dom_id
  "example"
end

def to_selector
  "#" + to_dom_id
end

def to_operation_payload
  [:html, :dom_id]
end

# but also support returning an explicit hash
def to_operation_payload
  {    
    dom_id: "example",
    selector: "#example",
    html: "<p>neato</p>",
 }
end