Hey folks, I’m working on a new blog and course centered around Stimulus, and one of the things I’m planning to do is address common complaints or gotchas that lead people to reject Stimulus in favor of other solutions (React, Vue, whatever).
Anything you’ve run into or heard people talk about? For example, I stumbled across an old question on a Reddit forum regarding if a Stimulus controller could update/re-render based on changes in other controllers, and the consensus was no, you should just use React for that. Another comment was if you use Javascript to update a field value directly, it doesn’t trigger a bound Stimulus action for some reason, and that was frustrating. (I’m having a hard time believing that is true, but if so, there’s got to be a reasonable workaround…)
Thanks in advance for any ideas!
3 Likes
Sounds like a really interesting project! I have so many thoughts about this, but I don’t have a lot of time for a proper reply today. I’ll give the short version — let me know if you want a follow-up!
One aspect that I think causes some confusion when people start to experiment with Stimulus is when they compare it with component-based frameworks like React and Vue. Stimulus is not an MVC framework by design. It’s a fundamentally different idea. It’s my impression that many people coming from the MVC world are stuck in a “reactive” mindset, and start to treat their controllers like components, which is the wrong level of abstraction and might make them quit early.
When you try to make controllers communicate in a programmatic way, things start to hurt, because Stimulus was designed to be declarative. When Stimulus eventually implements a solution for binding controllers together, it’ll be declared on the element in the DOM. As Sam puts it:
What we want is a way to declaratively link two controllers together in HTML, plus some sort of callback that’s invoked when the link is established and both controllers are initialized.
The method which is responsible for fetching other controller instances programmatically (getControllerForElementAndIdentifier) is in the private API, it’s undocumented and has an intentionally long name to discourage its use. Still, it seems to be used quite a bit.
My hopes are that anti-patterns like using getControllerForElementAndIdentifier will start to fade when the delegated property API is in place.
I don’t think Stimulus was designed to solve immensely complicated front-end problems. It’s designed for applications that need a bit of JavaScript sprinkled on top. People will enjoy it more when they start treating it as such.
Anyway, that’s my two cents. I look forward to reading your blog 
4 Likes
Great thoughts, I appreciate the detailed reply. I’ll have to think more about your stated different between Stimulus controllers and “components” as defined by React, Vue, etc. I agree they’re not exactly the same thing…and yet I find myself conceptualizing similar modular patterns when writing Stimulus controllers. Probably the biggest shift in thinking here is that Stimulus doesn’t place the “system of record” in the world of in-memory Javascript objects and treat the DOM as a render target. Rather the DOM itself is the system of record, and Stimulus just makes it easier to integrate Javascript into DOM-based interactivity.
2 Likes
That’s a great endeavour, thank you!
One quick thing that extends on “stimulus controllers != components”. I like that idea, actually, because it leads to more abstraction to enable controller reuse. One example I have up my sleeve is a “dropzone-controller”. I use it everywhere I need DnD file upload.
However, I find it sometimes really hard to achieve that kind of re-usability because JavaScript just doesn’t provide the same rich metaprogramming abilities as does Ruby.
So I think that’d be an interesting topic - how to really achieve DRYness w/ stimulus controllers…
HTH
3 Likes