Lists get loaded even after navigating away from a page

[mliu7]

When lists of objects are being fetched from the server, it sometimes takes a few seconds so if someone navigates away from the page during those few seconds, the list of objects still refreshes the page once they are fetched. Instead, once we are on the new page, we should stay there and not receive any interference from the previous page.

To reproduce: Click Teams While the list of teams is still loading, click the "+" to add a team. Notice that the list of teams then replaces the add team page once it's finished loading.

[cboulay]

This has to do with binding the 'render' method to the collection's 'reset'. What we should be doing is unbinding everything in a view when the view is unloaded. I haven't spent much time looking into that though because it seems to be a bit further down the road.

[cboulay]

A faster way of dealing with this would be to use two different layouts for the different pages. Layouts are refetched from the cache. In this case both the list screen and the edit screen are using the nav_content layout. The old render method is inserting into a valid container in the same layout after the new render method has already fired.

[mliu7]

A quick fix is to just check what page the view is currently on before re-rendering the page. We can do that using Backbone.history.fragment. This keeps the layout names consistent.

[cboulay]

I started out by reusing layouts because I thought it might be faster if ever we got the app to a point where we could just replace views of the layout instead of navigating to different pages. For example, clicking on a team could, instead of calling .navigate, call a function to remove the 'list' view from the .content area and replace it with a 'detail' view. We aren't using this particular paradigm but we might in the future for something. If we ever use that paradigm, or if we ever decide to not push the URL to the address bar, to switch to pushState instead of using a url hash, or to change the route name, then the fix you are proposing will break.

[mliu7]

Ah, gotcha. Good call. We'll re-open this if end up implementing something along those lines.