Open b-ma opened 3 months ago
Why not keep the whitelist
(and maybe blacklist
) for the subscriptions? constraint
sounds more like a requirement to me. (If constraint' is to be used, do not forget the
s`.)
Is there a way to integrate that with the filtering of attributes, to get only a subset (regardless of their values)?
filter
rather than constraint
Actually the dynamicFilter
behavior is not very relevant as we already have the SharedStateCollection#filter
method. This would also create problems such as how to be notified when the collection change, etc.
For now, let's just stick with something like:
stateManager.getCollection('test', {
whitelistParams: ['a', 'b'],
backlistParams: ['a', 'b'],
filterStates: (currentValues) => currentValues.group === 'group-1',
});
options
could be:Generalize existing parameter filtering feature (apply to
SharedState
andSharedCollection
):whitelist
- same behaviour as currentfilter
argumentblacklist
- inverse ofwhitelist
Allow to model some hierarchies / relationships (apply to
SharedCollection
):contraint
- arbitrary function to filter the states that live in the collection, could be useful e.g. to model sort of simple "join"This could be quite simply done on the client side, just detaching early from the state if the value does not match, or even by propagating init state values in
OBSERVE_NOTIFICATION
to avoid additional network roundtrips.The constraint could also be a pure facade, allowing to insert / remove a state from the collection when one of it's param changes and match the constrain... to be discussed
Maybe provide both behaviours:
staticContraint
- check is done only on init values when the state is created (better in terms of network load)liveContraint
- The state is attached but added / removed from collection dynamically at any momentWould also benefit from #93