RelaxedSignals are an addition to the popular signals library of Robert Penner.
It’s still in pull-request state, and hopefully it will make it into the official lib sometime soon.
In the meantime you can download it here:
Signals are great but there’s one feature that’s really missing: the ability to subscribe to a signal, after it has been dispatched.
There are several use cases in which that’s very useful and all of them have to do with async processes:
One of the typical hurdles with async processes using standard signals is that you need to have some kind of checking mechanism to find out whether the process has already finished; if so, pull the data from the process, and otherwise you need to subscribe to the completion signal of the process. But there’s an extra catch.
Sometimes if the process is really fast, it will be over BEFORE the interested parties have been able to subscribe to the completion signal. To solve that you have to subscribe to the signal before starting the process, which can lead to early instantiation of a lazily instantiated object or can complicate your setup process.
And if you’re like me, you want to make your process listeners synchronicity type agnostic. I think a listener shouldn’t have to care whether a process is synced or not, this allows for far greater freedom. That way (if you’re using interfaces, of course. And you should!) you can swap an async process for a sync one and your listeners won’t know the difference.
All of this is possible with standard signals, however it can get cumbersome to set up and racing conditions are almost always a problem.
RelaxedSignals solve all of the above difficulties.
Whether the process is async or not, whether you like to inject a completion signal into the process or prefer that process returns a completion signal, it will never be too late to subscribe to that signal, because if it has already been dispatched and a new listener subscribes to it, it will automatically notify the listener that the process has already ended.
RelaxedSignals are to be used exactly the same as standard signals. No differences whatsoever.
The only difference is in functionality; whether your listeners come late to the party or not, they’ll still enjoy the music. (That’s corny, I confess)
I put together a very small demo, which I kept really simple, where you can clearly see how everything still works even after the process has ended.
So, what happens exactly?
1/ A command triggers a service method
The service does it’s magic and dispatches the completion signal (in the demo it’s a synced process, but that doesn’t matter at all)
As you can see, the successSignal is immediately dispatched, since it’s a synced process.
Then, a mediator, which is created long after the service has finished (since it’s view is only created after clicking a button) listens to the same signal to pass the payload to it’s view
That’s basically it.
Now I can easily create a new service, which loads an xml file for instance (ie. async) and nothing needs to change except the mapping of
to the new service, for instance