data-reflexattribute. The syntax follows Stimulus format:
idattribute on any element that has a
data-reflexattribute on it.
idis unique in a valid DOM, and this is how StimulusReflex locates the controller which called the Reflex after a morph operation.
data-reflex-dataset="combined"directive to scoop all data attributes up the hierarchy and pass them as part of the Reflex payload.
data-idwould be 2.
ApplicationControllerimports the StimulusReflex Controller and calls
StimulusReflex.register(this). As a result,
ApplicationControllerand all Stimulus Controllers that extend it gain a method called
stimulateis extremely flexible
this.stimulate(string target, [DOMElement element], [Object options], ...[JSONObject argument])
stimulatemethod with arguments; there is no equivalent for Reflexes declared with data attributes.
data-reflex-dataset="combined"also works with the
stimulatetreats the DOM element that the controller is placed on as the element parameter. Instead, we use
event.targetto make the clicked button element be the source of the Reflex action. All combined data attributes will be picked up, and all callbacks and events will emit from the button.
before_reflexmethod in your Reflex class, it will be executed before the Reflex action. If you call
raise :abortin the
before_reflexmethod, the Reflex action will not execute. Instead, the client will receive a
haltedevent and execute the
reflexHaltedcallback if it's defined.
stimulatewith no parameters invokes a special global Reflex that allows you to force a re-render of the current state of your application UI. This is the same thing that the user would see if they hit their browser's Refresh button, except without the painfully slow round-trip cycle.
data-reflexattribute. For example, the following button element will refresh the page content every time the user presses it:
data-controller="foo". In the following example, we attach an instance of the Controller class defined in
data-reflexattribute, it adds a Stimulus Controller called
__performaction to the element:
removeReflex action on the
FooReflex class when the user clicks the button. The button is now a Reflex Controller Element, because the StimulusReflex Controller responsible for the Reflex is attached to it. As a result, all life-cycle events will be emitted from it.
fooStimulus controller to the
buttonelement in order to be able to call
FooReflexes. We are not doing it magically in the background, either; there simply doesn't need to be a
fooStimulusReflex Controller on the element in order for a declared Reflex to call
FooReflex#removeon the server.
foo_controller.js, and that's okay.
application_controller.js- which was installed during setup. Any generic Reflex callbacks defined in the
ApplicationControlleritself will be run, but this is usually limited to spinners and other "meta" UI effects.
FooReflex - and removes the
buttonfrom the DOM:
button) that was holding the instance of
foothat was responsible for the Reflex. That includes the life-cycle events that make callbacks possible.
data-controlleron the same element. There's nothing inherently wrong with doing so - in fact, it's a solid go-to strategy for handling callbacks - unless your Reflex does something that results in the Reflex Controller Element being destroyed (think:
innerHTML) or otherwise disconnected from your DOM.
divsafely out of harm's way, we now see the desired console message:
button) without losing your ability to have your StimulusReflex Controller still generating life-cycle events.
foocontroller instance to an element with
fooor it might be
stimulus-reflexdepending on whether a
foo_controller.jsexists, which is an ugly ambiguity