You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, typing the ingredients in reverse order has inconsistent behaviour, particularly if one of the elements is a non-alphanumeric character - e.g., type "r" in the first input element, then type "." in the next input element. The results will still show something. However, once you refresh the page at that state, the results become blank. (If you type in reverse order - i.e., ".", then "r", the results will always be blank).
If you type an empty space in an input text element, and then focus out of the element, the input text element does not get removed. It may be better to check the trimmed version of the input element's contents here, which gets rid of beginning and trailing whitespace.
The text was updated successfully, but these errors were encountered:
That the order of ingredients can effect the search result is just the natural behavior of the relevance ranking algorithms used by virtually every full text search engine, i.e. Sphinx in the case here. It might make less sense for pseudo-structured data like the ingredients here than it does for simple full text search, but as long as I don't observe any negative impact on meaningful searches, I wouldn't change it. In fact I'd expect that disabling extended relevance ranking in Sphinx will actually give worse results for most searches. Alternatively, we could simply sort the list of ingredients before passing them to Sphinx. But again, I don't mind small inconsistencies in constructed edge cases, as long as we still get good results for meaningful searches. In particular if it's not a bug but the natural behavior of the underlying algorithms.
The reason the UI doesn't care to trim the input, is that the Sphinx's stemming algorithms take care of that on the server-side anyway. Hence it would be redundant as far as the search logic is concerned. However, I see that users might expect the field to disappear when it has only whitespaces, like it does when it has no content at all. While I still consider it a negligible edge case, I guess I would accept a patch.
A couple of things:
The text was updated successfully, but these errors were encountered: