Then add the following into the app/assets/javascripts/application.js
//= require stimulus.umd
I then would create a folder in the app/assets/javascripts called stimulus.
Within this new folder, I create another application.js file with the contents
const appStimulus = Stimulus.Application.start()
Following the Copy to Clipboard example that they have on the docs, you would create a copy_to_clipboard_controller.js within the stimulus folder with the contents
appStimulus.register("copy_to_clipboard", class extends Stimulus.Controller { copy_text(e) { e.preventDefault() this.copy_address_field.select() document.execCommand("copy") } get copy_address_field() { return this.targets.find('copy_address_field') } })
Take note that the constant that I created was appStimulus and within each controller, we first call appStimulus.register(...)
This should get you started with getting Stimulus up and running in an existing application without adding Webpack. I don't think that I would add the complexities of Webpack in a application just for Stimulus. This would be my preferred route in an existing application.
Also, you may find that there are problems deploying to production. You may need to update the Uglifier gem to a later version and change the line in your config/environments/production.rb
# Compress JavaScripts and CSS. config.assets.js_compressor = Uglifier.new(harmony: true)
You can to some degree. Remember that you will have to have the DOM elements already existing on the page so if any of the referred JS is adding elements, there may be some disconnect with Stimulus. However, a lot of it probably can be moved over. For example, if you have a date picker which has a lot of different attributes and customization, that would probably be a good candidate. A nested forms "Add Item" & "Remove Item" links may not be a good fit since you're adding elements to the DOM.
>I don't think that I would add the complexities of Webpack in a application just for Stimulus. This would be my preferred route in an existing application.
Would you be able to expand on the added complexities of Webpack (through webpacker)? I was planning on switching from sprockets to webpack based on the advantages discussed in this article: https://rossta.net/blog/from-sprockets-to-webpack.html
On an existing established application, you would be adding extra dependencies for a micro framework. While Webpack would have long running benefits in the application, I wouldn't necessarily add it into one just for this. If I was tasked with refactoring the app and clean up a bunch of javascript files, vendor assets, etc. then I would consider adding it in.
Thanks for taking the time to reply. When you refer to adding extra dependencies, are you referring to the webpacker runtime dependencies of activesupport and multi_json (as well as the webpacker gem itself)? I'm still just trying to completely understand any webpack baggage before making the switch.
It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system
FYI, here's a blog post you may have seen where the author had great difficulties using webpacker: https://www.codementor.io/help/rails-with-webpack-not-for-everyone-feucqq83z
I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.
Hi,
I've heard about Stimulus being a good drop-in replacement for jQuery (within rails application) rather than being a competitor to Vue, Angular, etc.
It suits my needs because of I already have my HTMLs and I wanted to get rid of jQuery and sprockets etc.
My application doesn't have heavy JS features but definitely some kind of DOM manipulation for forms (validation and nested form addition and deletion).
Some other use-cases I think of are field formatting (phone numbers with dashes, prices with appropriate currency symbols and spaces, etc.), and also multi-step forms (with JS), so basically like a mini SPA for the multi-step forms only.
Will I be able to do this kind of stuff with Stimulus? (again without jQuery)
I will refactor my whole UI and I was also thinking about either going with Stimulus or Vue..
Regarding my needs do you have some advises?
What version of Rails are you using? I think the Stimulus route is the right path. Vue is acceptable as well, but Stimulus is a lot more light weight.
You can definitely use Stimulus without jQuery. If you are using other JS libraries which require jQuery, you can still pull it into your project, but just write your application's JS without it. If jQuery is being added into your Rails application as a dependency for another library, I think that's fine, but just avoid using jQuery directly as it would then become a dependency of your application as well as the library.
Hi,
I would like to test this in current app which is on rails 5.1.4, so I would like to know how to add webpack, and rest of the code ?
Thanks.
The easiest way to get started would be to download this file https://unpkg.com/stimulus/dist/stimulus.umd.js and add it to your vendor/assets/javascripts folder.
Then add the following into the app/assets/javascripts/application.js
I then would create a folder in the app/assets/javascripts called stimulus.
Within this new folder, I create another application.js file with the contents
Following the Copy to Clipboard example that they have on the docs, you would create a copy_to_clipboard_controller.js within the stimulus folder with the contents
appStimulus.register("copy_to_clipboard", class extends Stimulus.Controller {copy_text(e) {
e.preventDefault()
this.copy_address_field.select()
document.execCommand("copy")
}
get copy_address_field() {
return this.targets.find('copy_address_field')
}
})
Take note that the constant that I created was appStimulus and within each controller, we first call appStimulus.register(...)
This should get you started with getting Stimulus up and running in an existing application without adding Webpack. I don't think that I would add the complexities of Webpack in a application just for Stimulus. This would be my preferred route in an existing application.
Also, you may find that there are problems deploying to production. You may need to update the Uglifier gem to a later version and change the line in your config/environments/production.rb
Hi,
Can I move all js sprinkle code and jquery plugins to stimulusjs so that I can organize better and execute page specific js only?
Thanks.
You can to some degree. Remember that you will have to have the DOM elements already existing on the page so if any of the referred JS is adding elements, there may be some disconnect with Stimulus. However, a lot of it probably can be moved over. For example, if you have a date picker which has a lot of different attributes and customization, that would probably be a good candidate. A nested forms "Add Item" & "Remove Item" links may not be a good fit since you're adding elements to the DOM.
>I don't think that I would add the complexities of Webpack in a application just for Stimulus. This would be my preferred route in an existing application.
Would you be able to expand on the added complexities of Webpack (through webpacker)? I was planning on switching from sprockets to webpack based on the advantages discussed in this article: https://rossta.net/blog/from-sprockets-to-webpack.html
On an existing established application, you would be adding extra dependencies for a micro framework. While Webpack would have long running benefits in the application, I wouldn't necessarily add it into one just for this. If I was tasked with refactoring the app and clean up a bunch of javascript files, vendor assets, etc. then I would consider adding it in.
It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system
FYI, here's a blog post you may have seen where the author had great difficulties using webpacker: https://www.codementor.io/help/rails-with-webpack-not-for-everyone-feucqq83z
I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.