Assuming I have an arbitrary point in my history (the point someone lands on my page), I would like to push some states as they do certain actions, and then when they are done I want to go back to the history point they were at when they landed on the page. So if they press forward, they are starting the actions again, and if they press back they go back to wherever they were before they landed on my page.
Now the problem is when I push states and then at one point they press back. E.g.
landing page
push state 1
push state 2
back
Now at this point if I want to return them to the landing page I only have to go back once (as opposed to twice). How do I calculate how far to send them back using javascript? It seems that history.length is pretty inconsistent, and using history.js' saved states doesn't work since a state gets added to that regardless of whether I use push state or whether they click back.
Any help is appreciated.
If you want to go to a particular url,just redirect to the specific url using window.location.replace(url).
In your case, on all page loads,increment a counter which is kept in session variable so it is not lost between postbacks and use it window.history.go(-count) to go back.
For further reading-
http://www.aspnettutorials.com/tutorials/database/hit-cntr-asp4-cs/
Related
I have the following flow:
HOME => DEVICES => ADD NEW => SELECT TYPE => PAIR
Users can of course go back at any time. Now after pairing is complete I go to the DEVICES index page again.
When a user presses the back button on that page, it returns to PAIR (which I don't want), I want it to go to HOME.
I've looked at ReplaceState on the final step which changes the PAIR page by the HOME page before redirecting to DEVICES. That way when the user presses back in the DEVICES page he/she comes back at the home page (great!), however when the user then presses BACK again he arrives at SELECT TYPE which I don't want.
How can I accomplish that when the PAIR is done, the ADD NEW, SELECT TYPE and PAIR page are removed from history?
Side note: I'm using Turbolinks and Rails, although I believe the answer would be JS.
AFAIK, you cannot delete from browser history. But you can prevent saving history by location.replace (see https://stackoverflow.com/a/21820194/4486609) or do another mad thing like turning off back button at all, but...
if you have classic web app (not SPA) then you have some system to prevent user jump to abitrary step at your wizard, and if you have it, it is already solves such problem, isn't it?
How do you recover a past state when coming back to previous page (when using the browser's back button) in NextJS? Or in general, how do you recover a state when travelling between pages back and forward using browser's back and forward buttons?
I have a project where I am showing lots of gameshots in a grid ("gameshots" are something like Pinterest pins). In order to not have large waiting times when getting data from Sanity, I don't fetch it all at once and then store it in this.props, but in smaller batches and that's why they are stored in this.state.
This is my situation:
Use loads the /game page
Page gets 30 thumbnails from Sanity database, puts them into state as this.state.gameshots and renders them
User clicks on a thumbnail and the url changes to /game?gameshotIndex=14 (btw this is the real url but it says /gameshot/d6fg8a456g in the url bar)
When the url changes, a modal window is shown with a gameshot post in it: this.props.url.query.gameshotIndex && <Modal> ... </Modal>
User taps on a tag link inside the modal and goes to /tag/d65g4d56gff4g6jfg
User clicks the browser's back button, and gets an error because the state at /game is lost and the page therefore doesn't have this.state.gameshots needed to show the modal. If they were loaded at once and stored in this.props.gameshots it would work – but then you would have to load all the gameshots at once, even if there was 100000000 of them – which means huge TTFB and slow page loading.
So my question is: how can you travel through pages in a browser with back and forward buttons without losing the states?
Maybe you can use the localStorage.setItem('images', this.state.gameshots), and store what you need.
When the user get back you can use localStorage.getItem('images') get this data and show to the user. This gonna avoid to do another request to get the images.
I hope that's solve your problem. :D
I am using HTML and JavaScript to write Android APP, but I have a problem that when go back from current page to the previous page, the page is reloaded and the selection and setting when I made in the first goes to default.
For example: On the first page user can select country and city and then navigate to second page.
If user clicks on back button (which calls window.history.back(); or href="javascript:history.back(-1);")
, then all the selection he made are lost and default selections are shown.
It works fine in native browser of Android.
How to maintain state of selection?
Thanks in advance!
You need to make dummy history to disable history back button.
var originalHash = document.hash || "#dummyMain"
location.assign("#dummyBack")
location.assign(originalHash)
window.addEventListener("popstate",function(){
if(location.hash == "#dummyBack"){
window.history.pushState(null,null,originalHash)
}else{
originalHash = location.hash
}
});
The code above create dummy page history and checks if page transitions are occurred via history back button or not and if so,force page move to current page again to stop history back action.
Since You didn't put any code in the question,It's hardly possible to say it will work or not but I guess once you load this code,it should disable all page back action.
If you are using PC/Mac to use this site,please try to open developper tools/firebug javascript console and copy/paste the code and press history back button to see how it works.
I find a good way to maintain the data of previous page, which use localStorage store the data as key value before leaving this page and again when come back to this page you can get your data again from localStorage` and display it.
Because the data which is loaded by AJAX will be last on history back.
Hope this help someone may has this problem.
On my Single Page Application (Javascript (AngularJs) webapp), I'm displaying a paginated items list.
I'm displaying 10 items per page.
In order to retain the current pagination opened by the user at any time while this one navigates on other page, I put the current page number on browser's localStorage.
Here's an example of workflow:
The user goes to myItemsList.html.
He opens the page 2 involving the url: myItemsList.html?page=2.
Then, he goes to another page: myOtherPage.html.
He goes back to the link initially pointing to myItemsList.html, that displays directly thanks to localStorage the page myItemsList.html?page=2 in order to potentially continue his navigation.
Would it confuse the user, maybe expecting to see the page 1 as a new starting navigation.
If I display at the top of the list, a kind of label like "Page 2" in order to warn him that he's seeing the preceding portion of his navigation, isn't it UX-friendly?
Or should I completely avoid persisting current pagination?
Here's what could happen if I don't persist the current viewed page:
The user goes to myItemsList.html.
He opens the page 2 involving the url: myItemsList.html?page=2
He opens an item in this page (the "show" page), leading to: myItemsList.html?id=123
He clicks on the browser's back button, causing a refresh of myItemsList.html (since a Single Page Application). The current pagination (page 2) would be lost and the user would need to restart it in order to continue its items discovery.
This seems really touchy...
What strategy should I choose for a use case like this?
saving the progress through navigation is the expected behavior in UX design of SPA, so maintaining the page he was in the correct choice, and since it is a pagination it won't be an issue even if the user wants to go back to any page, it will only take a click.
First of all I would avoid using localstorage and use a service instead to persist ur page counter.
Secondly u dont need to persist pg counter to anywhere else but in a scope variable for refreshing to mext page data. You can even think about just adding to results similar to infinitite scroll use cases. But either way, u can use local scope variable for pagination.
Whether to go directly to last viewed page - is a more business decision and will depend on needs.
But u can very easily persist or remove persisted data using broadcast and watch and decide on persistence based on event listened to.
Hope thos helps ...
How about maitaining a sort of heirerachy in JS like this :
Suppose a user navigates to a section called Customer Search
customer_search.customer_display.page = 2
Where customer_search is the a subsection , customer_display is the view with pagination you are targetting .
menu.menu_items.page=7
Where menu is the subsection , menu_items is the view with pagination
Might work if your application is organized in a reasonably hierarchical manner .
Probably you could also maintain the page in $scope for that particular controller .
The URL should dictate the navigation.
When I navigate to your website, e.g. example.com, I expect to be on the first page.
When I navigate to a (bookmarked) page of your website, e.g. example.com?page=2, I expect to be on the second page.
When I hit the back button, I expect to be presented with the previous page exactly as it was when I left it. You don't need to refresh the entire page, just listen to the history events and update accordingly.
And I strongly believe that this question doesn't belong to stackoverflow...
I have a set of three apps/scripts.
The first allows the user to select a value. That value is passed to the second script, which takes the value, reads a database, and produces XML which is then posted to an Eclipse/Java/RAP application immediately, without user intervention using Javascript "onload'.
After the RAP application is loaded, to the user the back button doesn't seem to work. The back button takes the user to the second script, which gets the same values it did the first time and then immediately forwards to the RAP application again.
We want the back button to work as the user expects, i.e. to take the user back to the first script.
Since using the back button submits exactly the same information as it did in the first pass, including the referrer, the only way I can see to do this is to use cookies.
Is that it, or is there a better way?
Thanks,
Sean.
On page B set a cookie
On page A, detect the cookie. If it exists, clear the cookie then redirect.
One issue: Page A doesn't know if you got there by pressing BACK or if you navigated there directly. If you can live with that, it will work.