Article: Managing Publications & Subscriptions With Query Constructors

Our latest article is all about Query Constructors. What’s that you say? You’ve never heard of “Query Constructors” before?! Read on to find out what you’ve been missing… ; )

Love that it’s a sweet pattern to deal with query selectors, hate that it means additional files/places you need to write/change code for a view.

Thanks for another great article Sacha.

Hey Sacha, thanks for the article – that’s definitely better than spreading the query logic over your code base. Why not just add the “query constructor” as a simple API to your collections:

Posts.latest = function (limit) {
  return Posts.find({}, sort: {sort: {createdAt: -1}, limit: limit});

Just share the collection on client and server and you can use this API in any number of places like subscriptions, queries or even your “views” concept.

Yeah, that’s a good way to do it too, in fact that’s how Tom does it. I might transition to that syntax too.

1 more thing, I already answered same question few times and that is selector/projections constructing best practices.

I am using this approach. Is it the best or you suggest some other way ?

insertedObject = {}
insertedObject[“price”] = itemPrice;
insertedObject[“name”] = itemName;
if (!! itemNote ) { 
  insertedObject["note"] = itemNote ; 

I would say defining best practices for these usecases would be great addition for people learning.

In your post you described how it behaves when all parameters are mandatory, what is not always the case.
This way it can extend your approach to optional arguments also.

And yes, some people have problem understand that selector/projection is still defined by object and you can construct such object in advance.

Let me know if you write something to sum it up, or I can if needed.

Actually the way I deal with optional arguments in Telescope is to have a loop that iterates over the parameters object (the one that contains find and options) and applies callback functions successively.

Each callback function takes in parameters, modifies it (or not), and then returns it.

It might be overkill for most apps, but for Telescope it’s really useful because it means you can add and remove callbacks without having to modify the actual query constructor function.

Yes, as long as server side goes.

But I can see how people will be asking "how to prepare this parameters object with optional arguments on client based on user inputs?"
Where it would be nice to have some suggested way :smiley:
Plus get it in that form from Autoform as it is most used “dropdown search thingy”.

And I was splitting all our LESS to separate package 2 days ago after seeing Telescope repository :smiley: