Conditional Publications - "continue with this publication if the predicate is passed"


#1

A package which does the following:

//vanilla
Meteor.publish('nameOfSub',fn2);
//conditional
Meteor.conditionalPublish('nameOfSub',fn1,fn2);

fn2 is the standard publication function, and is only called if fn1 returns true.

fn1 is the predicate function which is given one argument: subsArray. The subsArray passed to fn1 is an array of currently active subscriptions for that connection with the same name; 'nameOfSub' in the example above.

Usages

  1. Checking arguments. This would allow us to separate publication logic from check or Match and other checking logic.

  2. Checking for enough change. When the arguments to a publication fall on an approx. continuous spectrum (e.g. geolocation coordinate pairs), usually we do not want to republish a data set if the input parameters change by a very small dX. So, we can check in the predicate function if the current input parameters differ enough from the previous ones.

  3. Checking for enough change in non-reactive queries. For non-reactive publications, (e.g. aggregate queries), it is common to have a notion of change/distance, which should be used to determine if we should rerun the aggregate query (e.g. if the timestamp differs by less than 1 hour, don’t rerun the query, since our data’s ~period of change may be 5 hours)

Of course, you can do all of this using the vanilla Meteor.publish, but I think it is more pretty/readable to separate all predicate logic from the publication logic.

I was thinking about writing this package. If anyone is interested in this package or wants to work on it too, let me know. If you have a better design approach, please let me know.

Thanks!


#2

This looks to me like what you actually need is middleware around publications or something.


#3

yes, I think I posted something a couple months ago about it with the
middleware diction, but it didn’t seem to get a ton of responses.

really, it can be as simple as a predicate function, but middleware I guess
is pretty much that.

I recall one of the MDG working on a throttling mechanism for methods,
which seems related. but that actually didn’t get a hugely positive
response iirc.


#4

It would be nice in a Promise-style cascade :slight_smile:


#5

hmm, it would be nice, but I think meteors style is pretty
(pseudo)synchronous, and it would go against the rest of the frameworks
feeling.

honestly, i think adding middleware structure in general for all types of
client server interactions would be super useful. in methods, directly on
pub/sub, then the community could implement their own features like
throttlers, etc…