feathers-plus/feathers-offline-realtime

Can `publication` and `query` be combined in some user cases?

eddyystop opened this issue · 0 comments

publication: data => data.username === 'john';
// or
publication: clientPublications.addPublication(feathersClient, 'messages', {
  module: commonPublications,
  name: 'query',
  params: { username: 'john' },
});

Is what actually filters the records both for snapshots and service events.

query: { username: 'john' }

Is used to return a minimal number of records during the snapshot. This is for performance purposes. options.publication still filters them further.

Having both publication and query is ugly. Can we specify just one in common use cases?

Idea #1: If we have options.query but no options.publication , can we could set options.publication = require('./commonPublications').query(options.query). This does not handle communicating the publication to the server. We'd have to call clientPublications.addPublication(() to do that, and trust the server Publications = {} contains commonPublications.query. Further how do we knoe the user wants the server to do filtering as we cannot have a isServer option.

Idea #2: Such defaults are confusing, fragile and awkward to document. Let people get used to specifying both options.query and options.publication.

I'm for #2 ATM.