After playing with a working version of this and taking it for a bit of a test drive, I had a few notes and bits of feedback regarding theopen questions in the description.

Restricting named targets to the controller element

In the case where there's a custom Stimulus controller on a whole section of the page (maybe a form for example) and it has multiple child elements and callsthis.stimulate(), the idea of potentially only including targets that are children ofcontroller_element makes a lot of sense and might be preferable in some cases.

But in the simpler case of a stand-alone element (like a button withdata-reflex="click->Example#action") thenthe element is the controller and the concept of "only include targets that are child elements of the controller" doesn't make sense. In that case it wouldn't be possible to interact with any potential targets, because they would necessarily be outside ofcontroller_element. Know what I mean?

It really feels like it should be at leastpossible to use named targets that are anywhere on the current page.

Named targets anywhere on the page

If named targets can be anywhere on the page and aren't restricted to being children ofcontroller_element then that creates some other potential issues, like: if the additional data about all named targets on the page is added into every client->server interaction by default would it would probably end up needlessly increasing the wire size in lots of situations where the targets might not even be used/required in a way that doesn't seem preferable.

My thoughts around these questions are coalescing towards the idea that the ability to control whether or not this additional data gets added and what the scope of it should be really wants to be represented by an optional parameter of some kind. Roughly what I'm leaning towards is: by default the additional data about named target elements does not get included. Optionally; data for only the named targets that are children ofcontroller_element can be included by declaring something likeinclude_targets: "controller", or; data about all named targets on the current page can be included with something likeinclude_targets: "page". Either way it feels like it wants to bedeclared. Maybe on the element? Like...

<spandata-reflex-target="whatever"> Target Me!</span><buttondata-reflex="click->Example#action_one"> Not using targets</button><buttondata-reflex="click->Example#action_two"data-include-targets="page"> Targetting!</button><formdata-controller="stimulating"data-include-targets="controller"data-action="submit->stimulating#submit"><inputdata-reflex-target="launchcodes"type="text"/><buttondata-reflex-target="bigredbutton"class="big red"> Boom!</button></from>

Support for multiple targets with the same name

This feels like it would be amazing, but it'll need some changes to how the targets are put together and what the interface for accessing them looks like. Also... there are some interesting questions about calling chainable operations directly on acollection of targets.

I had a quick look and I'm pretty sure that all operations that could feasibly be called on anelement have the optionalselect_all parameter. So... in the case of a collection, if there's an accessor method exposed for something likepost_targets which represents acollection of elements with the same target name... then maybe callingpost_targets.add_css_class(name: "active") could just automatically setselect_all: true when building that operation...? Hmmm... it feels like there's a bit of finesse needed there with regards to the underlying mechanics of it, but I think it can work. It would need theselector argument to be changed to aselector: "[data-reflex-target='<target_name>']" format in that case, but currently it's using xpath when extracting the target data on the client side.

Edit: it works 🎉 👉Matt-Yorkley@428ac77

A side note on simplicity

An interesting part of this change is that by removing the need to specify theselector argument explicitly (because it gets inserted automatically) it means that certain operations don't require any arguments at all... for example, you could write:

button_target.remove

And that translates to a validcable_ready operation which does exactly what you'd expect... 👀

There's a lot of scenarios where the reduction in the total volume of code required to achieve things and the overall increase in the clarity and simplicity of that code is absolutely wild.