[winstliu]

Requirements

• Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• All new code requires tests to ensure against regressions

Description of the Change

This PR removes the custom sorting logic that the setting-view performs after getting search results from apm. My reasoning is that with the recent changes to apm's sorting we should no longer need to add extra sorting in settings-view. This also means that the search results will be consistent regardless of whether the search was executed through settings-view, apm, or https://atom.io/packages/search.

Alternate Designs

None.

Benefits

Removal of code that had minimum benefits as well as consistency with other search methods.

Possible Drawbacks

It is possible that some people might prefer the custom sorting settings-view did.

Applicable Issues

None.

/cc @Ingramz do you have any opinions about this?

[Ingramz]

.filter and .map need to be on the same level: first filter is done, then map, not one inside other.

[winstliu]

Ah, I must have touched that line by accident when removing .sort. Then Coffeelint gave me errors and I guess I didn't notice and "fixed" it incorrectly :/.

Of course, this would have been avoided with JS 😀.

[Ingramz]

I don't mind if search worked identically everywhere (website, apm, and settings-view). I think it makes the ecosystem more consistent and predictable.

While the new ordering done serverside surfaces relevant packages without requiring assitance from the clientside (searching for blade shows nicely all blade related packages on top, which I like), it feels a little off. Maybe it is because a more popular package is not a top hit, but it's not as big of a deal as all 3 results are very close to the top.

Searching for common terms like php or javascript also do seem to have a clear boundary from which packages containing the search term are promoted to the top, however the ordering among them seems off. If the recent serverside improvement is essentially replicating the addCloseMatches and highlightExactMatch done in settings-view, then I would suggest sort by downloads done on the results that qualify for the addCloseMatches criteria.

Settings view does not implement pagination for search results, which means that it is important that good search results make it to the first page, preferably above the fold. This might become more important if all relevant search results do not fit into the first page.

In general I like where this is going and I am interested in what others think.

[Ben3eeE]

We got a question about this on the forums https://discuss.atom.io/t/visibility-inconsistent-package-search/51856

[daviwil]

Thanks @50Wliu! I agree that it's better to respect atom.io's search result ordering in Atom and focus future refinements in that codebase. Merging it!