[nickfisher]

yeah, that was something we struggled with when designing this architecture. The problem is that you don't necessarily know which subviews can be held onto and which are no longer needed, so the only way to generically handle the situation is to destroy all subviews when a parent view needs to be rerendered. This sound horrible and inefficient, I know, but our way to deal with it has been to be very careful about what triggers a rerender.

Views state exactly which attributes on their model should trigger the rerender when they change, and no others. If you have a very high level view which has a sizeable tree of subviews underneath it, then its subviews will probably be the ones actually displaying data and that it will essentially just be a 'composite' view and will never rerender.

Views which bind to collections (eg: Lists) have special logic for adding and removing subviews without rerendering all of them.