I'm working on a vue single page application.
Situation: I have a page which displays 1..* results (Page A), if there is only 1 result available, then this result is automatically selected; meaning the user is redirected to the items detail page (Page B).
[Page A] <-> [Page B]
Problem: if the user is on Page B and navigates back then the 'auto-select'-clause is triggered again which results in a redirect again to Page B. This means you cannot navigate back once you've entered Page B - this is unacceptable.
Thoughts: The best solution I can think of is to add a check to the auto-select clause which matches the origin (where the user came from, e.g. Page B) to the desired destination (where to user is redirected to, e.g. also Page B), and if they do match, do not trigger the redirect. The problem is that I have no way of knowing where the user was before.
I tried to use document.referrer but this isn't suitable for a single page application.
I tried to work with vue-router properties, but none of which brought me any futher.
The only other solution I can think of is to store each navigation in a cookie (or similar) to match against, but since this is quite a rare case I try to avoid having too much of an overhead.
Any idea? Is there something similar like document.referrer but for single page applications? Or is there a way to extract information from the history?
When result is only 1, then PageA will redirected to PageB ,if in this case , let the route like "/PageB?only=1".
in pageB, if the query's only is 1, then when you click the back button,redirected the page that you want to back.
I am not sure it is the best~ but it should work。
Related
I have a Django website that looks like this:
The arrows represent hyperlinks that take you to the next page. All pages except the Main Page need a "Back" button.
For Page A and Page B, the back button is pretty simple - it always takes you to the Main Page.
For Page C however, there are 2 different ways to get to it (technically 3, if you count the back button on Page D), so it's no longer obvious where the back button should take you.
The way it should work is this:
If the user came from Page A to get to Page C, the Back button should take them back to Page A
If the use came from Page B to get to Page C, the Back button should take them back to Page B
If the user didn't come from either Page A or Page B to get to Page C (they could have just entered the URL of Page C into their browser), default to having the Back button take them to Page A
This has been asked before, and none of the answers/suggestions make sense for anything other than the most basic scenario, where Page C is the end node.
The problem:
Using a hardcoded url for the back button of Page C won't work, because there are 2 ways to get to it
Using session to keep a single variable that keeps track of whether you last visited Page A or Page B won't work because multiple browser tabs share the same session variables. If the user has 2 tabs of our website open, navigating around will lead to confusion as both will update the same session variable
Using request.META.HTTP_REFERER won't work, because the user might navigate to Page D, and then back to Page C, so the HTTP_REFERER variable will point to Page D, rather than Page A or Page B
Using javascript:history.go(-1) won't work - same problem as above with HTTP_REFERER
I have come across this issue in multiple projects, and it's always a pain to deal with. The solution is always hacky. Is this a problem that inherently can't be handled by Django, and must be handled by something like JavaScript's sessionStorage?
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.
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?
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 bit of an interesting situation.
I have an application that uses an MVC framework to deliver the view to the user.
This is great for the overall design perspective.
There is a wrinkle though.
At certain times a user could be doing something on a page and they would be required to go to another page to perform a look-up service. I need to be able to uniquely identify each page that they go to and I am not able to use the URL, because all the subsequent pages that I visit from the parent page have the same URL.
Just an fyi, I care about this because I'm attempting to store the last known scrolling position on each page in cookies.
Example -
They are working on Page A.
They click a link from A and they are taken to page B.
On Page B they enter some values and click Search which will query a DB
A list of results is returned.
They can then select to "Return Value" of one of those search results.
The value is then returned to Page A.
When I run the following on each page (A and B) -
alert("${channelUrl}");
They are an exact match!
What else can I do to determine what page I am on within my javascript without resorting doing any sort of server side AJAX calls etc...?
Is what I am asking even possible?
Currently I am attempting to solve this problem by counting up the number of text fields on the page and appending that to my cookie name. This is not ideal, especially if a user visits a page that happens to have the same number of text fields.
Thanks.
One common way to handle this sort of thing is to open the second page in a new window. With this approach the parent and child windows know which is which (the child refers to parent as window.opener, and the parent refers to the child via the return value of the open call) so there's no need to manage URLs or anything to keep track.
People often use the part of the url after # to keep track of where you are under the a single URL. This is built-in supported with My Section which takes you to the element with id "my-section", but you can use libraries that take control of this section of the URL in other ways.