Use Symbol as topic, instead of string
caiovaccaro opened this issue · comments
It is very clear in the Wiki that the postal.subscribe(options.topic needs to be a string. But it would be wonderful to be able to use ES6 Symbols as topics, because of its immutable nature. Any way to make it work?
Would be great to have that indeed, symbols are always unique, it would prevent unintentionally setting the channel equally to one that already exists.
👍
Wouldn't that undermine the typical use case of postal.js? You subscribe to topics not caring where they are being fired from and operate on them. But if you use Symbol now you have to share Symbols in order to publish and subscribe which seems undesirable in postal's case. In my opinion anyway.
I have used postal.js in several projects, based on experience it only makes sense to use ES6 symbols instead of strings once the application channels and topics have been "locked". This helps to enforce and prevent abuse of the pub/sub within the application. However, in applications where the architecture is still evolving, it's much simpler to use strings to prototype channels and topics needed by the application. One limitation of using symbols is that you may not be able to use wildcards to subscribe to topics (you can still create a symbol for that but it may not be intuitive to the developer). A pragmatic approach would be to use both.
Since Symbol is unique in order to successfully use Symbol you would have to create a common place where all of the Symbol instances can be accessed. This ruins any separation you originally had as everything is now intrinsically dependant not only on this single location but that the Symbol instances are created before anything else attempts to use them.
I have no idea why you'd use a publish and subscribe pattern at that point and I'm not sure how Symbol prevents abuse here. Might as well turn it into a common library. I don't think it makes sense to use Symbol as a channel in postal (I know I'm not supporting it in msngr.js).
I completely agree with @KrisSiegel . You use a pub/sub library like postal to seperate publisher from subscriber. When using Symbols, you would suddenly have a coupling between publisher and subscriber.
And just like @antonioaguilar allready pointend out: using symbols will also make wildcards a tad more difficult. You'll be writing on(Symbol('simething')+'.*'.+Symbol('some other symbol')).
If managing topic names (with duplicated) and a clash in those names is the problem, using Symbol's is not the solution imho
I know I'm weighing in on this late - but I greatly appreciate the thoughtful discussion! The intent with postal is to separate publisher and subscriber, so I agree with @antonioaguilar that it wouldn't make sense unless you had a legitimate need to "lock" your channels/topics down. Having symbols-as-topics isn't something I'm actively planning to work on, but if it ever comes about, it would likely be an opt-in/plugin-based approach.