Add option to sort search results

[jwr1]

Right now, the API seems to do no sorting at all; it just takes the complete list of icons, and filters out those which don't match the query and filter options, this leaves for some weird search results though.

You would expect if one searched "home", for all icons named "home" to come first, icons that are almost "home" (like "homes" or "add-home") to come second, and so forth, but this is not the case. Instead, the icons are ordered exactly as they are originally listed (presumably alphabetically, separated by icon sets). So, I think it would be useful to either add an option to sort the icons by relevancy or have that be the default.

I thought about doing this client side, but then you can run into cases where there might be an icon named "home" that is past the 999 icon mark (and is completely missed), even though that should be one of the first results.

Assuming you think this is a viable option, I could also attempt a pull request.

[cyberalien]

Problem is, many icon sets use theme prefixes/suffixes, like home-outline, which is a home icon, so if sorting alphabetically, home-outline would be shown after something like home-add, which would not be a desired icon.

Current algorithm prioritises full keywords, so first it shows everything that contains home with either - or nothing before/after it, so icons like home, home-outline are shown first. Then icons with 1 added character before/after it, like homes, then 2 and so on.

You do have a very good idea, but need to figure out how to take into account prefixes/suffixes.

[jwr1]

So, we just need to check the list of prefixes and suffixes for each icon set when sorting the icons.

I did notice however, when looking through the icon sets, that some are missing a list of suffixes. material-symbols, for instance, definitely has suffixes (outline, rounded, sharp, etc.), but they aren't listed. Maybe this is something we could look through for each set and add in any missing prefixes or suffixes, because there are quite a few other sets missing these as well.

Also, the IconifyJSON metadata page makes it seem like the themes key is used for prefixes and suffixes, but the List of icons page says themes is deprecated.

[cyberalien]

Thanks a lot for noticing bug in docs! I've fixed it, metadata docs now have correct documentation for prefixes and suffixes properties. Refresh page to see new docs. themes key is deprecated and no longer used in any icon set.

Themes are used for icon sets where all icons belong to some theme. Material Symbols is not one of those sets, even though it does contain icons that end with outline and other viable suffixes. Google Material Icons is a good example because it includes 5 distinct variations of icons. Icons in Material Symbols are mostly just ports of old Google Material Icons, so they have suffixes.

[jwr1]

I'm also noticing the search has problems with unseparated words in names, like how simple icons names their icons. If you search Google Drive, the icon from Simple Icons doesn't show because the search is not looking for googledrive (with no dashes), it's only looking for the separated keywords: google and drive.

Weirdly enough, searching google drive under the simple icons page does pull up the expected icon.

[cyberalien]

Fixed in next branch. I'll probably put new version with fix on servers this weekend.

edit: just to clarify, this fix only fixes "google drive" search, not first issue.

[cyberalien]

Found a solution, which seems to work fine.

Idea is to extract prefixes/suffixes from icon set + known prefixes/suffixes, add icon name length to each icon based on name - length of longest matched suffix/prefix. This results in home and home-outline having same length of 4 due to -outline being a suffix, home-add having length of 8. When searching, sort results by that length, so home-outline would appear before home-add.

There is a small downside with such approach though. When searching for arrow left, first result is mdi:format-pilcrow-arrow-left because it is an alias of mdi:rtl, so it has length of 3 while matching arrow-left. These weird results are rare though.

[cyberalien]

Fixed that too

[jwr1]

Thanks for all the help! I just tried out the new search from the API and it works just as expected. This, along with the unseparated words fix, significantly improves the search results :tada:.

[cyberalien]

Yes, difference is huge. Didn't expect that.

This probably is the best issue so far, wouldn't have even considered changing search engine without it. Thank you very much!

I'll put new version on servers this weekend. It requires removing servers from network, which increases load on other servers, so better to do it at weekend when load is lowest.

[jwr1]

One more thing I'm noticing, maybe this has to do with having multiple words, but searching adobe after (and even adobe after effe) pulls up most of the expected icons, except for the one from simple icons (adobeaftereffects) and file icons (adobe-aftereffects). When I search adobe after effects (it has to be the full exact name), it does show the correct icons.

This has already been a huge help, so if it's too much work, we can just leave it.

[cyberalien]

Fixed

[jwr1]

Awesome, thanks! I'll go ahead and close this issue.