- Sanitize AJAX search queries to safely support wildcard searches (ILIKE)
- Centralize reports search actions in Spree::Ability and reuse across roles
- Fix TomSelect remote loading to fetch on dropdown open and typing
- Surface HTTP errors in TomSelect via showHttpError and improve error handling
- Update dropdown behavior to show proper “no results” feedback
- Move reports AJAX specs to request specs and expand pagination coverage
- Simplify searchable dropdown component attribute passing
TagRuleController is now a subclass of Spree::Admin::BaseController
because Admin::ResourceController did not play well with turbo_stream.
And to be honest we did not need all the functionality provided by the
ResourceController
Using the helper `definitionsFromContext` generate quite long name for
stimulus controller in component, ie :
`tag-list-input-component--tag-list-input`.
This custom loader will generate much more readable name, ie L
`tag-list-input`. It's expecting the following pattern :
ofn_component/ofn_controller.js and will fall back to the default
of replacing "_" by "- and "/" by "--" for controller not matching
the pattern.
Dynamically import only the requested flatpickr locale.
English locale is bundled by default, so passing null triggers flatpickr's built-in English fallback without an explicit import.
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.
Ok so I wasn't as smart as I thought I was. The stimulus controller knows when its element is added/removed from the DOM (and calls connect/disconnect appropriately). But if any child elements are added, they don't automatically have my new event handlers.
So I borrowed jQuery's event delegation concept, and listen for any events that 'bubble' up to the controller element, and delegate them as needed.
Alternatively, maybe I could have used a Mutation Observer, but I think it's best to avoid where possible.
Or of course, we could just revert my change and keep the 'data-action's in the HTML. I'm curious to hear opinions on this.."
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.
