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.
By disabling line wrap we can consistently predict how it will appear. The longest translation we currently have is 14 characters so this should be fine.
This was broken when upgrading [Foundation](https://github.com/openfoodfoundation/openfoodnetwork/pull/11349). For some reason the button.expand class now sets larger font size and padding, which overrides the button.small class. It's probably a bug but we'll have to work around it.
Now we don't have to specify the field names on products, yay!
I tried desparately to get it working for the nested variant forms too, but sadly the form builder refuses to acknowledge the relationship. The form builder simply doesn't support a collection of objects in this way.
We could try creating a fake model similar to ProductSet that accepts_nested_attributes_for :products. But it woudl be better to create a custom form builder to do it.
Or, just manually specify field names for now!
I have to admit I don't fully understand why, but it seems to work, even though the rails guide says "only one level of arrayness is allowed (https://guides.rubyonrails.org/form_helpers.html#combining-them). Maybe it's ok here because it's not an array of arrays.
(I think this format is what the reflex spec was already testing).
This means you can click on the label name to select the field, and accessibility software can read the label name. I was motivated to do this so that we could update the spec to use label text rather than IDs. But it seems we can't do that with tom-select.
I've updated the styles for all form labels (in admin_style_v3 toggle) to match the design.
I think that it's a valid case to check a feature toggle against the
user and an enterprise. You may want to check with only one user first,
then activate it for a whole enterprise and lastly activate the feature
globally.
