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?
Related
So, I'n NOT a frontend guy, please bear with me..
I have pages, where you submit forms (target and current urls are identical) a number of times, before you wan't to go back to the previous page.
The way the submits are processed, is that the form is posted, and then the user is redirected, so that a reload doesn't re-submit(POST) the form - I'm not sure if this is the optimal approach to achieve this..
The issue is that this will only take the user back to the same page, since if eg. a form on page A was submitted twice, the history will have:
page A (current)
page A (submit, yielding a redirect)
page A (previous load)
page A (submit, yielding a redirect)
page A (original load)
previous page
Now I'd like the back button to take the user back to the previous page (#6), and in order to do that I'm guessing I'd need to introduce code on each page (with forms at least) which:
checks if the referrer has identical url as the current one, and if so, does history.popState
on submitting any form, check if the target and current urls are identical does history.popState
Is this a sound strategy, or is there are better way to achieve this?
Html
<a href="index.html"
onclick="handleClick(this);">Click</a>
Javascript
const handleClick = (e) =>{
locaiton.replace(e.href);
return false;
}
This doesn't seem possible, so I took another route, where I'd avoid using the back button, but rather offer links to the previous page, based on the context.
My Setup
I am using react router 4 in my application and am trying to achieve something along the lines of adding hashes to certain routes on pages, that will save the state of the page so user can link to said state.
So for example - I have products I am listing that have many variants, when the user selects a variant, I add a hash + the variant ID to the URL, so like myapp.com/cars/truck turns to myapp.com/cars/truck#red, this allows users to link to that specific variant, which is what I want.
My problem
My problem arises when the user navigates to a page and selects a few variants, then tries to navigate backward. Because I change the hash, each back step hits the previous variant in the browsers history.
So if
the user lands on home myapp.com/
navigates to myapp.com/cars/truck
then selects the red variant => myapp.com/cars/truck#red,
then blue myapp.com/cars/truck#red => myapp.com/cars/truck#blue
When they press the back button on the browser they will go back to myapp.com/cars/truck#red, when the desired effect is they go back to the previous page omitting the variant and hash changes, which would be myapp.com/.
I understand this is the browsers behavior, but what I am wondering is if there is a way to let users link directly to the variant links, and also have it so pressing the back button after the described scenario takes the user back to the previous page (in that scenario it's myapp.com/). Perhaps re-thinking how I am doing this, I am open to any suggestions.
I am using react (16) and react router (v4) for this if this helps. Happy to show any code if needed, please let me know. Thanks for reading!
Try replaceState, it will update the URL without adding a history entry:
history.replaceState() operates exactly like history.pushState()
except that replaceState() modifies the current history entry instead
of creating a new one. Note that this doesn't prevent the creation of
a new entry in the global browser history.
e.g.
history.replaceState(null, 'Red Truck', '/truck#red')
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...
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/
If I have a form, and don't click submit before hand, using standard javascript history.
<button onclick="history.go(-1);">Back </button>
will bring me back to the previous page. However, if I click submit, and error come out (validation).
the back button will bring me back to the same page (the page before the submit error happen).
How can I create a back button where it always bring to the previous page, regardless error of validation.
Thank you
Going by the actual history isn't a great way of doing what you want. What you see happening here, is of course expected behavior, since submitting the form over and over will just add the page with the form to the history over and over. And by design, for security reasons, there isn't a way to check arbitrarily far back to the last page the user was on on your site that wasn't the form.
Therefore, I think a solution in Cake would be better. If the user can only arrive on the page from one place, you could make the button just link back to that page, rather than depending on the history. Alternatively, I would store in session the page that the user came from originally, and be careful to not rewrite it as long as the user stays on the form, and then link to that on the back button.