I have a sample application and I want to trigger a stimulus method controller upon some DOM changes.
Those changes are sent from the backend with action-cable after_save { broadcast_replace_later_to :exchanges }
On the frontend I have #views/exchanges/index.html.erb
the changes on backend are successfully streamed to the view but Im trying to make my stimulus controller aware of it and react to those changes in a callback #javascript/controllers/hello_controller.js
import { Controller } from "stimulus"
export default class extends Controller {
static values = { index: Number }
static targets = [ "slide" ]
connect() {
console.log("connect called")
}
initialize() {
console.log("initialize called")
}
indexValueChanged() {
//THIS does not get called after changes on the data-hello-index-value
console.log("indexValueChanged called")
}
}
My hope was DOM changes could trigger indexValueChanged on my stimulus controller and I could implement some sort of animation from there but for some reason the ValueChanged callback doesnt get triggered.
Maybe I have misunderstood the purpose of the value properties api. But any clarification on this will be appreciated.
@tleish As I see it, listening for DOM changes seems like an obvious basic use case. Having to write mutation observer code feels less like extending Stimulus and more like a step away from rolling my own framework. It’s undocumented and seems like a departure from the rest of the concepts, which are simple both in syntax and implementation. I see people confused about this almost as much as the link_to/button_to mix-up (a common issues sticky thread might not be a bad idea, come to think of it).
ty for your response.
I saw stimulus uses mutation observes to implement the valueChanged callbacks so I thought any changes to the observed values would trigger the callback, something similiar to a 2-way-databinding and it seems not to be the case.
Thanks for the links I will take a look and see if I can come up with a solution based on that.
@strobilomyces I can certainly understand some of the frustration.
Some frameworks out there have javascript methods to cover any and all scenarios. The tradeoff being those frameworks are larger. For me, the small stimulus library is one of it’s strenghts.
I personally like the ability to only use and customize mutationObservers in some controllers. In 25+ stimulus controllers for one project we have, only 5 need a mutationObserver. I feel concerned a global stimulus observeMutation feature could result in poor performance on large pages.
@tleish I don’t feel like the code would be a particularly large addition to the framework for the functionality it offers. I could see this being a non-trivial sticking point for people who maybe aren’t so versed in Javascript/Typescript, yet are capable of learning Stimulus on its own. Viewing some of the comments on this forum, people seem to have their hands full enough with the basic concepts without having to deal with something like this.
As for performance, I see your point. Maybe it could be invoked rather than enabled by default.
In any event, something should be documented on this
So I have 2 possible solutions: create the controllers on children div and adapt my controller logic or create a custom observer to serve as a bridge between the controller and the data changes from the back-end.
I think I will try the first one as it seems simpler RN
Thanks everyone.
