Why does a reSlice occur on every 'change' event?

[bryanspears]

Shouldn't it only reSlice/reset on sort/add/remove?

If you have a paginated collection rendered as a collection, the view is re-rendered every change. This causes a large number of visual issues if there's any animations, hover/focus effects, etc.

Example: I have a row, clicking the row selects (boolean that triggers bindings in the view) the row. However, the hover effect flickers on every selection because the entire table (collection) is being re-rendered by the paginated collection emitting a reset.

[wraithgar]

My gut says you're probably right. The initial idea was that a reset was the only response to an event we would ever use, arrived at after a lot of iterations. Once this was separated from the filtering functions, all we ever have to do is re-slice. The assumption to do it on every event however seems to have been an oversight. I can't think of a reason to do it on change event since any change event that would also trigger a change in that model's membership in the parent would also trigger an associated add/remove/change.

However, this will add a layer of complexity that we'd gotten rid of by this approach: bubbling up change events. This was something we don't currently have to worry about since the reset handles everything. This will mean doing much more expensive calculations of whether or not the event is from a model currently in our active 'page'. This was another thing the 'reset is the only event' was giving us. It now becomes a judgement call between the cost of those calcuations vs the cost of re-rendering.

Re-rendering should be inexpensive if you're using renderCollection however, since views in renderCollection are cached (iirc). The flicker is likely due to the fact that a reset causes the parent view to empty and re-fill w/ the (already rendered) views.

So shooting from the hip here, if someone were to tackle this I would think that first they should see if there is a more elegant solution in renderCollection for handling a reset (which doesn't involve nuking the parent view each time) and if that proves impossible then attempting to refactor this module to start tracking state of membership of parent models in itself (which is expensive).

Hope this helps explain how we got where we are, and maybe where we can go from here given this observation of yours. Thanks for getting the conversation started!