I’m never sure where to comment on your posts! Which location do you consider canonical?
I’m a big fan of the intersection observer, but typically mix in useIntersection from stimulus-use.
I tend to use initialize to store an array of matching elements, and then in the connect/disconnect I set up event observers on the elements in the array. This dramatically cuts down on the amount of markup that needs to be added to your page to use your controller. It’s certainly an issue of personal preference, but I get a massive thrill from being able to write and deploy controllers that only need to be attached to appropriate markup, no other targets or actions required.
Another great post. Tech will move faster as more folks realize Stimulus is the solution they’ve always been searching for.
I'm posting in a lot of places these days - posting here and on IH is new for me.
Interestingly, this post got very little traction here and on IH compared to my last post, but it did several multiples better than the last post on Medium.
The canonical place is always my (comment-free) blog at colby.so but I post to the other sites for extra visibility early on. The blog is mostly just the permanent home in case content disappears from external sites someday. Wherever you comment, I'll see it!
On the matching elements without targets: I initially built this the same way but then swapped out for targets. There's a lot more markup with this approach but it felt more Stimulus-y to use targets even if it is more verbose.
In guides like this it feels better to try to stick to the by-the-book path (or at least my interpretation of by the book) for folks who are interested in seeing how the tool works. I'm still learning what works best for this type of writing though, I can see that examples of really clean markup might be effective in pulling folks in to learning more about Stimulus too.
That's the funny thing about a relatively small community: we each have a disproportionate ability to influence the direction "best practices" tend to fall. We've been doing our best to document these outcomes on betterstimulus.com/ for a few years now, but there's till lots we're figuring out in real time.
So yeah... I don't know if "Stimulus-y" means as much as "Rails-y" yet, because there's just been fewer eyeballs on the problem domain.
The litmus test I run with when trying to decide how to collect elements is: is there ambiguity such that targets enable an explicit control that wouldn't be possible to infer otherwise? Or, based on the nature of the controller and what's nested under it, is it redundant make-work?
In other words, a controller that is intended to live on a ul and wrangle li elements probably doesn't benefit from forcing developers to attach a target to each li.
Anything more arbitrary, well... yeah, that's what targets are for!
Yeah, I've gotten a ton of use out of betterstimulus.com since I've committed to Stimulus for most of my projects - you and the other folks there are a huge resource to the community.
That way of thinking about target usage seems pretty reasonable, thanks for sharing!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I’m never sure where to comment on your posts! Which location do you consider canonical?
I’m a big fan of the intersection observer, but typically mix in useIntersection from stimulus-use.
I tend to use initialize to store an array of matching elements, and then in the connect/disconnect I set up event observers on the elements in the array. This dramatically cuts down on the amount of markup that needs to be added to your page to use your controller. It’s certainly an issue of personal preference, but I get a massive thrill from being able to write and deploy controllers that only need to be attached to appropriate markup, no other targets or actions required.
Another great post. Tech will move faster as more folks realize Stimulus is the solution they’ve always been searching for.
I'm posting in a lot of places these days - posting here and on IH is new for me.
Interestingly, this post got very little traction here and on IH compared to my last post, but it did several multiples better than the last post on Medium.
The canonical place is always my (comment-free) blog at colby.so but I post to the other sites for extra visibility early on. The blog is mostly just the permanent home in case content disappears from external sites someday. Wherever you comment, I'll see it!
On the matching elements without targets: I initially built this the same way but then swapped out for targets. There's a lot more markup with this approach but it felt more Stimulus-y to use targets even if it is more verbose.
In guides like this it feels better to try to stick to the by-the-book path (or at least my interpretation of by the book) for folks who are interested in seeing how the tool works. I'm still learning what works best for this type of writing though, I can see that examples of really clean markup might be effective in pulling folks in to learning more about Stimulus too.
Thanks for the feedback and the support!
That's the funny thing about a relatively small community: we each have a disproportionate ability to influence the direction "best practices" tend to fall. We've been doing our best to document these outcomes on betterstimulus.com/ for a few years now, but there's till lots we're figuring out in real time.
So yeah... I don't know if "Stimulus-y" means as much as "Rails-y" yet, because there's just been fewer eyeballs on the problem domain.
The litmus test I run with when trying to decide how to collect elements is: is there ambiguity such that targets enable an explicit control that wouldn't be possible to infer otherwise? Or, based on the nature of the controller and what's nested under it, is it redundant make-work?
In other words, a controller that is intended to live on a
uland wranglelielements probably doesn't benefit from forcing developers to attach a target to eachli.Anything more arbitrary, well... yeah, that's what targets are for!
Yeah, I've gotten a ton of use out of betterstimulus.com since I've committed to Stimulus for most of my projects - you and the other folks there are a huge resource to the community.
That way of thinking about target usage seems pretty reasonable, thanks for sharing!