I'm starting to think that these stimulus tests are worthless. The environment is not the same as a browser, which creates extra work to deal with the inconsistencies. And it means we're not testing real world behaviour.
So these are just unit tests, but they take extra effort to put together due to the inter-relatedness with the DOM. Hmm.
Had to update the form controller a little bit to handle buttons.
But arrow not showwing on focus.
Getting some weird SCSS behaviour here.. maybe I'm trying to be too clever.
I chose to use the 'elements' collection rather than choosing which elements to include (ie this supports inputs, textareas, buttons and anything else I didn't think of). It could be a bit simpler if we assume the element is a form. Even simpler if it's a fieldset (that has a disabled property). But I didn't want to limit it too much.
Unfortunately JS is quite ugly compared to Ruby. And 'prettier' made it uglier in my opinion.
It's not great to have Stimulus controller rendering markup on `connect`
Stimulus is intended to add behavior to existing markup.
Plus add some documentation
I decided not to invest the time to figure out how to test this..
The messages should have the same effect as the 500 error, but not technically a 500 because it's not handling a HTTP response. The documentation seems to state this covers server-side errors only (not network errors for example). I couldn't find any way to handle network errors with action cable.
Stimulus controllers aren't supposed to reach outside their own element (so we can't do this with targets). Perhaps the controller should be bigger to encompass more, but I wanted to see if I could avoid making a mega component that does everything. For now it seems appropriate just to pass a selector in.
Another option is to publish events on other controllers using Outlets, but I don't know if we need to go there just yet.
I found myself trying to write Ruby in Javascript, and it's not nearly as pretty..
Javascript now has more advanced data structures like Map, but it's rather useless because it doesn't have the usual iterator methods (such as filter, map, reduce etc).
Also for the spec I wasn't sure of the best approach, so will gladly recieve feedback.
Use the reflex itself
+ Don't need to create a method that will be called only in the connect
+ Simply code by adding only two lifecycle methods
Actually it seems that all reflex related to products controller should show/hide loading
+ Move outside `Admin` module the reflex
Therefore, this reflex should be _equivalent_ to its javascript controller: `ProductsV3` (relation is made through names)
Remove unwanted line
Actually call StimulusJS controller instead of calling the reflex itself
In order to have this "showLoading", "hideLoading" behavior.
It seems to be possible to directly use the Reflex itself (use `data-reflex` instead of `data-action`) but I can't make it work: the `stimulus-controller:after` event is never broadcasted/catched (but `stimulus-controller:before` yes...)
Documentation:
https://docs.stimulusreflex.com/guide/reflexes.html#understanding-stimulusreflex-controllers
https://docs.stimulusreflex.com/guide/lifecycle.html#generic-life-cycle-methods
Maybe @dacook if you want to have a look...
