gmac / backbone.epoxy

Declarative data binding and computed models for Backbone
http://epoxyjs.org
MIT License
615 stars 89 forks source link

Collection binding results in first collection entry beeing removed #49

Closed jhohlfeld closed 10 years ago

jhohlfeld commented 10 years ago

When I use an list item view, which itself is rendered using model binding, the collection happens to delete the first model-view when the corresponding model changes.

I identified this code section (around line 591, in collection.set()) to be responsible for this behaviour:

            if (isModel(target)) {

                // ADD/REMOVE Event (from a Model):
                // test if view exists within the binding...
                if (!views.hasOwnProperty(target.cid)) {

                    // Add new view:
                    views[ target.cid ] = view = new collection.view({model: target});
                    var index = _.indexOf(models, target);
                    var $children = $element.children();

                    // Attempt to add at proper index,
                    // otherwise just append into the element.
                    if (index < $children.length) {
                        $children.eq(index).before(view.$el);
                    } else {
                        $element.append(view.$el);
                    }

                } else {

                    // Remove existing view:
                    views[ target.cid ].remove();
                    delete views[ target.cid ];
                }

            } else if (isCollection(target)) {

As you can see, when a model is coming through the target parameter rather than a collection, it is removed if it's already present in the view list - which is the case for an initialized collection.

This is only reproducible with the first model/view pair in the list - all other list models are updated properly, the event not beeing triggered.

I'm not familiar with the innards but I suppose the event which is triggering the run through collection.set() is probably unwanted or misguided. Removing the isModel() block fixes this issue, however I'd rather prefer to know why exactly it's there in the first place.

Please could you explain this a bit?

jhohlfeld commented 10 years ago

Alright! This has obviously been fixed with the latest changes from the master baranch. Have been using tag 1.0.2. The only change I see is the cached/restored dependency graph. So maybe some 'dependency graphs' stumbling across each other.. anyone to explain this to me?