I immediately like the ethos of Stimulus.
We don’t always need a nuclear solution that:
- takes over our whole front end;
- renders entire, otherwise empty pages from JSON data;
- requires a proprietary templating language.
Instead, Simulus suggests a more “modest” solution – using an existing server-rendered HTML document as its basis (either from the initial HTTP response or from an AJAX call), and then progressively enhancing.
It advocates readable markup – being able to read a fragment of HTML which includes sprinkles of Stimulus and easily understand what’s going on.
And interestingly, Stimulus proposes storing state in the HTML/DOM.
How it works
data– attributes (rather than
data-controller values connect and disconnect Stimulus controllers.
The key elements are:
- Actions (essentially event handlers) which trigger controller methods
- Targets (elements which we want to read or write to, mapped to controller properties)
Some nice touches
I like the way you can use the
connect() method – a lifecycle callback invoked whenever a given controller is connected to the DOM - as a place to test browser support for a given feature before applying a JS-based enhancement.
Stimulus also readily supports the ability to have multiple instances of a controller on the page.
Managing State in Stimulus
Initial state can be read in from our DOM element via a
data- attribute, e.g.
Then in our controller object we have access to a
this.data API with
Stimulus feels a little restrictive if dealing with less simple elements – say, for example, a data table with lots of rows and columns, each differing in multiple ways.
And if, like in our data table example, that element has lots of child elements, it feels like there might be more of a performance hit to update each one individually rather than replace the contents with new
innerHTML in one fell swoop.