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...
This is not a normal pattern for setting up ActionCable channels, so it might need some notes. It ensures the broadcasts from the ReportJob are unique not just to the user session but also to the specific tab in the user's browser. Otherwise if the user has two different report pages open in separate tabs with the same session, the broadcast would overwrite the #report-table element in both of them.