Angular and SharePoint Search – what can go wrong?

Have you ever used Angular with SharePoint Search? Angular and search web parts using the URL for persisting state can cause some real havock! After hours of developer annoyment we finally found out why..

Angular have a nasty function in its source that doesn’t go well together with search web parts (especially those with paging).

The function is:

encodeUriQuery

What it does is encode the hash-part of the URL (even the #, which causes the havock). Why does this cause issues for search results web parts with paging? Because they use the URL to persist the paging properties.

Let’s say we have three web parts with paging on our page.

1. Featured Documents
2. Featured Tasks
3. Featured Events

Each of these webparts have an ID. Let’s just create some:

1. Featured Documents ea07aeed-5b08-4cc9-ab41-def7bcf3e24a
2. Featured Tasks 793d047b-7baf-4b0a-a80f-3651860d7a85
3. Featured Events 4f5cc786-27d4-454f-ba73-e5fd2865552d

When “paging” on one of these webparts SharePoint will start to persist the paging for all of these webparts in the URL. How will it separate the properties for each web part? With the #. 

And the HASH (#) has been encoded by encodeUriQuery. The paging won’t work!