Search filter does not filter type #957
Comments
1. Added provider to the pattern string for coordinates suggestion The search api call in service ignores provider type. For example, the following call returns co-ordinates with provider other than npmjs: curl -X GET "https://dev-api.clearlydefined.io/definitions?pattern=jw&type=npm" -H "accept: */*" This is probably by design: the suggestion api only takes the pattern string into account. When provider is included in the pattern string, the search result reflects the provider specification. The solution is to pass the provider information when searching in PageBrowse. 2. Also trigger search when provider is changed Task: clearlydefined#957
1. Added provider to the pattern string for coordinates suggestion The search api call in service ignores provider type. For example, the following call returns co-ordinates with provider other than npmjs: curl -X GET "https://dev-api.clearlydefined.io/definitions?pattern=jw&type=npm" -H "accept: */*" This is probably by design: the suggestion api only takes the pattern string into account. When provider is included in the pattern string, the search result reflects the provider specification. The solution is to pass the provider information when searching in PageBrowse. 2. Also trigger search when provider is changed Task: clearlydefined#957
|
I took a look at this in dev environment. Although the search relevance has certainly improved, I still observed one or more cases where other package types are shown (for example, you select "GitHub" from the dropdown but still get NPM packages in the mix too).
Furthermore, when I actually select the package from the search result it may not always show in the list below. This is certainly still the case with more generic named (NPM) packages like "cli" or "log", but does not appear to impact more specific searches such as "cli-box" or "log-driver".
I spoke with @qtomlinson and it appears this selection behavior may be by design in this view. In the workspace view, if you search and select, only the selected component is added. This should probably be tracked separately in another issue. |
To refine search result, pass component type information in search pattern. Task: clearlydefined#957
To refine search result, pass component type information in search pattern. Task: clearlydefined#957
To refine the component search result in PageBrowse, pass component type information in search pattern. Task: clearlydefined#957
|
I can confirm the above appears resolved in dev environment. The very last point I am told is by design. However, it does now actually populate the list with what I select (albeit along with many other similarly named components from other providers). |
@qtomlinson is this by design? |
|
@bduranc Yes, what you described in the above screen shot is the designed behaviour in the current web ui. The original issue documented is that the dropdown list below the search text ('abaus') box did not respect the package type selected ('NPMJS'). The dropdown list now only displays the npm related packages, which addressed the issue of 'search suggestions show everything even though filter is set to "NpmJs"'. After a specific search suggestion in the drop down list is clicked, the browse page currently displays all components whose names contain abacus and this is reflect in the url: |
|
@qtomlinson : Alright, just wanted to clarify. Thanks. @capfei : Do you think we can close this issue then? |
|
I think this specific issue appears to be resolved. It would be nice if the package name and type I searched for appeared first in the results (exact match first and then similar). If that hasn't been opened yet then I will open an issue. Thanks for fixing this one! |
Tried searching for npm package called "cli", but search suggestions show everything even though filter is set to "NpmJs". Same result if I change it to different filters. Same behavior in Chrome and Edge.
The text was updated successfully, but these errors were encountered: