tagListInputController is not a standard form controller so we had to
make a few changes to integrate with the change tracking used int
bulkFormController. Mainly we make sure to manually trigger event when
deleting a tags, and we handle the change highlight.
We are already specifying the element's role ('all') in the HTML. Its behaviour should be predefined; there's no need to also specify in the HTML.
The eventhandler doesn't need to be cleand up on disconnect, because they are removed along with the DOM object.
They were already counted as changed by the javascript, but didn't have a 'changed' class to indicate it.
The reason they are 'changed', is because the dropdown has no blank option, and is forced to select the first item in the list.
This is purely to cover the case of invalid data, but should help a lot when debugging data issues. I don't think it's any less efficient, because the extra 'classList.toggle' calls don't do anything on unchanged fields.
Watch out, HAML will strip an attribute with boolean false, so we need to use a string. Or reconsider using false as a default value..
I wish Jest had the rspec concept of `let`.
Thankfully I was able to use basic DOM features, so there's no coupling of the logic with tom-select.
It wasn't going to be simple to get tom-select to listen for the 'changed' class on the original select, so I found a simple solution with a CSS sibling selector instead.
- put former remote toggle ctrller toggle method
in new toggleAdvancedSettings in more generic toggle ctrller
- modified acordingly the 2 associated views
- put former test code in more generic ctrller test file
- deleted now useless ctrller + test files
Using browser validation. I didn't use model validation because the on_hand pseudo-attribute doesn't support it.
But.. it turned out to not be so simple. Browser validation can't work if the field is hidden, and breaks the javascript. So now I made the javascript smarter, and the end result is more helpful I think.
- 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
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
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).
I was mistakenly thinking that you can define variables in beforeEach, but it turns out these are not used.
Rather, Jest was automatically creating variables for the elements according to their IDs. How convenient!
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.
