Essentially, we want to take the same approach D3.js does with marrying data collections to dom collections. You want to make changes transactionally. Matching data collections to views has been a pain from the get-go. We don't want to naively re-render everything -- the way that most Backbone devs handle this. We want to take a document manipulation approach instead. DOM selections should be broken down sub-selections with associated data available: * enter() (additions) * exit() (removals) * update() (moves/changes) ...this breakdown is just about right, since you want to animate additions, removals and moves differently. ListView's `list` element should not be thought of as a single wrapping element, as we handle it now. Instead, we should store the jQuery collection and compare it to the data collection that comes in. It might make sense to create a whole new type of view class for this, since Backbone's views are single-element-centric.
We've now got an OOP approach to this set up -- the views() array on ListView. It solves the problem with encapsulation rather than expressive collection manipulation, but it works. If we're going to re-approach this, it should be part of planning a larger functional architectural change. Closing.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.