(Temp) Storage of JSON Search Results in Web App - javascript

I'm working on a search function for my Web app (HTML, JS & CSS only). I'm using jQuery's .getjson() method to retrieve data from a feed and display those results on a page. Inside of an .each() statement I'm adding HTML markup to the results making some of the elements links to outside sources.
The issue is when a visitor initiates a search on my Web app and clicks on a link from the results to an outside page, then uses the Back button on the browser to go back to the results page, all of the search results are cleared and another search needs to be initiated.
I'd like to temporarily save the search results so if a user clicks on a link from the results, then presses the Back button to come back to the app, all of the results will be available without the new for another search.
Taking this one step further, it would also be cool is the results for past searchs also persists so if the visitor continues to press the Back button, they can see all of their previous searches (with a given limit of course).
HTML5 sessionStorage seems to be ideal for this, but the information that I found points to a tedious coding solution. Can't I just save all of the json results as a JS object and have them re-rendered by my each statement when the visitor presses the Back button? I'm definitely open to using a code library or plugin for this problem.

http://brian.io/lawnchair/ is a good little library for API for persistence. You can use the same syntax as an abstraction for different storage options http://brian.io/lawnchair/adapters/

You have two ways to approach this issue, one is caching the results on your server and populating the view on-demand, and number two is like you previously mentioned - use sessionStorage. sessionStorage (IMO) has a very straightforward API. You can either use sessionStorage.setItem(key, value) or sessionStorage.getItem(key) -- other methods are available as well such as sessionStorage.key(index), sessionStorage.removeItem(key) and sessionStorage.clear(). It would probably be useful to include a cross-browser polyfill solution for sessionStorage, you can check out the "Web Storage" polyfills section at Modernizr: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills -- Have fun :-/

Off the top of my head:
Every time the user searches, change the hash in the url to a unique string (e.g. 'search-{userInput}' ... you could of course just forget about the 'search-', but I like my urls in pretty). This should give you back-button support. Then:
Alternative A:
Listen for the hashChange Event, parse the window.location.hash and resend the request to your search URL. Theoretically, unless adding the timestamp to the URL or crazy stuff like that, the caching mechanism of your browser should kick in here. If not, it means an additional request, but that should be ok, shouldn't it?
Alternative B:
Extend your existing search query mechanism by caching the results to localStorage (just don't forget to JSON.stringify it beforehand and use a something-{timestamp} key). Then listen for the hashChange Event and pull the results from your localStorage. Personally, I wouldn't recommend this solution as you're clogging up the localStorage (afaik there's a limit at 2.5mB for some browsers).
You're probably going to have to find ways to circumvent missing browser support for at least the hashChange Event, JSON stringify/parse and LocalStorage, but I'm optimistic that there are enough libs/plugins out there by now.

You think too complicated: your search form most likely does not change the url! Use GET instead of POST and you have the desired result. Right now the browser has no way of knowing which state of the website you want to show and by default shows the first - the empty search form
Caching could be added as suggested, but that really is not the problem here

Related

Clearing out data if browser reloads using Horizon.io

For testing purposes, I am trying to re-create the situation where a new user enters the website for the first time. So all existing data should be reset. I tried to use the id of the data I wanted to remove using data.remove(id) syntax in a ready() method but that did not seem to work. How can I clear out all data when the page is reloaded? Do I manually have to remove each data item using remove or removeAll or is there a simpler way to do sort of a clear browser history which will clear all data from previous sessions?
The easiest way would be to use removeAll. There's no equivalent of clearing browser history because multiple users may be able to read and write to the same document depending on your permissions scheme, so it's hard to define a general rule for what should be cleared.

Is there any way to access browser form field suggestions from JavaScript?

Is there any way to access the autocomplete suggestions that appear under HTML input fields in some browsers (representing previously submitted data)? Is this only available to the browser?
I ask as I want to make my own autocomplete implementation in javascript, but I want to intermingle my own suggestions with the users previous searches. A bit like how youtube does (but youtube stores all the data obviously, and it is tied to a login, there are no accounts on my website and never will be).
I was wondering more if there was a way to do it with the data stored in the users browser rather than storing all the data on my server. Is there is a way to grab the data the browser uses to present previous input to a user?
Is the data that appears in html input fields representing previously submitted data only available to the browser?
Yes - until it appears in the DOM.
Is there is a way to grab the data the browser uses to present previous input to a user?
It's a browser-specific feature, and you can't access the data [history] directly (Where do browsers save/store auto fill data). You only can disable storing anything.
I ask as I want to make my own autocomplete implementation in javascript, but I want to intermingle my own suggestions with the users previous searches. I was wondering more if there was a way to do it with the data stored in the users browser rather than storing all the data on my server.
Especially if you want to utilize all previous searches, the browser's autofill doesn't help you anyway. But yes, you can store them in the browser (on the client side) manually: Use DOM Storage, like localStorage. Though I would recommend sessionStorage only, you might run into privacy issues otherwise if everybody using a browser could see the search terms of previous users…
You can use jstorage. Jstorage lets you store up to 5Mb of data on the client side.
<script src="//cdnjs.cloudflare.com/ajax/libs/json2/20110223/json2.js"></script>
<script src="https://raw.github.com/andris9/jStorage/master/jstorage.js"></script>
<script>
/* $.jStorage is now available */
// store some data
$.jStorage.set('yourkey', 'whatever value');
// get the data back
value = $.jStorage.get('yourkey');
</script>
The only way i see this working is with help of localStorage (html5) problem that it doesn't work in ie<8
Here's an example: http://jsfiddle.net/8NZY7/

How to avoid ajax reload when you click the back button

I have a page that used Ajax to generate the a list of result. Then there is a link to click to another detail page. When I'm at the detail page, and click the back button. The list of results page will reload again. Is there anyway to stop the ajax to reload again and cache the result. Also is there anyway to cache the position also.
thank you for your help
A few projects I had bookmarked regarding the AJAX/back button management
https://github.com/browserstate/history.js
https://github.com/tkyk/jquery-history-plugin
Regarding your second question, if your browser supports local DB you may cache the result there. The following project provide a uniform API across browsers.
https://github.com/marcuswestin/store.js
https://github.com/alexmng/sticky
Position can also be stored in the localDB.
You can save state by changing the window.location.hash property. The hash is the only part of the URL that you can change and not force a reload of the URL.
window.location.hash = 'some-id'; will translate into your URL looking like this: index.html#some-id.
You can then get the hash when the page loads and set the UI to the proper state:
if (window.location.hash == 'some-id') {
//setup UI for `some-id` identifier
}
https://developer.mozilla.org/en/DOM/Storage
Store your data with a timestamp of some sort. Check to see if you have stored data and that it's not older than you would like it to be. If it's older, fetch new data. If not use the stored data.
(it's not mozilla specific)
http://caniuse.com/#search=local%20storage
You can use the new HTML5 LocalStorage system to build a cache. Here's a link: http://playground.html5rocks.com/#localstorage

What purpose is of "&rnd=" parameter in http requests?

Why do some web-applications use the http-get parameter rnd? What is the purpose of it? What problems are solved by using this parameter?
This could be to make sure the page/image/whatever isn't taken from the user's cache. If the link is different every time then the browser will get it from the server rather than from the cache, ensuring it's the latest version.
It could also be to track people's progress through the site. Best explained with a little story:
A user visits example.com. All the links are given the same random number (let's say 4).
The user opens a link in a new window/tab, and the link is page2.php?rnd=4. All the links in this page are given the random number 7.
The user can click the link to page3.php from the original tab or the new one, and the analytics software on the server can tell which one by whether it has rnd=4 or rnd=7.
All we can do is suggest possibilities though. There's no one standard reason to put rnd= in a URL, and we can't know the website designer's motives without seeing the server software.
Internet Explorer and other browsers will read an image URL, download the image, and store it in a cache.
If your application is going to be updating the image regular, and so you want your users to not see a cached image, the URL needs to be unique each time.
Therefore, adding a random string ensures this will be unique and downloaded into the cache each time.
It's almost always for cache-busting.
As has been suggested by others. This kind of behaviour is usually used to avoid caching issues when you are calling a page that returns dynamic content data.
For example, say you have a page that gets some current user information such as "mysite.com/CurrentUserData". Now on the first call to this page, the user data will be returned as expected, but depending on the timing and caching settings, the second call may return the same data - even though the expected data may have been updated.
The main reason for caching is of course to optimise the speed of frequent request. But in the instance where this is not wanted, adding a random value as a query string parameter is known to be a widely used solution.
There are however other ways to get around this issue. For example if you were doing an Ajax request with javascript/JQuery. You could set the cache to false in your call...
$.ajax({url: 'page.html', cache: false});
you could also change it for all page calls on document load with...
$.ajaxSetup({cache: false}});
If you were to do an MVC application, you can even disable the caching on the control action methods with an attribute like so...
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public ActionResult NonCacheableData()
{
return View();
}
(thanks to a quick copy and paste from here)
I dare say there are also settings in IIS you could apply to get the same affect - though I have not been that far with this yet.

When using back button AJAX results have been lost

So I've set up a pagination system similar to Twitter's where where 20 results are shown and the user can click a link to show the next twenty or all results. The number of results shown can be controlled by a parameter at the end of the URL however, this isn't updated with AJAX so if the user clicks on one of the results and then chooses to go back they have to start back at only 20 results.
One thought I've had is if I update the URL when while I'm pulling in the results with AJAX it should—I hope—enable users to move back and forth without losing how many results are shown.
Is this actually possible or have I got things completely wrong?
Also, how would I go about changing the URL? I have a way to edit the URL with javascript and have it be a variable but I'm not sure how to apply that variable to the URL.
Any help here would be great!
A side note: I'm using jQuery's load() function to do all my AJAX.
Not mentioned in the duplicate threads, but useful nonetheless: Really Simple History (RSH).
This would be the answer I would put here:
Browser back button and dynamic elements
You can't actually change the url of the page from javascript without reloading the page.
You may wish to consider using cookies instead. By setting a client cookie you could "remember" how many results that user likes to see.
A good page on javascript cookies.
The answer for this question will be more or less the same as my answers for these questions:
How to show Ajax requests in URL?
How does Gmail handle back/forward in rich JavaScript?
In summary, two projects that you'll probably want to look at which explain the whole hashchange process and using it with ajax are:
jQuery History (using hashes to manage your pages state and bind to changes to update your page).
jQuery Ajaxy (ajax extension for jQuery History, to allow for complete ajax websites while being completely unobtrusive and gracefully degradable).
First 3 results google returns:
first
second
third
I'll eat my shorts if none of them are useful. ^^
And yeah - you can't change URL through JS.

Categories

Resources