Repository navigation
Allow to search keys #19
Description
We will probably have thousands of properties and we need to make them easy to find.
For the end-user, the best option would be to enter a keyword related to the property he wants to add.
Example: searching how to enter the color of the cap:
- the user enter "c", then "o", then "l"
- the UI should provide a list containing properties (or descriptions) containing "co" then "col"
The GET /keys is currently returning all the keys with stats:
- the stats are not useful for our current concern
- returning ALL the keys might be costly when there are thousands of properties
Currently, Open Food Facts website is already using tags autocompletion with a library (tagify) that takes simple JSON arrays in input ["tag1","tag2","free_tag"] (see the explanation here).
Suggestion 1
Create a GET /keys&term=col which returns a simple JSON array: ["color","color_of_the_cap","multicolor"].
Suggestion 2
Create another API route to return only the useful data:
- rename GET /keys into /key_stats
- create GET /keys&term=col which returns a simple JSON array:
["color","color_of_the_cap","multicolor"].
Part of
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
stephanegigandet commentedon May 12, 2021
Well the current /keys is very similar to what you get on the web site with facets /labels
I do think the stats are very useful, even for end users, to know how popular a key is.
My preference would be to keep /keys as is, and add parameters to filter them ?term=color (word search), and ?autocomplete=col (makes it clear that is searches on starts of words and not full words). But keep the output the same (with counts).
CharlesNepote commentedon May 12, 2021
I don't say we should avoid stats! I also do think stats are useful, but not for an autocompletion service.
To synthetize you suggestion @stephanegigandet :
Suggestion 3
Keep GET /keys results as is but add a &term= (full word search) and &autocomplete= (start of the word) to refine the results.
About &autocomplete=
Currently, Open Food Facts is returning all words containing the term, and not just the words beginning by the searched term. I'm in favor of chosing words containing the searched term as many of the properties will use expressions. Eg:
KISS for the backend devs or for the frontend devs?
Suggestions 1 and 2 makes life quite easier for frontend devs: JSON arrays are far easier to use (and it's ready to use in OFF website).
Suggestion 3 probably makes life easier for backend devs but makes frontend devs' work harder.
IMHO, the API should always try to make frontend devs' work easier.
stephanegigandet commentedon May 12, 2021
You need both &term= for word search, and &autocomplete= for autocomplete / suggest as you type search.
What you described here is suggest as you type:
And here it's regular word search:
The user types a keyword and hits enter. (then the keyword can match in the property name, but potentially also its metadata, description etc.)
stephanegigandet commentedon May 12, 2021
Not much I think, and it's useful to have stats/metadata available even for suggest as you type results, or search results, so that you can display it to users:
Search properties: col (user typing)
Properties:
I'd argue that it's even simpler for devs if you get the same format of results when you list all keys, or keys containing a specific term, or keys starting with characters. Frontend code can be only one function that covers all use cases.
Ajay-Nair commentedon Apr 8, 2022
@stephanegigandet So if I understand you correctly, you want to do as follows:
Idea 1: As the user types each letter, the frontend does the &autocomplete query (which does prefix search, else we may have too many hits). When the user enters a space after a word is complete, then do &term query. This &term query does full word search.
For eg: So as I type 'c' it shows ['Color (1532 products)', 'Collectible (120 products)']. If we did full word search with 'c', we will return all items with 'c' in it, thus we only do prefix search for &term queries. As I complete 'color ', it shows ['Color (1532 products)', 'Bottle cap color (32 products)']. The problem here being two different behaviours for the same input field.
Idea 2: Both &term query and &autocomplete query does full word search. But we only give results after second character is typed.
I will think and come back on handling multi-word queries (May have to use some sort of inverted search/search engine, though it may be an overkill).
[-]Key search[/-][+]Allow to perform a Key search[/+][-]Allow to perform a Key search[/-][+]Allow to search keys[/+]CharlesNepote commentedon Mar 14, 2025
@stephanegigandet as a first step:
/keys&term=which is searching for property name containing the term/keys&autocomplete=which is a bit redundant withterm; in the vast majority of the cases, the term searched by people will be inside the property not at the beginning of the property/keys&search=which would allow to search in the properties' documentation (but it's harder to implement)Ok?
stephanegigandet commentedon Mar 14, 2025
Instead of ?term=, on the OFF website we use filter: e.g. https://fr.openfoodfacts.org/facets/labels?filter=bio returns a list of labels that have "bio" anyhwhere in them. ?term=word would be more appropriate to search for full words.
CharlesNepote commentedon Mar 14, 2025
@stephanegigandet Yes we should try to be coherent. But unfortunately we already use
?q=to filter thing https://api.folksonomy.openfoodfacts.org/docs#/default/get_unique_values_values__k__getShould we use
qorfilterfor both?stephanegigandet commentedon Mar 17, 2025
"q: Filter values by a query string" -> is that the same filter you want for keys (i.e. match anywhere in the string without needing word boundaries)? if yes, then use q= for keys as well..
CharlesNepote commentedon Mar 17, 2025
Fine, so let's use
q=as well.kirtanchandak commentedon Mar 17, 2025
working on this
CharlesNepote commentedon Mar 21, 2025
Thanks a lot @kirtanchandak !