As you mention bin/webpack-dev-server, a great enhancement for my rails 6 development I did is using foreman. Put a file called Procfile.dev in your app's home directory:
Being tired of all those frontend stuff, Stimulus seems to bring Rails in the frontend. That's really lovely to see another way of building things. And nobody can tell it doesn't scale; Hey and Basecamp are a good exemple. Very neat.
All the examples I've seen before were too trivial, e.g. change a style of an element, add some HTML content in a target section, etc. What about a concrete use of Stimulus in a Rails CRUD app and explain the pros and cons, tests, etc. It would be really great and useful.
☒ I believe the main benefits of Stimulus is isolation, reloading, minimization, and ease of use.
Isolation - The controllers don't leak over into other pages. If the data attributes are present for that controller, it will work, but is deconstructed after the page refreshes or navigates away where those data attributes are no longer present. This makes working with complex front ends really nice. There is a caveat though with something like getusermedia where the use of a webcam or audio source could leak from one page to another and must be handled properly.
Reloading - Whether you're loading the controller on a new page refresh, adding in controllers via UJS, or even rending a partial sent over websockets, the controller will initialize and work. This use to be a pain in situations where UJS wouldn't initialize a datepicker and you had to manually initialize it again.
Minimization - You get a lot of functionality from such a tiny library. Even then, you don't have to write a bunch of Javascript to get highly interactive front ends. This combined with Turbolinks/Turbo makes for a super powerful tool.
Ease of Use - By following the conventions, you can make your javascript more readable and easier to maintain. Write less javascript and get more functionality. Bringing in additional libraries is easy with webpacker. This will be interesting to see how things change if we revert back to sprockets, but for now, webpacker is a very viable solution.
I recommend that you check out some of the other videos like Google Maps API, Video Chat with WebRTC, FullCalendar, AutoComplete, Drag and Drop, Audio Recording, QR Codes and Cropping images. All of these are accomplished using StimulusJS.
Thank you, David for the provided response. Sure I'll a look athletic the indicated resources ti understand better the real field of application of Stimulus. For example, I wonder how to proceed if you need to display some additional content on a page only after a user clicks on a button and avoid the page reload, - what kind of response should I use in the corresponding Rails controller action (js, html, json, etc.)?
In those kinds of situations, you have a few different paths.
If you use button_to for the button with remote: true, you can make an AJAX call via RailsUJS to your Rails application which would be a JS format. Within the <action>.js.erb, you could render a partial and insert it onto the page. If that partial has a stimulus controller within it, the controller would initialize and "just work"
If you use a stimulus controller for the button, when clicked, you can make the AJAX request back to the Rails application in a similar fashion and then render a partial within the Rails controller action and then insert this into the page.
Thank you, David, - I think I have to dig deeper this kind of situation:
If you use a stimulus controller for the button, when clicked, you can make the AJAX request back to the Rails application in a similar fashion and then render a partial within the Rails controller action and then insert this into the page.
Put a file called Procfile.dev in your app's home directory:
Isolation - The controllers don't leak over into other pages. If the data attributes are present for that controller, it will work, but is deconstructed after the page refreshes or navigates away where those data attributes are no longer present. This makes working with complex front ends really nice. There is a caveat though with something like getusermedia where the use of a webcam or audio source could leak from one page to another and must be handled properly.
Reloading - Whether you're loading the controller on a new page refresh, adding in controllers via UJS, or even rending a partial sent over websockets, the controller will initialize and work. This use to be a pain in situations where UJS wouldn't initialize a datepicker and you had to manually initialize it again.
Minimization - You get a lot of functionality from such a tiny library. Even then, you don't have to write a bunch of Javascript to get highly interactive front ends. This combined with Turbolinks/Turbo makes for a super powerful tool.
Ease of Use - By following the conventions, you can make your javascript more readable and easier to maintain. Write less javascript and get more functionality. Bringing in additional libraries is easy with webpacker. This will be interesting to see how things change if we revert back to sprockets, but for now, webpacker is a very viable solution.
I recommend that you check out some of the other videos like Google Maps API, Video Chat with WebRTC, FullCalendar, AutoComplete, Drag and Drop, Audio Recording, QR Codes and Cropping images. All of these are accomplished using StimulusJS.
https://www.driftingruby.com/episodes?tag=stimulusjs
If you use button_to for the button with remote: true, you can make an AJAX call via RailsUJS to your Rails application which would be a JS format. Within the <action>.js.erb, you could render a partial and insert it onto the page. If that partial has a stimulus controller within it, the controller would initialize and "just work"
If you use a stimulus controller for the button, when clicked, you can make the AJAX request back to the Rails application in a similar fashion and then render a partial within the Rails controller action and then insert this into the page.