Algolia search results hit component not working with absolute URLs

[itsacoyote]

Version

@nuxtjs/algolia: 1.10.2
nuxt: 3.13.1

Reproduction Link

--

Steps to reproduce

I have a nuxt layer I have built that is used in three projects.

• Nuxt Layer: https://www.npmjs.com/package/@matterlabs/docs-nuxt-template
• ZKsync Docs: docs.zksync.io
• SDK Docs: sdk.zksync.io
• Community Code: code.zksync.io

In the Nuxt Layer I implemented the @nuxtjs/algolia module and set it up so that it is used across all three sites. Our algolia crawler indexes through all three sites and I return results from all three sites in a single docsearch implementation.

What is Expected?

If you are on ZKsync Docs, I would expect search results to display relative links for results that are from the subdomain docs.zksync.io and an absolute URL for the other two websites. When clicking on an internal link, it should navigate as expected in a Nuxt application, for example a search result of ecosystem/wallets on ZKsync Docs should navigate via the relative URL. When clicking on an external link, it should navigate with a full load to a new page, for example a search result of https://sdk.zksync.io/js/ethers on ZKsync Docs should direct to a new page load.

What is actually happening?

Instead of navigating to an external link, upon clicking the search result for https://sdk.zksync.io/js/ethers while on ZKsync Docs (for example https://docs.zksync.io/build), the URL is changed to https://docs.zksync.io/build/https://sdk.zksync.io/js/ethers. It will not recognize the URL as an absolute URL and simply appends it as part of the navigation click.

How I fixed it (sort of)

I am using the transform-items prop to set all of my items with an absolute url. This is to override the default function that sets the item url to a relative path. This defines a full URL on the item for me to start with but it didn't solve the click issue.

I initially thought the way to solve the click navigation issue was to modify the navigator prop but it didn't seem to do anything and I'm still not sure exactly what it's doing.

I eventually came across the 'hit-component' prop and took what was the default and made a modified version that works with the absolute URLs:

const isSpecialClick = (event: MouseEvent) =>
  event.button === 1 || event.altKey || event.ctrlKey || event.metaKey || event.shiftKey;

export const useDocsearchHitComponent = () => {
  const config = useRuntimeConfig();
  return ({ hit, children }: { hit: { url: string }; children: unknown }) => {
    return {
      type: 'a',
      constructor: undefined,
      __v: 1,
      props: {
        href: hit.url,
        children,
        onClick: (event: MouseEvent) => {
          if (isSpecialClick(event)) {
            return;
          }
          
          const siteUrl = `https://${config.public.app}.zksync.io`;
          if (hit.url.includes(siteUrl)) {
            const { pathname, hash } = new URL(hit.url);
            // navigate internally
            navigateTo(pathname + hash);
          } else {
            //navigate externally
            navigateTo(hit.url, { external: true });
          }
        },
      },
    } as unknown;
  };
};

I understand this might be a bit of an odd situation to have DocSearch results linking to external sites, but I had assumed that simply defining absolute URLs in the item's url property would resolve my issue. It was driving me crazy trying to figure out why the module was being very insistent on appending the absolute URL as a path to the URL even when the anchor tag in the HTML was linking to the absolute URL. It feels like javascript hijacking the expected behavior and doing actions that aren't standard from a visual point of view.

I am also still unsure how this works in relation with navigator.

[Baroshem]

Hi there!

First of all, thank you for the extensive research and proposing a solution which can be used by others if they encounter similar problems. This will certainly help 😀

I think we have to support both approaches (relative and absolute) to not ship breaking changes to the current users.

Would you be interested in contributing to the module and implementing such solution? I can provide help if necessary to make it live :)

[itsacoyote]

Yes I would like to implement the fix!
I do agree that we should still maintain the current behavior of managing relative URLs, the fix will be to determine if the URL is relative or absolute and handle both appropriately.

The main question I have before creating a PR for this is how the hit-component onClick behavior works in relation with the `navigator'. Any changes I tried to make to the navigator did nothing and the onClick behavior seemed to be the primary action that managed the behavior of navigation for a search result.