Protiviti / SharePoint Blog

SharePoint Blog

July 28
SharePoint 2013 Search Part 1: Asynchronous Search Results

​SharePoint 2013 introduced many new features with search:  continuous crawl, content by search web parts, and result sources just to name a few.  A hidden gem among all this new functionality is asynchronous search results.  You probably didn’t even notice, but when you drop a Search Results web part and a Search Box web part on a page, content is searched asynchronously by default! 

As you change your search query, you will notice the “k” value change in the URL right along with it.  Even more interesting is that if you change the “k” value in the URL directly, the search box as well as the results will again update to reflect the new query.  All the while, the page never posts back!  


What sorcery is this?  The secret is the URL hash indicator.


You can change the value after the hash character all you want and the browser will never post the page back to the server.  In fact, the browser doesn’t even send the value of the hash back to the server when something does cause a post back.  However, you can use JavaScript to handle changes to the hash, and this is exactly what Microsoft does with the search web parts.

Refinements end up in the hash as well, but look at what happens once you select a refinement


What happened to the “k” value?  What is this Default business all about?  Passing the hash through a simple URL decoder reveals something like this (note that the URL extends well beyond what can easily be captured in the screen shot above):

Default={"k":"test","r":[{"n":"LastModifiedTime","t":["range(2013-07-24T04:00:00Z, 2014-07-17T04:00:00Z)"],"o":"and","k":false,"m":null}]}

If it isn’t obvious, this value represents a JSON formatted object.  This makes sense now.  Refinements can be very complex and using the data in JavaScript is going to much easier to deal with in object form.  JSON lends itself very well to this purpose.
 
You get this same format if you have more than one results web part on the page as well, except each part is given its own hash.  The first results part is always labeled as Default.  Subsequent parts will have a GUID ID value.  This is done so that search can determine what queries should be directed to what results.

These details are honestly a bit mundane and perhaps unimportant for most users.  But if you are asked to build something custom that integrates with and modifies search queries or refines search results, they are invaluable.  The next post in this series will detail how to handle the hash change event in JavaScript and one way to parse the JSON and modify it to suit your needs.

Quick Launch


© Protiviti 2019. All rights reserved.   |   Privacy Policy