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.
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.
