Hi could you maybe create a razor section with a default content that is overriden if an editors checks a property with disable find. Or you could create a complete new view without the helpers that is adding find scripts.

I ended up creating a new layout for this specific page that doesn't include the client scripts included in the footer. This was a suggestion from Episerver. It works, but it also means that any other client scripts included won't work.

I guess you could implement your own IClientResourceService as well

I've experimented with a custom IClientResourceService, and I'm wondering if it is enough to include the scripts on the actual search result pages (and not on all the other pages of the site)

Do the script have any purpose on a non-search result page?

You can try overriding Find tracking script on that single page. Inject some dummy script that does nothing when user is on that single page. Use epi.find.trackingScript as a resource name when you require that script:

ClientResources.RequireScript("path-to-dummy-script.js", "epi.find.trackingScript", new[] { "browserstate.history" });

You also can try to inject inline script using ClientResources.RequireScriptInline method or require script/inline script using IRequiredClientResourceList instance (get it from service locator). See this article for more information about how to manage client resources. Make sure that you override epi.find.trackingScript on required page only.

In this case you can use normal templates and don't break all other client resource injections. Please let us know if it works for you.

I've tried using the approach suggested by Dmytro Duk, but unfortunately the native.history.js is still loaded:

public ActionResult Index(InsuranceShopPage currentPage)
{
    _requiredClientResourceList.RequireScript(
"~/Scripts/insuranceshop/empty.js",
"epi.find.trackingScript", new[] { "browserstate.history" });

   var model = new InsuranceShopViewModel(currentPage);
   return View(model);
}

I was under impression that you want to disable tracking. So click tracking is disabled if you override find.js as it was suggested.

History.js is used by find.js script, but history.js does not track anything. You can override history.js location in the same way if you want to get rid of Find history.js injection on that single page.

Use browserstate.history as a resource name.

Dmytro Duk suggestion with the last addition works just fine. I get an error from the Find JavaScript, but my problem is solved. Trying to avoid the error I combine the two suggestions, but Episerver has an error in the detection of the FindApi-script (it uses the syntax if(FindApi), but should have used if(FindApi === "function") I believe).

Anyway; thank you very much for your help. Dmytro!

Oh yes, you should override both scripts on that single page if you trying to get rid of history.js. find.js depends on history.js and of course it fails when history.js is not loaded.

I will check if statement if(FindApi) doesn't work when scripts are not loaded and will file a bug if there is an error.

Do we need to include the Find scripts on pages that does now show a search result? 

I've modified some examples of a ClientResourceProvider and it seems to work: 

[ClientResourceProvider]
    public class EpiFindResourceProvider : IClientResourceProvider
    {
        public IEnumerable<ClientResource> GetClientResources()
        {
            // Check if we are on a page with a query, and include tracking scripts if we are :-)
            // Apparently, these scripts are only required to show on the search result page. 
            if (HttpContext.Current != null && 
                (
                    (
                        HttpContext.Current.Request.QueryString.HasKeys() &&
                        HttpContext.Current.Request.QueryString.AllKeys.Contains("q")
                    ) 
                    ||
                    (
                        HttpContext.Current.Request.Form.HasKeys() &&
                        HttpContext.Current.Request.Form.AllKeys.Contains("q")
                    )
                )
               )
            {
                return new[]
                {
                    new ClientResource
                    {
                        Name = "browserstate.history",
                        Path = GetIntranetUrl() + "native.history.js",
                        ResourceType = ClientResourceType.Script
                    },
                    new ClientResource
                    {
                        Name = "epi.find.trackingScript",
                        Path = GetIntranetUrl() + "find.js",
                        ResourceType = ClientResourceType.Script,
                        Dependencies = new List<string> {"browserstate.history"}
                    }
                };
            }
            else
            {
                return new[]
                {


                    new ClientResource
                    {
                        Name = "browserstate.history",
                        InlineContent = "",
                        ResourceType = ClientResourceType.Script
                    },
                    new ClientResource
                    {
                        Name = "epi.find.trackingScript",
                        InlineContent = "FindApi=false;",
                        ResourceType = ClientResourceType.Script,
                        Dependencies = new List<string> {"browserstate.history"}
                    }
                };
            }
        }

As far as I can see, the scripts does not do any useful work unless they are loaded on a search-result page. 

Please correct me if I don't see far enough :-)

I should say that workaround that I described above is a hack to override tracking scripts on one single page. This is definitely not recommended and not normal way of using Find.

Tracking scripts should be injected on all pages.

Simple example: visitor clicks on search hit link and navigates to target page. In this click is detected on the search page, but information about that click is sent to the backend when target page is loaded. See more details here.

I don't think it's good idea to implement client resource provider like that because it looks too much context-related. In my mind provider should just describe available client resources and that's it. Some other component decides and requires which resources must be injected in current moment of time and for the current context. You can implement IClientResourceRegister or just require resources using ClientResources static class or or IRequiredClientResourceList instance in your page/controller/filter/whatever depending on your needs.

Thanks for commenting, I'll look deeper into this.

Our main problem is that we have a few Angular-based SPA's that relies on # in the URL, and the history.js script is not compatible with this, and causes a lot of weird issues if included in the page -

Making the client resource provider "aware" of context was a work-around that appeared to do the trick...  

I believed that the actual "useful" work the scripts did was stripping the querystrings from search result and storing the value in a cookie for the next request to the server. 

Is the script somehow involved in reading the cookie on the target page? 

In normal case information about clicks is buffered on a client side and data is sent to the backend as soon as "next" page is loaded, which is usually that target page.

So tracking scripts work not only on search page.