Data-action is not working in stimulus using with kendoui jQuery

Hi , Actually I am using the Stimulus js with turbo and symfony. With all these I am using the kendo jquery Components and face some problem.
Let me explain this:
Basically Kendo provide the in built components like : grid, table, popup windows etc which we can used for the fast development. In this we can pass the custom html as a template to change the design of the components. But the issue is when I used the stimulus such as data-target, data-action etc in the html that passed to kendo jquery its not working. I am not able to bind the click event with controller’s function.


Sounds like an exciting project. I don’t have a specific answer for you, but I can nod and say, yes, this might be a sticking point that keeps you from integrating the two parts the way you want to.

If you want to bind to specific elements that get hoisted into the page outside of Stimulus or Turbo’s view, then those elements might be invisible to Stimulus, because from its point of view, they didn’t change, and thus they didn’t trigger the mutation observer that would cause them to be registered to the library.

There’s another angle to this as well – when you use jQuery outside of the “modern JS” practice of loading it as a module, it’s almost as though you have two different DOMs in play at once. Stimulus and all of Hotwire are working in “module space”, and jQuery is working in a different, older space, hearkening back to Web2.0 and the bad old days of IE6. You would think that “mutating the DOM” would mean triggering a mutation observer, which would mean that Stimulus could see the changes and react to them, but in my experience, it doesn’t always work that way.

What you may need to do is step back a bit, and register an observer to a greater parent element, and then use to lazily determine if the element that was actually interacted with (i.e.: not the registered parent element, which would be enclosing all such “bound” elements) is one you need to respond to specifically.

I just went through this in another part of the stack, using TurboStreams to replace part of the page, and I found that the less I tried to do myself, and the more I relied on the entire Hotwire stack to just take care of me, the better it worked. I was initially trying to integrate manually created Stimulus behavior with the TurboStreams automatic injection of newly-created elements, and I wasn’t trying to integrate with jQuery, but I was still seeing some form of “element blindness” in that my newly-added parts were not visible to the TurboStream that was trying to clean up the page by removing stale parts. It was only when I stopped trying to do everything myself, and let the TurboStream broadcast do everything from defaults that it started working really well.

Hopefully someone else may have some more specific advice for you about this, and I hope to learn something too if they pipe up. I am currently working on a project where I want to use the new tools, but I have to put up with an ancient carousel widget that is written rather like a love letter to jQuery.


One follow-up to this: jQuery is famously uncaring about the details of HTML construction, and papers over frank errors that would trip up “vanilla” JavaScript. For example, it is perfectly acceptable (to jQuery) to have more than one element in the DOM at the same time with the same ID, and if you construct some effect based on $('#foo_bar'), then all such elements will change. But if you tried to do that with standard JavaScript, only one element would change. This is not a bug. The HTML spec is quite adamant about IDs being page-unique (and thus DOM-unique). Have a look and a think about the actual DOM that your data-grid is constructing. Inspect it in a browser’s dev tools. Check that when it’s fully populated with elements, that the resulting DOM is actually valid HTML. Failures in this area can cause any form of standards-expecting JS to fail or behave unpredictably.