Kristian Dalgård
Kristian Dalgård
Nice find!
I may not be able to look into it more until tomorrow, but I'm sure we will be able to fix this within a very short timeframe.
I think it's an interesting perspective that we might be dealing with a race condition. Is it always the exact same elements that get the duplicate bindings?
If I understand you correctly, it is _not_ always the exact same set of elements that gets affected?
My guess is that `Meteor.reconnect()` triggers a Tracker flush, which coincides with some or all elements being in a temporary state where the `onReady` or other event are _supposed_ to...
If you set a breakpoint on [this line](https://github.com/dalgard/meteor-viewmodel/blob/master/packages/dalgard_viewmodel/lib/base.js#L64) and look in the call stack, does that part of `onReady` ever get called directly by the `Nexus` constructor, or is it...
For sure, it could happen in other scenarios – thanks again for taking the time to debug this. I'll look into the reason why `do_unbind` evaluates to false. The `{{bind}}`...
The `nexuses` list on the view is only for debugging and doesn't affect the bindings.
It's weird if it returns `false`, but those two lines have no bearing on the bindings themselves, they only track what is currently on the page for debugging purposes.