You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way useControllers compose is a little unusual with some interesting side effects. I was wondering if calling this behavior out a little more explicitly as it bit me on my hind quarters for more time than I am willing to admit to.
What we've really done is added the controller onto the myTarget element while making the mixed in controller methods available in this controller. Some of the weird, not expected side effects, at least until one gets their heads wrapper around this concept are:
Any values or classes must be on the Target element, not THIS controller's element
You are unable to name scope the values, classes, etc -- because they are the property of the mixed in controller (i.e., data-transition-* Vs. data-myController-*)
This has at least two unfortunate side effect:
it breaks the standard linkage between the controller that's visually responsible for, and holds the code logic for, the functionality from where the data-* attributes live
if you need the same mixin from two different places targeting the same element (i.e., myTarget), it becomes impossible because of the name spacing issue above.
The way I'm working around this issue is to duplicate any of the mixins required data-* attributes under the auspices of my controller (using standard stimulus naming conventions) and then in connect():
The way useControllers compose is a little unusual with some interesting side effects. I was wondering if calling this behavior out a little more explicitly as it bit me on my hind quarters for more time than I am willing to admit to.
When one mixes a controller in:
What we've really done is added the controller onto the myTarget element while making the mixed in controller methods available in this controller. Some of the weird, not expected side effects, at least until one gets their heads wrapper around this concept are:
This has at least two unfortunate side effect:
The way I'm working around this issue is to duplicate any of the mixins required data-* attributes under the auspices of my controller (using standard stimulus naming conventions) and then in connect():
This implementation is not without its own set of problems, but I believe the surface area of those issues is smaller.
The text was updated successfully, but these errors were encountered: