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.
from old bulk product screen. Hmm I just realised we're deleting that screen soon anyway.
But this helps clean up the spec before I refactor it further.
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.
As per review comment, use data-disable-with="false" do prevent Rails
from automatically enabling the "Apply" button. We can then remove
the timeout hack.
The "apply" button is disabled by default. If left enabled, a customer
could try to apply an empty voucher, which results in system trying
to move to the order summary step, an unexpected behaviour!
We only enable the button when something is entered in the input.
The code used the global BulkProducts which was shared amongst a group
of specs. Some were resetting the `products` attribute, others weren't
and the product object of one spec was leaking into the next.
One spec was also referencing a wrong attribute and must have passed
accidentally.
jquery-ujs automatically disable submit button when submitting the form.
If one choose cancel on the leaving page warning, then the submit buttons
end up in a disable state, with no way to re enable them. This fix
prevent the warning from being triggered when submitting the form, so
we can't end up in the scenario described.
