Skip to content

Instantly share code, notes, and snippets.

Wouter Soudan rhythmus

View GitHub Profile
rhythmus /
Last active Nov 28, 2015 — forked from Sewdn/
Query Collections

Query Collections

How to reactively change a resultset when a query’s parameters change


A query defines a set of conditions on a collection of documents. Most of the time, only the documents that meet these conditions need to be published to the client. In many cases the query’s conditions are subject to the state of the application (for instance the selected sorting field). This pattern describes how to update your query’s result set reactively without losing the cursor’s state. This way, results are preserved over different adjustements of a query if they meet both set of conditions.

An example case



Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to orchestrate your builds for different use cases? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

You can’t perform that action at this time.