Consider allowing Generic Trigger Keys

[berickson1]

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.

[erictraut]

IMO, this is one of those cases where keeping it simple (restricting it to strings and numbers) is preferable. Just my 2c.

[FrogMonarch]

I like the added documentation and typesafety around specifying the space of trigger keys. We can add the restriction that TriggerKeyType extends string|number so the behavior is the same and it is not a breaking change. [Note: MyStore extends StoreBase does not need <> since TypeScript now infers the default string|number for 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 enum of special keys (e.g. TK.NoneId).

Actually, Key_All = '%!$all' is a good candidate for a Symbol.