New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add onDispose method #276
Add onDispose method #276
Conversation
It seems the name is misleading, as the method actually returns another "wrapper" observable. Right? |
If we were to implement an onDispose method that doesn't require you to wrap the observable, that would require some kind of a fork in the Dispatcher. And that might indeed be a more useful / general-purpose method. Might add nicely to the visualization/analysis tools discussed in #273. |
Yeah, naming is not so good. How about withDispose? We could do a "pulling" variant of this as you suggest in the style of On Thu, Oct 31, 2013 at 8:45 PM, Juha Paananen notifications@github.comwrote:
|
@philipnilsson the "pulling" variant must not force subscription, of course. That would defeat the purpose. Instead it just just observe the lifecycle of the stream by plugging into the Dispatcher mechanism. I'm also a bit concerned about the actual Hence, this is not necessarily the mechanism you'd like to use to free up resources. I'm not sure what kind of resources you're talking about, but shouldn't they be reserved again if a new subscriber re-activates the stream? Maybe we should introduce a pair |
Are you talking about the "spy" feature? Yeah I never really use the fact that you can go to zero subscribers and up On Fri, Nov 1, 2013 at 7:21 AM, Juha Paananen notifications@github.comwrote:
|
Well yeah, these new suggested methods would probably be useful for debugging/analysis/visualization in combo with |
@philipnilsson are you planning on taking this further? I'm considering closing this for now, unless there's gonna be activity. |
Depends on if the new changes in .7 affects this. I could try to write a |
Now that 0.7 is out, and new year 2013S and all, we might consider getting back to business with #273, i.e. allow observing the lifecycle and content of all streams without them knowing. Maybe something along the lines of Bacon.spy (stream) ->
stream.spy {
onEvent: (event) -> console.log "event", event.toString()
onActivate: -> console.log "stream active", stream
onDeactivate: -> console.log "stream inactive", stream
} Where |
A convenient method for cleaning up resources allocated when creating an Observable. I use this all the time, figured it's a candidate for core. I'll complement with tests if we want to include it.