Enhancement: sticky events support about pubsubjs

[dazinator]

+1. I have many widgets on a page. If one widget publishes an event, prior to the second widget being loaded, the 2nd widget will subscribe afterwards and will have "missed" the event.

One solution to this would be "sticky" events as suggested.

The only other solutions I can think of:

1. Create an intermediate dependency that both widgets depend on, and which will mediate the pub sub order.
2. Ensure that all subscriptions occur before some event (like DomReady) and all publishing occurs after that event (i,e the page is fully loaded so all widgets have had a chance to subscribe to topics)

I think I'll go down the path of 2) whilst this sticky event feature is not available.

[mikkokam]

Sounds like a queue / csp style for some use cases: a publish (put) waits for a subscriber to act (take). But js-csp and others are not pub-sub, not about broadcasting, - one take removes the message from their channel, so others won't get it.

Broadcast "playback" of message implementations -- the sticky message would need decisions about size and age for a buffer, and how messages should be removed / A login event is stale if there is a logout event after it.
One of the internet-based pub-sub implementatons (PubNub) has a playback, I think.

One easy way to tackle this with the existing PubSub implementation: For state -like use cases (login state) one might use a service (singleton) holding that state for everyone joining in later: the service subscribes and holds the state, others read it directly.

[dazinator]

@mikkokam thanks for this. I ended up finding an alternative library that does all I need. It only keeps the "last" message that was published in terms of sticky messages, so it doesn't queue them up, but this is all I need, and is probably less worrying from a perf perspective. https://www.npmjs.com/package/radjs-publish-subscribe

[mikkokam]

@dazinator seems like a good candidate , thanks for the link!

I've been using the last option of the ones I listed; services as state holders and having them subscribe to 'persistent' messages.

[mroderick]

Thank you for your comments and for sharing tips for solutions!

I don't think sticky events is a good feature for PubSubJS. If this is something people really want, then I would suggest that they implement it in a fork. StickyPubSubJS.

I am closing this issue