custom search worker setup

[xvandish]

Hi,

I've spent a good enough time on this that it's probably better for my sanity to get some help.

I want search to query a search API I'm setting up instead of the default local lunr setup. I found and read through https://squidfunk.github.io/mkdocs-material/setup/setting-up-site-search/?h=searc#custom-search.

The problem is, I can't get any (arbitrary) code to run in any file I place in the config block of my overrides/main.html file.

Here's my overrides/main.html file:

{% extends "base.html" %}

{% block htmltitle %}
  <title>Lorem ipsum dolor sit amet</title>
{% endblock %}

{% block config %}
  {{ super() }}
  <script>
    var __search = {
      transform: function(q) {
                console.log('query is: ', q)
                return q;
            },
      worker: "docs/worker.js"
    }
  </script>
{% endblock %}

And here's docs/worker.js:

console.log('whats going on')

export async function handler(message) {
    console.log({ message })
}

addEventListener("message", async ev => {
    postMessage(await handler(ev.data))
})

With this setup, I can see query is: ... being logged to the console whenever I type. But I can't see any logs from my worker.js file, nor can I see worker.js being loaded as a worker in the sources pane.

Here's what I've tried/gone through:

1. Putting the worker.js file in several different places and updating the config block accordingly - no change
2. Different file contents in worker
3. Passing an invalid <url> and turning on verbose mode - no errors are logged even with invalid path
4. Tracing how/where the current worker is loaded...

I can see the setupSearchWorker is configured then called here with a URL value of config.search, but config.search, when I logged it out after setting up mkdocs-material locally, seems like its being set in src/base.html.

transform, which is configured in the same __search block is set (I think) - here. to the value in GlobalSearchConfig, which doesn't include worker anywhere.

So gist is, I'm not sure why my custom worker isn't being loaded, and from the code I can't see how it's configurable, so I'm guessing I'm missing something in the flow.

Any insight would be greatly appreciated, thanks!

[squidfunk]

Good catch. The search customization documentation is outdated, the variable was removed. You can open an issue, so we can fix it.

[squidfunk]

As a temporary workaround, you can extend the whole config block and replace the value of app.search:

{% block config %}
  {%- set app = {
    "base": base_url,
    "features": features,
    "translations": {},
    "search": "assets/javascripts/workers/search.js" | url,
    "version": config.extra.version or None
  } -%}

  <!-- Translations -->
  {%- set translations = app.translations -%}
  {%- for key in [
    "clipboard.copy",
    "clipboard.copied",
    "search.config.lang",
    "search.config.pipeline",
    "search.config.separator",
    "search.placeholder",
    "search.result.placeholder",
    "search.result.none",
    "search.result.one",
    "search.result.other",
    "search.result.more.one",
    "search.result.more.other",
    "search.result.term.missing",
    "select.version.title"
  ] -%}
    {%- set _ = translations.update({ key: lang.t(key) }) -%}
  {%- endfor -%}

  <!-- Configuration -->
  <script id="__config" type="application/json">
    {{- app | tojson -}}
  </script>
{% endblock %}

[xvandish]

Gotcha! Sure, I'll open an issue up shortly. In the short term, the temp workaround works just fine for me, thanks for the idea. Thanks also for the quick and thorough response, it's much appreciated.

[xvandish]

Also, I'm open to helping out and submitting a PR which allows worker to be configured in __search, I just probably won't have time to work on it until this weekend or next Friday. Can discuss on the issue.

[squidfunk]

Thanks for offering to work on this. The thing is that I'm not sure whether this is still the semantically correct and best possible position for this, so we should discuss it in an issue.

[xvandish]

Of course, and makes sense! I opened up issue #2973 .