loading...

Composable Stimulus Controllers?

adrienpoly profile image Adrien Poly ・1 min read

Quite some time ago I wrote a simple Stimulus wrapper for Flatpickr. I learned a lot while doing this project. One of my initial goal was to explore the possibility of having standard controllers with in the Stimulus world. Controllers anyone could use to avoid reinventing the wheel every time.

Stimulus by default is a modest (yet powerful) framework. The list of available standard controllers is also rather modest.

Beside a few exceptions I don't have the feeling they are widely used. While many factors can explain it, for me the missing ability to compose multiple simple behavior within a controller has been a major obstacle of adoption.

I have been recently looking into this and made a few prototypes. Would love to have feedbacks if anyone already tackled this problem

Have you made in your projects some reusable, shareable and composable Controllers ?

Posted on by:

adrienpoly profile

Adrien Poly

@adrienpoly

Freelance Fullstack developer Rails React Javascript

Discussion

pic
Editor guide
 

Took me some time to narrow the API but here is my first shot at building a library of composable behaviors to enhance your Stimulus Controllers
github.com/stimulus-use/stimulus-use

Hopefully much more behavior to come down the road

 

You've poked the bear! And almost everything I'm saying here applies equally to Turbolinks, which suffered the most undignified release non-strategy I can think of.

I consider Stimulus to be the greatest thing to happen to JavaScript since jQuery came out. Of course, it's cool to hate on jQuery in 2020 but I was there - eventually using Prototype, then jQuery - when everything about working in JS sucked. So many things we take for granted in EcmaScript and the browser selector API etc we owe to Sam and John Resig moving us forward.

Stimulus could be equally transformative, but it gets basically zero push from Basecamp and as such, the vast majority of developers have simply never heard of it. This actually infuriates me, because Basecamp has such a tall platform from which to promote important ideas.

It is true that things are slowly changing: there's the awesome-stimulus list, betterstimulus.com. But nobody (except us!? it seems? how is this possible, though...) is really overtly championing Stimulus and Turbolinks. Hell, it seems like half of the Rails community hasn't tried Stimulus, and a depressingly high percentage of Rails developers have --turbolinks in their .railsrc because of the aforementioned release disaster. It's become like a 2nd-generation trauma, now, where even people who weren't developers when TL came out "know" that they are supposed to kill TL before it hurts them.

The simple fact that people can show up on the Stimulus Discourse and ask if the project is dead when it's on the eve of the largest update since it came out is maddening. The Basecamp folks seem to be bending over backwards to not notice people asking questions, solicit input or gasp ask if the community has some good ideas or would like to get more formally involved. It's developed behind a wall and released to us when they feel like it, and frankly, it feels cruel because this library is so good, so important and something we want to be involved with.

You gave me some shit on the Stimulus forum for having the audacity to mention that there's an active Stimulus channel on the StimulusReflex Discord, and while I assume good intent, the fact is that as someone invested in Stimulus, I hope that you can see yourself as a bit of an activist, too. We wouldn't likely have a #stimulus channel if there was a place where actual Stimulus devs were congregating and sharing controllers.

Now, for my part I'm trying to be part of the solution by releasing more and more of my extracted controllers as well-documented packages. I put out stimulus-image-grid last week, and there's a dozen more to come. All of these will be namespaced stimulus- and each will have similar instructions showing how easy it is to register a composable component from an npm package.

But the real reason Stimulus isn't thriving is a lack of loud promotion. Look at how much clout the Python Foundation has given their favourite language? Look how much clout Basecamp loudly championing Rails has given us? Without some role models with large followings taking a much more assertive role in championing Stimulus, it's going to be a small, quiet community for a long time, and that is a shame - especially given what's at stake: an entire generation of new devs being told that React is the future. It's kind of dire, my friend.

 

Thanks for your detailed answer.

While I agree that things are moving slowly with Stimulus, I am grateful to Basecamp for making this open sourced, battle tested, well documented.

Yes the last release is more than a year old and for any Javascript developer this is a smell. I took over recently a React project that wasn't that old and I had to bump Redux by 3 major versions!

BUT

  • In the list of issues I don't see anything major that should have been addressed urgently
  • What Stimulus is intended to do it does it perfectly well and it just works
  • Basecamp is a 50 persons company and their main business is not delivering Stimulus / Turbolinks
  • Yes I am also waiting for the v2 and the Value API but this new API is mostly a convenience feature. There isn't much that I will be able to do with v2 that I am not able to do with the current version. It will just make controller cleaner (except maybe for the changed callback)

Still, I agree that it would be great if they could publish some more open roadmap of what they want to do so that more open source contributors could submit PR rather than waiting for them to make the call.

Adoption rate might be low within the Rails community, I am not sure this is really only Stimulus issue. I think one of the major challenge Rails dev are facing is moving from their Sprockets old style jQuery in the view Javascript to a more modern Webpack ES6 style javascript.

With regard to my comments in the forum sorry if it was misinterpreted
I think my main intent was to say that
1) diluting the community won't make it more active as a team
2) while discord offers real time chatting, it ends up being a private discussion group and all the content generated within this group cannot be searched and found by a newbie Googling questions on Stimulus
3) While maintainers don't answer to all post on Discourse I am sure they are reading it. Quite often they will answer when they feel like a more advanced answer is required. So keeping feedback, requests, pain point in front of their eye is important
4) also in some way Basecamp sees Discord as a competing product. Lots of their talks are against distraction caused by tools like Slack/Teams and by extend Discord

Thanks for all your contribution to this community looking forward to test you Image gallery controller

 

Interesting perspectives!

I used IRC, Campfire (and later HipChat) long before Slack was a gleam in the eye. I think Basecamp made a principled decision to move away from RT chat, and frankly - I don't love RT because I personally lack self-control to not jump in. It ends up being incredibly distracting, although I will say I like it for StimulusReflex as an open source project far more than I like it in a professional setting. It's really hard to find organizational data in a mountain of chat.

That all said, the reason I've been positive on Discord for our project is that forum posts are slow and kind of lonely - they don't encourage people to jump in and problem solve in real-time as a community. If you show up at the SR Discord with a problem, you get tackled by a group of experienced developers that treat your arrival as good news and actually set down their tools to help a newcomer get over the first hump. It's allowed us to build an incredible community in a relatively short period of time. People sometimes get emotional (in the good way). That is just not a thing on a message board.

I agree with you about Basecamp not being in the business of promoting Stimulus, because it's not really something that can be debated. To me, the important question is what, if anything, we as a community of users are willing to do to change the story going forward. Open source projects can grow bigger than the creator envisions, but it's not going to be done for us.

 

Hey Adrien, thanks for sharing your thoughts on this.

Based on reference documentation for stimulus, it's possible to use multiple controllers on a single DOM element. Doesn't that qualify as composable?

stimulusjs.org/reference/controllers

 

Yes it is definitely a great way to compose controllers. It forces you to make small and specialized controllers. This is a good practice however not always followed in practice 😀