Repository navigation
Consider allowing Generic Trigger Keys #18
Description
Something like
const enum TriggerAreas {
Foo,
Bar,
Baz,
Cat
};
type TriggerKeyType = string|MyObject|TriggerAreas;
export class MyStore extends ReSub.StoreBase<TriggerKeyType>{
...
// Trigger for enum, string and a complex object are fully typesafe
this.trigger([TriggerAreas.Foo, 'fooitemKey', fooObject]);
...
}This would allow passing anything a developer wants through keys and allows more documentation context to be gathered from the specified trigger keys.
Activity
erictraut commentedon May 16, 2017
IMO, this is one of those cases where keeping it simple (restricting it to strings and numbers) is preferable. Just my 2c.
FrogMonarch commentedon May 17, 2017
I like the added documentation and typesafety around specifying the space of trigger keys. We can add the restriction that
TriggerKeyType extends string|numberso the behavior is the same and it is not a breaking change. [Note:MyStore extends StoreBasedoes not need<>since TypeScript now infers the defaultstring|numberfor you.]Someone might want support for Symbols to avoid namespace collisions with specific and arbitrary keys. We don't have that problem since our keys are usually in a predefined format so we can make our special keys different (e.g. guid vs 'FooToken'). This would be more of a problem for subscribing to arbitrary numbers (e.g. id) and having
const enumof special keys (e.g.TK.NoneId).Actually,
Key_All = '%!$all'is a good candidate for a Symbol.