If you look at the itemsPerRow calculation you can see that for listview it is always 1. For grid view it is a calculation that relies upon clientWidth.
When you navigate from a list to a detail page for example, the virtualscroll element is hidden so clientWidth changes to 0. When you navigate back to your list you get a scroll to a random location and don't benefit from the view cache as the change in itemsPerRow from x to 0 and back to x as the virtualscroll element goes visible -> invisible -> visible again causes a change and invalidates the cache.
Only applies when the private _itemsPerRow is already a value greater than 0.
Have tested in a couple of my own apps and it's working great now when I navigate back from a detail view with gridlist enabled I get the cached view exactly as it was which is perfect! Have not seen any issues or side effects and wouldn't expect to as this only catches the case where clientWidth goes to 0, in which case the old logic would show nothing anyway.
Resolves #32
If you look at the itemsPerRow calculation you can see that for listview it is always 1. For grid view it is a calculation that relies upon clientWidth.
When you navigate from a list to a detail page for example, the virtualscroll element is hidden so clientWidth changes to 0. When you navigate back to your list you get a scroll to a random location and don't benefit from the view cache as the change in itemsPerRow from x to 0 and back to x as the virtualscroll element goes visible -> invisible -> visible again causes a change and invalidates the cache.
Only applies when the private _itemsPerRow is already a value greater than 0.
Have tested in a couple of my own apps and it's working great now when I navigate back from a detail view with gridlist enabled I get the cached view exactly as it was which is perfect! Have not seen any issues or side effects and wouldn't expect to as this only catches the case where clientWidth goes to 0, in which case the old logic would show nothing anyway.