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.
Wouter Soudan rhythmus
rhythmus
/ query-collections.md
Last active
November 28, 2015 04:35
— forked from Sewdn/query-collections.md
Query Collections
rhythmus
/ project-builds.md
Last active
August 26, 2015 00:51
— forked from Sewdn/project-builds.md
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.
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.