0

I have a web app that uses some subtle effects when navigating. Essentially the pages "slide" in from the right.

Everything in the app is based changes to the hash and all that is working great.

What I'm simply looking for is a way to determine if the change to the URL is a "back" action. I'm not going to try to affect the change-- my app already handles that perfectly. I just want to reverse the "effect". In other words, if I know they are clicking "back" I want to slide in from the left left instead of the usual action of sliding in from the right.

Keep in mind I don't need help with the animation itself or keeping track of app state in the hash-- I only need to know how to know if the change is a "Back" action.

Also, I really don't want to keep a list of the hash states in the app as users click around to try and determine if they are going "back". I might consider that if it's really the only option, but I hoping to find a solution that just knows if the user initiated back (Back button, history.go(-1), right click "Go Back", etc).

Is this information available in javascript without explicitly keeping track of changes to the hash?

David
  • 8,340
  • 7
  • 49
  • 71
userlite
  • 479
  • 1
  • 5
  • 13
  • This question suggests a jQuery plugin that seems to be what you're looking for: http://stackoverflow.com/questions/172957/detecting-back-button-hash-change-in-url?rq=1 – Ben McCormick Jan 05 '13 at 19:12
  • Can the person initiate back by clicking back or using an arrow key? – Sam Jan 05 '13 at 19:12
  • @ben336 - I've seen that plugin and while it might help, I'm looking for a non-plugin way. I already have a very light, custom "hash change" handler that I'm using. I didn't see anything specifically in that plugin that says it tells you if a change is "back". – userlite Jan 05 '13 at 19:15
  • @Sam - Any time the browsers "back" function is triggered (if arrows work on your browser then yes). Swiping on tablets, right-click "Go back"-- anything. I'm hoping for a central property or event I can check to know if back was used to get to the current URL. – userlite Jan 05 '13 at 19:21
  • Dans is probably your best option then. Give it a shot. – Sam Jan 05 '13 at 19:23

1 Answers1

0

Use a previous page variable. I'm going to assume that when you are "changing" pages you are doing it through a central function.

In your goto page function

// Try to get the previous page if known (will be 'unidentified' if unknown)
var prevPage = window.previousPage;

// Set this page as the previous before moving.
window.previousPage = 'this page';

// Assume that gotoPage is where we are headed
if(gotoPage == prevPage)
{
    // We're going back!
}
else
{
    // We're going forward!
}

P.S.

I am using the window.previousPage as the general container and using prevPage to compare in scope. This is on by design to limit the number of places you would have to set window.previousPage

EDIT:

Didn't think about multiple going backs, same idea using an array (not tested but this is the general idea)

var prevPage = '';

if( Object.prototype.toString.call( window.previousPage ) === '[object Array]' )
    prevPage = window.previousPage[ window.previousPage.length - 1 ];

if(prevPage == gotoPage)
{
    // Splice out the last entry
    window.previousPage.splice( window.previousPage.length - 1, 1);
    // Going back DO NOT add new window.previousPage
}
else
{
    // Going forward add the previousPage before changing
    window.previousPage[ window.previousPage.length ] = 'this page';

    // Move Page
}
  • this won't work because it will only keep track of going back once right? I need something that would know if you are going back all the time. And I don't want to track the list all the time (unless I have to). – userlite Jan 05 '13 at 19:19
  • This is a good solution if there is no way to just "know" if we're going back from the browser. It doesn't quite solve my problem because it's based on a single previous memory. But I can change it to keep track in a list. My hash tracking function is very centralized so I'll only need to do this in one place. – userlite Jan 05 '13 at 19:26
  • This is true, this only accounts for one going back. You can compare against your own list or the window.history list however be warned that there are reports that IE < version 10 do not support this. https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history –  Jan 05 '13 at 19:27
  • Edited my answer to show how to use the window.previousPage as an array. It's not tested I apologize if there's a syntax error in it, but the general idea is to use the array like a deque, in other words when moving forward add the current page to the end of the array and then go. When moving backwards we want to remove the last element of the array, perform backwards anim and go. –  Jan 05 '13 at 19:39
  • P.S. no window.previousPage doesn't exist natively, we are creating and populating it ourselves –  Jan 05 '13 at 19:41
  • I saw your original code and got excited before I really looked at how it works. Thanks for your help-- I guess I'll be tracking "back" in my code. – userlite Jan 05 '13 at 19:47
  • Well if you don't care about internet explorer users (who really does anyway? lol) then use the window.history object. That DOES contain lists of the tab / windows recent activity. –  Jan 05 '13 at 19:58
  • Yeah I wish. We just lost a job this week because our intranet site wasn't working in IE. Ironically the bug was a special case fix to support IE6 which was now breaking things for IE10. So I guess we get to have fun with IE forever. – userlite Jan 05 '13 at 20:08
  • Ouch, sorry to hear it. I normally deal with more profit driven clients. Numbers are everything to them, couple case studies across the net and it's pretty easy to get them not to care about IE either ;) –  Jan 06 '13 at 17:54
  • It would be interesting to see the case studies you're referring to. All the research we do internally shows IE as being relatively significant portion of traffic and ecommerce sales. While IE (older versions in particular) have been difficult to accommodate, we've never regretted supporting it (from a profitability standpoint). – userlite Jan 06 '13 at 18:54