Canonical way to use jQueryUI autocomplete with Meteor

Using Meteor, I would like to understand the most efficient way to use jQuery UI autocomplete with large amounts of server data.

I have two working suggestions and would like to hear opinions on the differences and if there are any better ways to do the same.

Using pub / sub:

// Server Meteor.publish("autocompleteData", function (theSearchTerm) { var query = { name: { $regex: theSearchTerm, $options: 'i'} }; return MyData.find(query, options); }); // Client Template.myTemplate.rendered = function() { initAutocomplete($(this.find('.my.autocomplete'))); }; var initAutocomplete = function(element){ element.customAutocomplete({ source: function(request, callback){ var sub = Meteor.subscribe('autocompleteData', request.term, function(){ var results = MyData.find({}, {limit: 50}).fetch(); sub.stop(); callback(results); }); }, select: function(event, ui){ // Do stuff with selected value } }); }; 

Using Remote Functions (Meteor.Methods):

 // Server Meteor.methods({ getData: function(theSearchTerm) { var query = { name: { $regex: theSearchTerm, $options: 'i'} }; return MyData.find(query, {limit: 50}).fetch(); }); }); // Client Template.myTemplate.rendered = function() { initAutocomplete($(this.find('.my.autocomplete'))); }; var initAutocomplete = function(element){ element.customAutocomplete({ source: function(request, callback){ Meteor.call('getData', request.term, function(err, results){ callback(results); }); }, select: function(event, ui){ // Do stuff with selected value } }); }; 

What, if so, is the most efficient way to install server-side auto-completion using Meteor with a large dataset?

+5
source share
1 answer

For what it is worth, I will offer some of my thoughts on this issue. As a disclaimer, I'm just a Meteor enthusiast, not an expert, so please correct me if I said something wrong.

For me, this seems like the potential advantage of pub / sub in such cases that the data is cached. Therefore, when subscribing to the same set of records, the search will be almost instantaneous, since the client can search in the local cache, instead of again requesting the server for data (the publication is smart enough not to click on the client repeated data).

However, the advantage here is lost, since you stop subscribing, so every time the user enters the same search term, the data is clicked on the client again (at least the event added by the cursor fires again for each document), In this case, I expected that pub / sub will be on an equal footing with Meteor.call.

If you want to cache pub / sub data, one way is to take out sub.stop (). But if your users don’t see a search for similar terms, data caching is actually worse, because with each letter that the user enters more data, it will be stored on the client, it may never be seen again (if the search is not such an important function in your application, which user will benefit from this?).

Overall, I don’t see much of an advantage using pub / sub methods on top of Meteor methods, although I don’t understand Meteor well enough to offer more specific advantages / disadvantages between them. I personally believe that Meteor methods look cleaner, though.

If you are trying to implement a search function, I personally like the easy-search package, which supports this type of server-side search with autocomplete. In any case, I hope you solve your question! I am also interested to know the answer.

+5
source

Source: https://habr.com/ru/post/1204138/


All Articles