Recently I came across an issue with SPServices where it is not properly removing the hash portion (everything after the ‘#’ sign) of an URL when no search parameters are present. The exchange I had with Marc (@sympmarc) led me to believe that not allot developers are using the hash to store page state. But their application design should take into consideration how storing data there can help improve the user experience (UX). Specially as more SharePoint customizations move to the client side (browser).
In my (limited) working with SharePoint I have developed single-page client side applications where the page state is manipulated to display the proper state based on user interaction – all without requiring a page post-back. All needed data is retrieved in the background using asynchronous calls and custom UI widgets are used. I use the hash portion of the URL to store the state of the page as this happens. Why, you may be asking? So that the URL can be used to directly access the specific state. Users can bookmark the page or send it to others being assured that when loaded again the page will display the same information as when the URL was initially copied. The end result is similar to filtering a list’s ‘All Items.aspx’ to show only the desired data: once done, one can bookmark that page for quick access.
Yeah, the same could be achieved by storing the data in the normal search parameters section of the URL location object (everything after the ‘?’ mark and before the ‘#’ sign if present), but you cannot set the search portion of a URL without triggering a browser post-back. The hash, on the other hand, can be manipulated and the user never even notices.
Here is a real world example on a recent project. A few weeks ago I was asked to put together a page to show different metrics across a few projects. The page needed to show a high level rollup of all the projects as well as views per project and within each project, the ability to show/hide certain metrics – thus allowing customization by the end user. After learning a little more about the audience for this page and how they would be using it, two common use cases kept coming up:
- Once I have my view customized, I want to bookmark that view so that in don’t have to do it again
- I will need to share reports (via URL) with other team members and upper management
The solution was to save the state of the page by adding key=value parameters to the URL’s hash. When the page is initially loaded, and before the default view is shown, the hash portion of the URL is checked for known data and if found, the state is recreated automatically. Here is an example of such a url:
You can even use SharePoint’s built in GetUrlKeyValue() function to retrieve the values, as long as you place that first ‘&’ sign after the hash
GetUrlKeyValue("release", true, location.hash) // Return 3.0
I have used this method in addition to the search parameters to pass data around between pages and trigger functionality such as:
- Pre-pop form elements
- Trigger background data retrieval and in some cases updates
As the future of SharePoint pushes customizations away from SharePoint designer to the browser, I will certain use this practice allot more.