Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behaviours when searching #13

Open
frolino opened this issue May 4, 2016 · 1 comment
Open

Inconsistent behaviours when searching #13

frolino opened this issue May 4, 2016 · 1 comment

Comments

@frolino
Copy link

frolino commented May 4, 2016

A couple of things:

  1. 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).
  2. 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.
@snoack
Copy link
Owner

snoack commented May 4, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants