Basically what I want is this: https://dev.to/videos
You can select an item -> new page with item loads -> you click on backward button -> the old page is loaded from cache
I want that the same search page shown to user on navigation back, without calling the async fetch method again.
A solution seems to be SPA? But that is an enormous overhead.
I know how to do this with SPA. I need way without SPA.
iPhone, Android and Safari have a backforward-cache enabled by default, so no problem there. Static pages also don't have any problems.
I don't need any excact JavaScript code. I just want to know how do other websites solve this problem? Is SPA the only way? Are there any "frameworks" to solve this problem?
If server allows the page to be cached, your browser won't send a request again before the page expires.
https://stackoverflow.com/a/36554152/14263615
I am making one-page web on my school project. I am using very simple history API, to just change the URL so user thinks he is on another page (but I am hiding and displaying different elements on a page)
It looks like this:
www.mypage.com/main
www.mypage.com/slideshow
When I am using the application with back/forward history buttons it works fine, but when I want to reload the page, the browser tries to load that fake URL and that cause a crash of course. How do I manage to stay always on index.html no matter what url is displayed to the user please?
I tried to manage this with htaccess, but I wasn't sucessful
It seems you are not using a back-end, which is the only way to achieve your desired result. (If my assumption is correct) The browser gives error (cannot load /slideshow after refresh) because it is trying to fetch that file (from you local machine) but that does not exist. SO answer explaining this well.
So in your example you should instruct the back-end to render the same view for all routes (using a wildcard), and do the displaying on front-end based on the given url.
You do not have to use React-Router, but instead create a router-handling function which runs at each refresh (that is, when your javascript is loaded) which tells your page what to render based on what route (or url, call them as you like).
(you will know that the javascript will be run for every url, because the back-end already handles routing with the wildcard, *)
If you want to rewrite all requests to only one URL, you can do so with just
RewriteRule ^ /index.html [L]
I'm using the following history.go in search results with acceptable results cross-browser. I'd prefer a PHP solution but this filled the needs until I realized a larger issue.
Return To Search Results
My only issue is when the viewer comes from a page NOT originating from the search page http://www.domain.com/search/
Is there a way to modify this to use the simple script but if the previous -1 history is NOT the search page URL to redirect to the search page URL if the href is clicked?
the php variable $_SERVER['HTTP_REFERER'] will give you the page the current tab / window was on before it got to you.
this value might be empty if someone opened your page directly by typing in the url or by preventing this value to be transmitted to the server.
all in all there is no way to access the browser history at all due to security reasons.
$_SERVER['HTTP_REFERER'] is all there is that you could make use of. sorry to disappoint you.
btw.. its commonly used in hot linking prevention through out various blogs so people cannot "link" to pictures and files etc.
in your case you just need to figure out if the url equals the search site.
Am I right to assume that the biggest difference between location.assign and history.pushState in terms of URL displayed in browser is that the former reloads the page and the latter doesn't? I'm ofter asked on job interviews why hashtags were needed for routing in single page applications before the HTML5 history API came into being and I guess the answer should be because the developers had no tools to change URL without page being reloaded, correct? While manipulating the hash part of location could be done without page reload.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What’s the shebang/hashbang (#!) in Facebook and new Twitter URLs for?
I was wondering how Twitter works its links.
If you look in the source code, you use the links are done like /#!/i/connect or /#!/i/discover, but they don't have a JavaScript function attached to them like load('connect') or something, and that it doesn't require a page reload. It just changes out the page content.
I saw this page, but then all of those files would have to exist, and you couldn't just go straight to one of them. I imagine that on Twitter each of those files don't exist, and that it is handled in some other method. Please correct me if I'm wrong, though.
Is there a way I could replicate this effect? If so, is there a tutorial on how to go about doing this?
"Hash-Bang" navigation, as it's sometimes called, ...
http://example.com/path/to/#!/some-ajax-state
...is a temporary solution for a temporary problem that is quickly becoming a non-issue thanks to modern browser standards. In all likelihood, Twitter will phase it out, as Facebook is already doing.
It is the combination of several concepts...
In the past, a link served two purposes: It loaded a new document and/or scrolled down to an embedded anchor as indicated with the hash (#).
http://example.com/script.php#fourth-paragraph
Anything in a URL after the hash was not requested from the server, but was searched for in the page by the browser. This all still works just fine.
With the adoption of AJAX, new content could be loaded into the current (already loaded) page. With this dynamic loading, several problems arose: 1) there was no unique URL for bookmarking or linking to this new content, 2) search would never see it.
Some smart people solved the first problem by using the hash as a sort of "state" reference to be included in links & bookmarks. After the document loads, the browser reads the hash and runs the AJAX requests, displaying the page plus its dynamic AJAX changes.
http://example.com/script.php#some-ajax-state
This solved the AJAX problem, but the search engine problem still existed. Search engines don't load pages and execute Javascript like a browser.
Google to the rescue. Google proposed a scheme where any URL with a hash-bang (#!) in lieu of just a hash (#) would suggest to the search bot that there was an alternate URL for indexing, which involved an "_escaped_fragment_" variable, among other things. Read about it here: Ajax Crawling: Getting Started.
Today, with the adoption of Javascript's pushstate in most major browsers, all of this is becoming obsolete. With pushstate, as content is dynamically loaded or changed, the current page URL can be altered without causing a page load. When desired, this provides a real working URL for bookmarks & history. Links can then be made as they always were, without hashes & hash-bangs.
As of today, if you load Facebook in an older browser, you'll see the hash-bangs, but a current browser will demonstrate the use of pushstate.
You might wanna check out more on Unique URLs.
It's loading the page via AJAX, and parsing the "hash" (the values that come after the "#") to determine which page it's going to load. Also, this method is used due to the nature that AJAX requests don't count to the browser's history thus the "back button breaks". But the browser does however store into history the hash changes.
Using hashes plus the fact that you can use hashes to determine pages, you can say that you can keep AJAX requested pages "in history". Added to that, hashed URLs are just URLs, and they are bookmarkable including the hash, so you can also bookmark AJAX requested pages.