Taking Stimulus.js for a ride

Stimulus.js is one of the new front-end framework on the market. It’s goal is to be a modest JavaScript framework for the HTML you already have, which makes it ideal as an alternative to jQuery or framework-less JavaScript. Let’s see how it feels to replace VanillaJS with Stimulus.js on one concrete example.


Remember my article about building a simple visual select with pure JavaScript? I will use the exact same example and rewrite it to Stimulus.js. Here is the original fiddle for comparison. Note that for today article I will drop the ES5 requirement.

Stimulus.js concepts in a nutshell

In Stimulus.js we write controllers with targets and actions that are automatically connected with HTML elements based on good old data attributes. If we want to implement something with Stimulus we have to mark the related DOM as a controller with controller data attribute.

Every element that should trigger an action will have a data attribute action with the format of “event->controller-name#method” and every element that we need to reference will have a data attribute target with the format of “controller-name.targetName”.

In this case the first example from the project’s GitHub will make things clear:

Please refer to the official handbook for details on this philosophy.


For today’s example I will use CDN which shows how easy is to drop Stimulus.js in any project. If your project uses Webpack or Webpacker, follow Webpack installation guide.

To use Stimulus.js from the CDN it’s enough to include the following <script> tag:


I will start converting the original implementation by updating the HTML with data attributes that Stimulus.js uses for references as follows:

First I mark what part of DOM will be the controller responsible for. The controller name will be activity. Then I mark the targets which is the input field, virtual select field and the real select. All of the target names are prepended with the controller name. This enables Stimulus to work with more controllers placed all over the DOM.

After that I need to define an action for the filter input field. “input->” denotes that the action triggers on every input change event (as we type) and “activity#showOrHideOptionButton” denotes the controller and method called.


Once the HTML is ready we can start writing the controller itself. Here is the stub of the controller:

I should mention three important things at this point. First is that we need to define our application and register the controllers. Second, for every controller we need to list the targets that we are using in a static method targets(). That’s a convention. Last, every controller can define connect() method that gets called when the controller is “mounted”. And that’s also where I start with the implementation:

I prepare the virtualSelect, hide the real select and run showOrHideOptionButton that will prepare the clickable links for options. Notice how the targets are actually referenced; always with a “Target” suffix. Then you simply used them as DOM elements as in pure JavaScript.

showOrHideOptionButton implementation is practically same only it’s a controller action rather then function.

addSelectOption differs in a way that we are defining an action data attribute rather than onclick event handler. “click->” part defines the action on click.

Unlike the pure JS implementation enableOrDisableOption action uses the event that gets passed to the action and finding the real target with event.target call. I am also stopping the original click with event.preventDefault() and event.stopImmediatePropagation() which took me a while (see issue #163).

Finally we finish by defining clearFilterSearch action:

Wiring between JavaScript controllers and the HTML is done automatically for you and works perfectly in tandem with Turbolinks which is very appealing to me.


Here is the final JS fiddle implementing visual select in Stimulus.js. Please share your comments if I made some obvious mistakes regarding Stimulus!


Perhaps you also noticed a lot of similarity in the structure of the controller and my previous functional implementation. It doesn’t really feel that different. In this very example it does not even feel like you would need Stimulus.js.

Nevertheless I like its use of a few conventions to standardize simple JavaScript code that would otherwise get unwieldy soon. It’s almost always good to enforce a structure and in case your project does not really warrant a component approach I can only recommend giving Stimulus.js a go. There is also a package repository for Stimulus.js code, so make sure to check it out.

Join the Conversation


  1. Thank you very much for the article. It really shows a clear example of how to start with Stimulus in practice. I work almost exclusively on the back-end, rarely touch HTML/CSS/JS and really found this article helpful.

    You say:
    > in case your project does not really warrant a component approach I can only recommend giving Stimulus.js a go

    Does this mean, that in case we want to use components, Stimulus is not a good choice? This article:


    (and the following parts 2 and 3)

    recommend an approach for organizing different view parts into components (Rails specific stuff) and it is JS framework-agnostic, so I think Stimulus can be useful even with components. What do you think?

    1. Even though it’s not part of the article I also wrote Stimulus.js code that works across controllers so I don’t think it’s impossible. But once you talk about components as a completely separate things that you just “drop” to the page and imagine something more complex where you have a hierarchy of components, then Stimulus.js won’t shine as much as alternatives. I hope we get useful packages for Stimulus.js soon so that we really can just use a simple Rails view and Stimulus :).

Leave a comment

Your email address will not be published. Required fields are marked *