Single page apps and "fast switching"

gistfile1.txt

"broad question: how does fast load work? site is a one page app, switches categories similarly, but no URL relation."

https://twitter.com/drewdil/status/452228299150721024

So you want to change views client-side with support for urls and history. You definitely want to use a library. We use http://backbonejs.org/#History. There are lots of others and it comes built into a lot of frameworks.

It sounds like you've already started doing the view switching. It's just javascript and ajax calls. But tying it to a url scheme is more involved. Here's some info that might help.

1. You want to figure out what url scheme you want and tie those to the client-side view you want. For example, in Yammer, each group view has it's own url.

You want to update your app so the views are driven by url changes. Let me explain.

It's easy to do this workflow.

• User clicks a link/button to change views
• Tear down the old view
• Grab some data if necessary
• Render the new view

But this doesn't update the url and in fact it doesn't need the concept of a url per view. Here's a suggested workflow that supports history.

• User clicks a link/button to change views
• This triggers a url change. But it doesn't navigate away from the page. The library ensures this for you.
• An event is triggered that there has been a url change
• This event should kick off the flow that causes the old view to be torn down and the new view to be instantiated
• Grab some data if necessary
• Render the new view

Because the url drives the changes, you can use the back button as normal and it results in the same workflows.

So helpful, thanks Marco.

You want to update your app so the views are driven by url changes. Let me explain.

Another way of doing this and the way I do it is having the URLs not drive the changes (this actually causes lots of weird app state related bugs and if you're interested I can point to some blog articles about this in regards to backbone) but the events or views trigger the change and those view simply update the URL, but the URL doesn't actually trigger anything. This kinda depends on your setup tho, but when possible the workflow I'd suggest is (lets say you're on the /foo page):

• User clicks a button
• The button is triggered to show the "groups" view
• Groups view is displayed
• Groups view tells the browser that its URL is /groups

Now, going back is a URL change just like if you typed in site.com/foo (the page you were at before). The router sees the URL change and will show the proper view for that page.

Example code:

Here is the routes. Whenever the browser sees sees /settings itll call the settings function which renders the settings view. this will happen if you go to site.com/settings or if you click back and that hits /settings.

var router = Backbone.Router.extend({
  routes: {
    "/settings": "settings"
  },
  settings: function (query) {
    var view =  new app.view.Settings({ ... }).render();
  }
});

Now, in the app, lets say you want a button to open that. You'd have like:

app.view.Foo = Backbone.View.extend({
  events: {
    "click .foo": "openSettings",
  },
  openSettings: function () {
    var view =  new app.view.Settings({ ... }).render();
  }
});

So, clicking on a button with .foo will trigger the settings view to load. The settings view will update the URL. This way every section on your site doesn't need to know this URL. The settings view only needs to know its URL.

app.view.Settings = Backbone.View.extend({
  initialize: function () {
    app.router.navigate('/settings');
  }
});

@polotek's method will work as well, but I've found that to be a bit tougher to maintain in the long run.

@OscarGodson I want to hear more about why you think the first method it's tougher to maintain. Obviously I know the app state problems you're referring to because we used to work on them together :) I'm just not sure why you feel they're connected to this method of maintaining urls. In my mind, app state is a general problem with single page apps and the challenges are present in both of these approaches.

Oh, maybe you're referring to having hard coded urls throughout the app. That's definitely a problem when you want to change them. Changing them in one place is great. But you also have to support redirecting from the old form the url.