Routing after a page reload.

[vlhardy]

Hi. What are the possible ways to implement the routing after an user refreshes a page? In most cases a server will return '404-Not found'. Please advice.

[paulmillr]

mhm? The router itself is built with purpose that if user reloads page, things should look the same (or almost the same, depending on state).

Do you mean that you're using some custom server that doesn't support pushState?

[vlhardy]

I'm using nginx. I installed the latest facebook sample application. When I refresh 'Wall Posts' page in chrome (for me it generates url like 'chaplin.moviepilot.com:85/posts') the server returns 404.

[paulmillr]

you'll need to rewrite your nginx paths to point everything except static assets to index.html.

Or you can edit application.coffee and add pushState: no at initRouter line.

[vlhardy]

Not so clear about nginx - do you mean I need to map all possible routes to the index.html? Also can you please be more specific where to add the pushState: no in the code?

[paulmillr]

do you mean

yep. that's the thing with pushState API.

can you please be more specific

https://github.com/chaplinjs/facebook-example/blob/master/coffee/facebook_application.coffee#L31

@initRouter routes, pushState: no

[vlhardy]

Thank you for advice. I applied the initRouter case and it worked. I noticed one thing - when I naivigated to a specific like (url looked like '#likes/123690647667832') and did a refresh, the like did not update, the 'Loading…' was displayed instead. Is that a bug or I'm doing something wrong?

[paulmillr]

not sure about this. @molily ?

[molily]

@vlhardy: pushState is on by default. See the Backbone documentation and also these background articles:

https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history http://diveintohtml5.info/history.html

In short, pushState “fakes” the URL which is shown in the browser address bar. It’s possible to set an arbitrary URL, it does not need to be a URL which actually returns a document from the server when dereferenced using HTTP.

The idea behind is to provide normal URLs which denote bookmarkable, sharable, accessible resources. This is what’s the best solution for the web ecosystem in the long term: JavaScript web apps that save their state in normal URLs which are – at the best – accessible to all devices. Of course that’s an ideal and you probably don’t or do not have to care about search engine accessibility etc.

As a simple solution, you can:

• Disable pushState and therefore switch to hash URLs
• Or: Route all client-side routes also on the server-side so at least the JS app starts up when a user visits the app URLs

[molily]

@vlhardy I’m closing this, feel free to ask again if you need some advice.

[vlhardy]

Paul and Mathias, thank you for for the fast and detailed answers.