Ability to add Animations (transitions) to ListView items

[michaelpelletier]

As a Torso Developer, I would like to be able to add animations to adding/removing listItems, to enhance the user experience.

For the sake of discussing this at the practical level, and trying to capture all of the potential pitfalls, I will be discussing this use case not as simply a list of items in a ListView, but more in the sense of what we’re calling a TableView - an extension of the ListView that also has interaction with other views which act as filters, searches, and pagination to affect what the TableView displays.

I also will say “Remove” referring to removing a row. This does not necessarily mean visually, but refers to changing the row’s data such that it no longer qualifies to be displayed on our table.

Brainstorming and Gotchas

The first way that I attempted to implement something like this without adding to Torso itself was to adjust my code so that when I used an action on the row, it would perform the animations using setTimeout and adding CSS classes. This does not work reliably because delaying the ajax call can mean that it becomes interrupted if the user does something like navigate to another page, or a change that causes a re-fetch of the table can result in trying to perform an action on something that no longer exists.

The second idea was to do the animation after the Ajax call completes. This would run the risk of interrupting the animation (super low concern) but may add other complications as well. There are two scenarios with this approach.

Scenario A) I do not re-fetch after posting changes.

Let’s say my table is set to display 5 items per page. If I remove one of those items, it is no longer qualified to be in our list. By not doing a re-fetch, my table is no longer “valid” - I’m only seeing the first 4 items on my page, not 5. This means that if I change pages, we will miss (at least) one item.

Eg: My table shows items with IDs A, B, C, D, and E on Page 1. We remove C and D, without a re-fetch triggered. When we change to Page 2, it will trigger the re-fetch, meaning that instead of seeing F, G, H, I, and J on Page 2 as the user wold expect, Page 1 would now be A, B, E, F, G, and Page 2 would be H, I, J, K, and L. The user would have never seen items F and G.

Scenario B) I do a re-fetch after posting changes.

This scenario has two ways to think about it. The first is “When I post changes to an item, I also grab the next (undisplayed) item from the list”. This allows you to animate removing the item which has changed, and also still display the item which is replacing it in your view. This allows you to still do animations on the removed item, and doesn’t break the “items per page”. It could potentially be strange as there may be a moment when you’re seeing more items per page than your setting would “allow”.

Eg: I have items A, B, C. We post a change to B that removes it, and when we do so, we also grab D. We then display A, B, C, D, and then animate B disappearing, leaving us with A, C, D, the content we would expect to have.

The second way to view this scenario is “I re-fetch the items for this page, and also prepend the one that I know is going to be removed”. This potentially could change the ordering of your items, or require a resort to “inject” the old row into the right place depending on how your columns are sorted.

The difference between the two of these approaches may be simple semantics, or it may be an implementation detail - I’m including both for the possibility where they’d be different and one would be preferable.

Additional Implementation Thoughts

TorsoViews include the option of using transitionIn and transitionOut (https://runkit.com/torso/view-transitions) for their tracked views. This does not currently extend to ListViews, which do not track their children in the same way (ie: adding an itemView is automated https://github.com/vecnatechnologies/backbone-torso/blob/master/modules/ListView.js#L108 and does not currently include a way to pass a property for specifying whether or not there is a transition.

More than one of the situations outlined above can also fall apart if something else causes the tableView (listView) to render. A render will not persist the item you wish to animate that no longer belongs in that data set. This brought up the idea of possibly being able to “Lock” the TableView.

So, I click an action on a row, the entire table locks. It does the call, animation, and then unlocks. While locked, it would prevent the user from doing something like changing the number of itemsPerPage. This could be a confusing interaction.

It could also lead to a long queue, potentially. Because we’re preventing renders until after the Lock has finished, each new Lock would have to reset that timer. This would mean that if I hid 5 rows pretty quickly, nothing would happen for potentially several seconds.

Some things to think about, at least. Looking forward to more discussions on this!