Optionally sort first matches starting with the query string

[dandv]

Generally, users start typing the beginning of a word or a string. For instance, at the demo page, if I type AS, I'm more likely to be looking for ASBESTOS, rather than ACID WASTE (the example is in stark contrast to the nice fruity one on the left, but that's a different issue ;)

This "preferential matching" is mentioned briefly in the README, but it requires client side support besides a custom publish function. My initial commit implemented it on both sides, and with the added wisdom since, I can submit a patch to bring that option back in a simpler way.

As a further enhancement, records containing the query string starting from a word boundary could be prioritized between those that start with the query string, and the rest (e.g. D should prefer boiler blow Down to aciD vent.

[mizzao]

@dandv I can think of a couple ways to implement a preferential matching rule without even modifying the current API; why don't you start this in a branch and we can discuss?

[dandv]

Hey @mizzao, revisiting this. It's been a while and I don't have any brighter ideas at the moment other than sorting again the results client-side. I'd be happy to start a branch. What were the couple ways you had in mind?

[mizzao]

I think what I was thinking with in the above comment was to push a custom sort field down with the specified publication function on the server, since it's already required to be a custom publication anyway. That way, the server could just pre-sort the results in whatever order and the client could use that order to display the results.

In the simplest case, the server can add a field that is 0 for things that start with the string and 1 otherwise, and the client-side can sort objects by that field, then the specified search field.

My hunch is that if the publication does sub.added with the results in the right order, they won't even need to be re-sorted on the client. That seems to occur in the vast majority of cases. Can we just depend on that behavior and obviate the need to do client-side re-sorting?

[jfly]

Is there a way to achieve this with client side data?

[mizzao]

@jfly I don't know what you mean, can you elaborate?

[jfly]

My understanding of how the preferential sorting works in the example is that the server builds a subscription by doing 2 Mongo queries: 1 requiring that the regex match the start of the field, and another which can match anywhere. The server then builds a query from those two that will return records in preferential order. See https://github.com/mizzao/meteor-autocomplete/blob/a437c7b464ad9e779da2ca15566a5b91cf603902/autocomplete-server.coffee

How would I do this with a simple local collection client side? I was able to achieve it by building a wrapper for my collection that acts like a collection (and does all the stuff the server does in the example above), but that feels kind of gross. I'm curious what the best way of achieving this is.

[mizzao]

That description is out of date. That logic has been taken out, although you can write that in your own publication. @dandv has some code that implements that.

I don't see a "simple" way to do it other than to run the two queries sequentially, but if it's in-memory it should be pretty quick to do in the client.

[jfly]

Running two queries sequentially seems fine to me for what I'm doing. I just don't know what the best way of doing it is with the api meteor-autocomplete gives me.

Here's what I hacked together (I'm looking at the profile.name attribute of Meteor.users):

  Template.foo.settings = function() {
    var fakeCollection = {
      find: function(selector, options) {
        var allResults = Meteor.users.find(selector, options).fetch();
        selector['profile.name'].$regex = "\\b" + selector['profile.name'].$regex;
        var preferredResults = Meteor.users.find(selector, options).fetch();

        var seenIds = {};
        var arr = [];
        var addResult = function(result) {
          if(seenIds[result._id]) {
            return;
          }
          seenIds[result._id] = true;
          arr.push(result);
        };
        var i;
        for(i = 0; i < preferredResults.length; i++) {
          addResult(preferredResults[i]);
        }
        for(i = 0; i < allResults.length; i++) {
          addResult(allResults[i]);
        }
        arr.count = function() { return arr.length; };
        return arr;
      }
    };
    return {
      position: "top",
      limit: 5,
      rules: [
        {
          collection: fakeCollection,
          field: "profile.name",
          template: Template.userPill,
          matchAll: true
        }
      ]
    };
  };

Faking a collection feels pretty gross to me. Is there a better way of achieving this?

[jfly]

Bumping this issue because I'm still curious if this is the recommended solution. Thanks for the great library!