v0.4.0

List View naming convention change to Item View

A major List View naming convention change happened. The wording of child view means a view that any view (including a list view) might own. List Views always had the ability to both own auto-generated views and other classical child views. However, due to treating these types of views as the same, inconsistencies in logic occured (e.g. this.hasChildViews() while checking if there were any autogenerated views). Therefore, a new name was needed to differentiate the auto-generated child views of a list view and other child views it might have. "Item View" was used. Like a Perspective View, there is nothing particularly special about this type of view but more a label given to help understand it's role and lifecycle.

Thus, some arguments, fields, and methods in the list view were updated including:

Fields / Initialization Arguments:

NOTE: using the deprecated names as arguments during initialization will still work, however references to them afterwards (e.g. listView.childView) will no longer exist but rather only referenced as there new names (e.g. listView.itemView)

• childView -> itemView (the view class of the auto-generated views)
• childContainer -> itemContainer (the injection site of the auto-generated views while using a template)
• childContext -> itemContext (the object or function result that's passed to the item view's during initialization under the name "context")
• childModel -> modelName (the argument name of the model when initializing an item view, defaults to 'model')

Methods:

• getChildViewFromModel -> getItemViewFromModel (getting an item view that corresponds to a model)
• any private methods (prefixed by "__") containing the words "child" were updated to use "item". __createChildViews, __createChildView, __removeStaleChildViews, __emptyAndRebuildChildViewsFragment, __generateChildArgs

Note: aliases were provided for backwards compatibility for the following methods. These methods are now deprecated in favor of their "item" equivalents:

• getChildViewFromModel
• __generateChildArgs

Collection reset and sort optimizations

Collection reset

A collection reset effectively forced a re-render in order to make sure all item views were placed correctly on the DOM. This meant detaching, rendering, and attaching all the item views. In 0.4.0, the view will inspect the models removed and added as part of the reset. If the number of additions and deletions is half of the number of new models that would have to be rendered, the list view will add/remove these item views individually, instead of invoking a re-render. This threshold can be changed by setting:

this.updateThreshold

NOTE: because the calculation puts the sum of the additions and removals over the resulting size that it would render, the threshold value can be greater than one. If you would like to always update using adding/removing instead of re-rendering, make the threshold value Number.MAX_VALUE

Collection sort

During a sort, the elements were always rearranged even if the order never changed. Now, in 0.4.0, the list view can identify if the order hasn't changed, and not manipulate DOM.