It’s been a little while since I’ve taken a look at JZ Publish/Subscribe, but recently I had a great idea to fix a problem I was having trouble solving. Mix that in with a few more bits of context capability and you have the version 1.3 release of JZ Publish/Subscribe. Go ahead and read a little more to get the scoop on this great idea and how it will make using JZ Publish/Subscribe more stable.
What’s Changed?
There are two big changes in this version of JZ Publish/Subscribe. Before I get around to talking about “the great idea,” I’ll talk about the changes with context. In version 1.2 I introduced the ability to specify an object on which to apply the callback, which I called the context. The problem was that I didn’t take into consideration that you might subscribe a callback to a topic multiple times, but with different contexts for each one (or maybe no context was specified for one or more of the subscriptions). So, if you tried to unsubscribe a callback from a topic, it would unsubscribe the first occurrence of that callback and topic combination, without checking to see if the context was correct. In 1.3 I added a context parameter to $.unsubscribe and made it check to see if the context matched too before unsubscribing something. Along with adding a context parameter for unsubscribing, I also added a context property to the handle returned from $.subscribe.
Now for the “big idea”, but before I can tell you how my idea works, I have to explain why it helps. I realized that in some situations a callback should only be called once (or until some criteria is met) and then it will be unsubscribed. Generally, the callback is designed to unsubscribe itself. This is bad news. Why? Well, the unsubscribe call will take place before the rest of the publishing to that topic is finished, which will shrink the collection of subscribers to that topic. If a collection shrinks while $.each is still iterating through it there will be an error because the length of the array is cached at the beginning of the iteration, so it’ll try to continue iterating beyond the end of the array. Not only that, but since the subscription that was just called is removed, the next one fills in the hole that it left. The iterator then moves on to the next subscription and skipping the one that filled in the hole.
So here’s my idea: while we are still publishing, all requests to $.unsubscribe will be thrown into a queue. When we’re finished publishing, we run through that queue and handle all of the unsubscribes. Okay, that’s not a BIG idea, but I thought it might be a pretty nice addition to the plugin. At the very least it makes the behavior predictable and stable, which is always good.
Show Me The Plugin!
As usual all updates to the plugin can be found on the JZ Publish/Subscribe project page. You can find the download link, documentation on usage, and version history all listed on that page. If you find any bugs – I really hope you don’t because I tested this version more than any other before it – just throw a comment at the bottom of that project page. It’s not a big project so I don’t think a more thorough ticket system is required right now. Anyway, I hope you like the update and Happy Coding!
