- add enableIfPresent method in toggle_control_controller.js to handle enabling on toggle
- add testing in the corresponding spec
- replace in view previous ctrler with intended generic toggle-control
This could have been done with a tiny amount of inline JS, but I went this way in case I needed any special logic for UJS. It turns out we don't.. but it still looks a bit cleaner this way.
Remove shop-tabs controllers since we can listen on `"data-action":
"orderCycleSelected@window->tabs-and-panels#activateDefaultPanel"`
Test for cases:
* activate by clicking on tab
* activateDefaultPanel on orderCycleSelected event
* activateFromWindowLocationOrDefaultPanelTarget to activate tab based
on achor in URL
Hmm, but this isn't useful until we get Tom-Select to work the way we want..
To do that, I think we'd ned to hook into TS to clear the current selection when focused, then set it back upon blur (if no selection was made). Hmm, but we still want it to show slected in the dropdown list.
Can we do it with css maybe?
It doesn't matter where the flash messages appear in the HTML (thanks to fixed positioning), so why not keep it simple and send them with the main response.
preventDefault in case we are inside a form, so the button doesn't submit it.
This ensures morphed flashes hide like other flashes (eg in bulk order actions). I wanted to write a spec to prove it, but Capybara doesn't support mocking setTimeout and I didn't want to use sleep.
I've made it optional because this controller is shared with the shop frontend ([supposedly](5ef34347a3), although angular seems to override it).
This introduces a new 'toggle' controller, and we already had three\! So I created a generic interface that could be extended to potentially support all of them. I propose we try to reduce them all into the one controller, but won't go down the rabbit-hole just yet..
I have an idea on how to re-arrange and make it more contained, by assigning the controller only to the checkbox, and defining targets with aria-controls="", but chose to stick with Stimulus conventions for now.
I couldn't think of a simpler way to hardcode it, so now we have a clever generic method :)
We can assume that hidden elements will stay hidden, but we need to check each time if an element is disabled or not.
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.
