Update cached heights and `totalHeight`, etc., when item view heights vary, or are dynamic

[mysterlune]

This PR handles the situation in which individual row heights for item views change or have dynamic elements within them (e.g. text fields, accordion-ish views, etc.)

The introduction of the list view's ...heightForIndex(idx) and related methods/properties that enable individual heights per item view is really a huge addition. I hit a case in my own project where I don't actually know the appropriate height for items (images) until after the views all render and the service responds with data. Using the heightForIndex callback, it's simple to feed the correct heights to the list view. However, the cached heights (from the initial render of the list) does not update. Also, the list's totalHeight and the position.ys of all the items remain what they originally were set to on initial render.

This PR adds a cache-busting routine that ensures _cachedHeights recomputes when item view heights change dynamically. Also, in the event of such a change, the totalHeight will recompute as well.

This PR also (I think) introduces the concept of a rowHeight property for Ember.ListItemView and subclasses.

[mysterlune]

Closing this PR since there are a number of issues I just saw that I hadn't accounted for. Will resubmit when things are a little closer to correct.

[kristianfreeman]

@mysterlune I'm attempting something similar to this – curious what kind of issues you ran into?

[stefanpenner]

might be worth trying https://github.com/emberjs/list-view/pull/173 I believe i added support for this their..

[mysterlune]

@stefanpenner, i'll give it a try.

@imkmf, thanks for your interest. one of the main things that is causing me trouble is being unable to know much about views outside the viewport and/or buffer (other than their proto() values from class definition). it's easy to track an item view's dynamically updated rowHeight if it's in the viewport or buffer because there's an actual instance in the list view's childViews and/or positionOrderedChildViews() response. but unfortunately, for all the other n-item views, there's only cached data (e.g. _cachedHeights, _cachedPos, etc.). and the cache, when necessary, gets rebuilt off of the proto().rowHeight values, not the dynamically generated values resulting from possible user and/or binding updates.

for a situation where an item view contains an accordion that becomes isExpanded or something, its own height and the positions of items lower in the list need to recompute and update the _cachedHeights and totalHeight values of the list view. that doesn't seem too difficult until the user scrolls down the list so the expanded view leaves the viewport/buffer altogether and gets re-rendered when scrolling back to it. then the cache is all off and the position y-values are not accurate anymore.

for an item view like this:

  ...
  itemViewClass: ListView.ItemView.extend({
    rowHeight: 200,
    fooHeightObserver: function() { 
      // compute a new height
      this.set('rowHeight', [new height]);
    }.observes('someExternalInfo')
  }),
  ...

... i can only know the itemViewClass.proto().rowHeight, which is fine at first. then, say, someExternalInfo updates and provides the item view with data it needs to compute the height (e.g. a scale factor for "zooming" in and out using a slider control, or whatever). at that point, all views (not just this one) need to have a different rowHeight. again, scrolling the view causes the cache of heights and positions to recompute based on the proto() value and positions are all off.

the case i'm fighting with is where i'm trying to put images (of document pages) into the background style of the item view, and i don't know the image dimensions up front. for my purpose, a document may have many pages of varying sizes. while i know i can fix the width, i don't know what the height of the item view should be until the model for the displayed document returns from the service via ajax. the model contains the height/width dimensions of the full size image, which i then use to create an aspect ratio constrained on the list view's width in the DOM. however, other factors (e.g. sidebar expand/collapse) may update the list view's width in the DOM as well, adding to the multifactorial complexity of updating and caching the correct item view data.

i'm able to get the first few images positioned correctly. also, as i scroll and the item views go out of the viewport into the buffer and beyond, they don't re-render at all. that's probably a different issue, but it's where i'm at.

i might be trying to push ListView harder than it was intended for, given the tall items and relatively short viewport height. i'd concluded that if there was a way to more actively manage the values in _cachedHeights and _cachedPos, etc., based on what views were rendering and re-rendering, then the list view could scale fluidly in height and/or width for its item views and always have an accurate record of their y-positions based on dynamic changes rather than their proto().rowHeight values.

i'd be interested to hear what kind of issues you've been facing, and whether #173 has resolved your issues.

[kristianfreeman]

hey @stefanpenner, @mysterlune – been playing around with this new info and PR this morning/afternoon, thought I'd give a bit of a progress report:

we're also working with variable row heights. it sounds like our implementation isn't as complicated as @mysterlune's, though; we have two pre-defined rowHeight (default and expanded).

i saw a little bit of progress in #173 – updating the listView instance's rowHeight does re-render the view, where it didn't before. the final missing piece is being able to specify different rowHeight based on each row's content. i think i spotted the beginnings of something like this in the multi-height demo. the part i'm having trouble with is actually overriding the listView instance's rowHeight to call heightForIndex. any suggestions there, @stefanpenner? lmk if i can clarify any of this, i'm still wrapping my head around the internals of this project :)

[stefanpenner]

@imkmf heightForIndex should do the trick for you

[kristianfreeman]

ah, that worked! <3 thanks for the help @stefanpenner

[kristianfreeman]

thought I'd update for future reference - I ended up not needing the aforementioned pull request, and heightForIndex was the magic key here. gist with the implementation