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.