Closed jayaddison closed 1 year ago
I think that a short-term workaround for this could be to handle the select2:unselect
event within the application's autosuggest component code, and possibly to raise the issue upstream. There are some select2
issue threads related to item ordering; we should be careful not to add noise until we have a good idea about the best place to comment -- and ideally a test case and/or code to contribute.
Describe the bug Order of ingredient terms in queries can be used to infer some level of priority -- more important ingredients are likely to be listed first. See openculinary/api#117 for a recent changeset where we begin using query term order as an input during tiebreaker search result ranking.
This implies that users should be able to reorder ingredients easily. Currently there is a quirk in our autosuggest controls that means that previously-selected-but-removed items may be re-added at positions other than the end of the list.
To Reproduce Steps to reproduce the behavior:
milk
,butter
andbread
.butter
.butter
.Expected behavior
butter
should appear at the end of the list; instead it is re-added in the middle.Screenshots We use
select2
in multi-select mode and with an AJAX datasource to provide the ingredient autosuggest controls.In this mode,
select2
creates an HTML<option>
element within the parent<select>
element when a selection is made by the user.However, it seems that
select2
in this mode does not remove the<option>
HTML element for items when they are unselected (the removal ofbutter
).This means that when they are re-added, the loop that builds up the list of items to render as tags discovers them in the order that they were first selected.
1. multiple items added
2. middle item removed
(notice that the entry for
butter
is still present as an HTML<option>
)3. removed item re-added
(notice that
butter
has unexpected appeared in the middle of the tag list - this seems to be due to the ordering ofmilk
,butter
,bread
as the three<option>
elements)