Kristian Dalgård

So. There are duplicate nexuses that involve the same binding-element pair, and each time Meteor reconnects, one more pops up. If you set a breakpoint inside `bind`, is it triggered...

Btw, you can filter the global nexus-list by passing in the element in question: ``` js // $0 refers to the currently selected element in dev tools ViewModel.Nexus.find($0); ```

How about this? ``` js temp1 = some_superfluous nexus; temp1.view.nexuses.indexOf(temp1) >= 0; ```

Right, so it simply isn't unbound – back to square one ;)

It is important that `unbind` isn't called twice when `bind` is. It must have something to do with some detail in `onRefreshed`, `onDestroyed` or `onInvalidate`. One of those hooks must...

Right. So the view's `onViewReady` hook calls the `bind` function of both the old and the new nexus. That makes sense. That means `unbind` ought to somehow unregister `bind` from...

The weird thing is that this problem only occurs sometimes. There must be something special going on with `onViewReady` that differs in your case.

The `vm-bind-id` attribute should change every time the view is refreshed – it is expected behavior. It's the only way the `{{bind}}` helper can be used in that special way...

Other places that would be interesting to inspect are `view._callbacks` and `view._domrange.attachedCallbacks`.

I've continuously profiled the usage examples for memory leaks and made sure there wasn't any, so I'm surprised that the library is bleeding nexuses in your case. But I guess...