Instantsearch hooks: router not getting along with Next.JS

[dsbrianwebster]

We are trying out a server rendered search implementation with NextJS. All seems okay until we try to add a routing object to InstantSearch. We are using routing to have urls for our search state, and to make them SEO friendly (q=potato&type=tuber). There are all sorts of quirks though, from additional re-renders on load to the rest of the application routing breaking.

1. Re-Render Example: If we try starting at url /search?q=potato we immediately see a re-render to /search.

2. Routing Example: When we click on a hit/result <Link href={/post/${hit.slug}>🥔 hit</Link> we are taken to our expected /post/${hit.slug} url, but then from there our routing in general seems to be broken. Clicking back moves to /search?q=potato, but only the url changes. Page content is not updated.

[Haroenv]

Just to double check, is that with using the getLocation call, like in the hooks-next example? https://codesandbox.io/s/github/algolia/react-instantsearch/tree/master/examples/hooks-next

It's definitely not a simple problem keeping the state and routers in sync, so if there's a specific edge case missed I'd love to fix that

[francoischalifour]

Hey @dsbrianwebster – this is likely because Next.js is using Strict Mode, which isn't yet supported in the library with React 18.

Our <InstantSearch> component reads the URL query params to set the initial state, and write the browser URL on unmount to reset it. This is a first-class behavior of the underlying InstantSearch.js library. The problem is that during the second Strict Mode render, the URL has been reset, and therefore the second render is unable to recover the initial state. This breaks URL synchronization.

We're working on React 18 Strict Mode support this week so you can expect a fix in the coming days.

In the mean time, could you disable Strict Mode on the <InstantSearch> component?

Edit: Strict Mode support was introduced in v6.28.0.

[dsbrianwebster]

Hi @francoischalifour. Thanks for the response! Yeah we have been seeing a bunch of "additional render' issues with other packages after upgrading to React 18 and pretty much roll with strictMode off by default on all projects for the time being.

I can confirm our next config is...

and we still experience these issues.

[dsbrianwebster]

Hi @Haroenv thanks for the response. And yes, no doubt, def not a simple problem keeping the state and router in sync. Its feels so close 🏁 ! I've forked your sandbox to demonstrate item 2 (Routing example above)...

https://codesandbox.io/s/hooks-next-bug-3506-item-2-6ekug6?file=/pages/index.tsx

To reproduce...

1. perform a search. either a query or refinement -- anything that triggers a URL change.
2. Then click on one of the results where you will be routed to '/test'
3. The click back, the url will change but you will be stuck on the test page

Perhaps issue is something to do with how the InstantSearch component / router is unmounted.

[dsbrianwebster]

@francoischalifour + @Haroenv we've dug a little deeper on Item 1 (The Re-Render Example) and seem to have isolated the issue we're experience there as having something to do with our effort to implement an SEO-friendly URL structure. We're still investigating and will either circle back with an answer there or a sandbox example.

The sandbox provided in the previous comment is still very relevant for @Haroenv as it pertains to item #2 edge case.

[joshgeller]

I'm also experiencing the second issue (broken back button).

1. Refine hits via <RefinementList>
2. <InstantSearch> appends stringified refinements to the URL
3. Click a <Link> to go to hit content page
4. Click back, the URL changes but the page content does not

Possible clue for narrowing down the issue:

1. Refine hits with <RefinementList>
2. <InstantSearch> appends stringified refinements to the URL
3. Refresh the page (so that state is initialized from URL)
4. Click <Link> to go to hit content page
5. Click back and everything works correctly

[klaasman]

I'm running into issue no. 2 here as well, the broken back button. I think it's caused by the instantsearch.js history implementation performing it's own history mutations, over here:

https://github.com/algolia/instantsearch.js/blob/0a517609de103eef4f8edfefe6e28a1d79a14209/src/lib/routers/history.ts#L142

e.g., try the following on any app rendered by next.js (in this example I'll use https://nextjs.org/)

1. visit https://nextjs.org/
2. open dev tools console
3. run command history.pushState({}, '', '/test-foo-bar') and see the url get updated to the new pathname. (this mimics an updated url due to filtering)
4. click the nav item "Showcase" (this mimics clicking a search result)
5. hit the back button
6. the pathname goes from /showcase to /test-foo-bar, in the UI nothing happens, you'll stay on the "showcase" page.

---

~The algolia hook history API needs something like custom routing method in order to fix this.~

~e.g. calling context:~

import { InstantSearch } from "react-instantsearch-hooks-web";
import { history } from 'instantsearch.js/es/lib/routers';
import { useRouter } from "next/router";

const router = useRouter();

<InstantSearch
  routing={{
    router: history({
      // please note that `onUpdate` is not an existing part of the api
      onUpdate: (url) => router.push(url),
    })
  }}
/>

~When an onUpdate is provided the history instance should obviously no more do it's own history mutations.~

~This also alllows us to perform a history.replace() instead of history.push() which makes more sense in some filtering contexts.~

Edit: the above is already possible with a custom history handler as suggested below.

[Haroenv]

You can provide a custom router, you don't need to use history, the methods are described here https://www.algolia.com/doc/api-reference/widgets/instantsearch/js/#widget-param-routing

I'd advise looking at the implementation of the history router, because there's some edge cases we already cover there as a base

[joshgeller]

import { InstantSearch } from "react-instantsearch-hooks-web";
import { history } from 'instantsearch.js/es/lib/routers';
import { useRouter } from "next/router";

const router = useRouter();

<InstantSearch
  routing={{
    router: history({
      onUpdate: (url) => router.push(url),
    })
  }}
/>

Edit: the above is already possible with a custom history handler as suggested below.

@klaasman Do you actually have this working? Because it doesn't look like the history router accepts an onUpdate function. onUpdate is used internally, but I don't see a way to pass a custom function. Same goes for several other options mentioned in @Haroenv's link above.

It would be nice if history allowed the user to pass custom functions for onUpdate, read, write, etc. I'd rather not fork and maintain this router if I can avoid it.

Please let me know if I'm misunderstanding any of this.

[klaasman]

@joshgeller Sorry for the lack of clarity, what I meant is that it would be nice to make that onUpdate part of the api.

FYI: I've copied the original history.ts into my repo and made some adjustments in order to use the nextjs router instead - it certainly hasn't been cleaned up but feel free to take a look here: https://gist.github.com/klaasman/b0e06e8f63dbae70829424232285570c

[DB-Alex]

Hey @dsbrianwebster – this is likely because Next.js is using Strict Mode, which isn't yet supported in the library with React 18.

Our <InstantSearch> component reads the URL query params to set the initial state, and write the browser URL on unmount to reset it. This is a first-class behavior of the underlying InstantSearch.js library. The problem is that during the second Strict Mode render, the URL has been reset, and therefore the second render is unable to recover the initial state. This breaks URL synchronization.

We're working on React 18 Strict Mode support this week so you can expect a fix in the coming days.

In the mean time, could you disable Strict Mode on the <InstantSearch> component?

Can you maybe tell us the status of the Strict Mode support and good routing in next?

[francoischalifour]

@DB-Alex Strict mode support was released in v6.28.0.

Do you have other routing issues than the ones mentioned in this thread?

[saybou]

Hi @francoischalifour , i'm still experiencing the 2 issues mentioned by @dsbrianwebster (i'm using nextjs 12 & react 17), especially the broken back button

[DB-Alex]

I also have this warning:

dev: warn  - ../../node_modules/react-instantsearch-hooks-server/dist/es/getServerState.js
dev: Critical dependency: the request of a dependency is an expression

And when I switch pages in Next like this:

• Homepage -> no algolia
• Category page -> has algolia
• To homepage -> no algolia

Its crashing in the instantsearch clean up:

TypeError: Cannot read properties of null (reading 'state')

Call Stack
eval
../../node_modules/instantsearch.js/es/widgets/index/index.js (530:0)
Array.forEach
<anonymous>
Object.dispose
../../node_modules/instantsearch.js/es/widgets/index/index.js (520:0)
eval
../../node_modules/instantsearch.js/es/widgets/index/index.js (254:0)
Array.reduce
<anonymous>
Object.removeWidgets
../../node_modules/instantsearch.js/es/widgets/index/index.js (252:0)
InstantSearch.removeWidgets
../../node_modules/instantsearch.js/es/lib/InstantSearch.js (357:0)
InstantSearch.dispose
../../node_modules/instantsearch.js/es/lib/InstantSearch.js (494:0)
eval
../../node_modules/react-instantsearch-hooks/dist/es/lib/useInstantSearchApi.js (40:0)
safelyCallDestroy
../../node_modules/react-dom/cjs/react-dom.development.js (22932:0)
commitHookEffectListUnmount
../../node_modules/react-dom/cjs/react-dom.development.js (23100:0)
commitPassiveUnmountInsideDeletedTreeOnFiber
../../node_modules/react-dom/cjs/react-dom.development.js (25098:0)
commitPassiveUnmountEffectsInsideOfDeletedTree_begin
../../node_modules/react-dom/cjs/react-dom.development.js (25048:0)
commitPassiveUnmountEffects_begin
../../node_modules/react-dom/cjs/react-dom.development.js (24956:0)
commitPassiveUnmountEffects
../../node_modules/react-dom/cjs/react-dom.development.js (24941:0)
flushPassiveEffectsImpl
../../node_modules/react-dom/cjs/react-dom.development.js (27038:0)
flushPassiveEffects
../../node_modules/react-dom/cjs/react-dom.development.js (26984:0)
eval
../../node_modules/react-dom/cjs/react-dom.development.js (26769:0)
workLoop
../../node_modules/scheduler/cjs/scheduler.development.js (266:0)
flushWork
../../node_modules/scheduler/cjs/scheduler.development.js (239:0)
MessagePort.performWorkUntilDeadline
../../node_modules/scheduler/cjs/scheduler.development.js (533:0)

Here is a snippet of line 530

localWidgets.forEach(function (widget) {
        if (widget.dispose) {
          // The dispose function is always called once the instance is started
          // (it's an effect of `removeWidgets`). The index is initialized and
          // the Helper is available. We don't care about the return value of
          // `dispose` because the index is removed. We can't call `removeWidgets`
          // because we want to keep the widgets on the instance, to allow idempotent
          // operations on `add` & `remove`.
          widget.dispose({
            helper: helper,
            state: helper.state, <----- 530
            parent: _this5
          });
        }
      });

[nico-mautone]

Hi, I'm also still experiencing issue number 2, mentioned by @dsbrianwebster (i'm using nextjs 12 & react 18). Has anyone come up to a solution? The custom router implementation maybe? Thanks

[RudiPersson]

@dhayab posted a workaround using Next useRouter and useEffect in a discussion. Worked for me :)

https://github.com/algolia/react-instantsearch/discussions/3376#discussioncomment-2297218

[nico-mautone]

Thanks, but I couldn't make it work with that approach as I have a whole application with tons of search state, that is not attached to a single React useState as it is on the sandbox example. Because of that, I wasn't able to apply URL changes to the algolia UiState, because I don't have access to a function such as "setIndexUiState" provided by useInstantSearch, because hooks can't be called outside the InstatSearch Wrapper. (in the sandbox it uses directly useState setter).

[nico-mautone]

Thanks @dhmacs, I used that workaround for the moment, triggering a page reload once the popstate occurs over the search page. Something simple like this for the moment, until issue is fixed:

useEffect(() => {
    const handleRouteChange = () => {
      if (window.location.href.includes('${searchPage}')) window.location.reload();
    };
    window.addEventListener('popstate', handleRouteChange);
    return () => {
      window.removeEventListener('popstate', handleRouteChange);
    };
  }, []);

[leeran7]

I'm experiencing the same back button routing bug as @dsbrianwebster. I recreated it and you can use this vercel link and this source code to check it out.

[JulesVerdijk]

I ran into this problem as well and created a, pretty hacky, fix that seems to work (not used in production yet, so fingers crossed). What I did was taking full control of the routing, not using the router provided by Instantsearch.

Requirement for this solution is a helper that can convert an UiState to a URL (like the createURL function in the algolia router) and back again (like the parseURL function).

In basis the solution works like this:

const AlgoliaCollection: React.FC<any> = ({ serverState }) => {
    const nextRouter = useRouter();

    const onStateChange: InstantSearchProps['onStateChange'] = ({ uiState }) => {
        setUiStateFromAlgolia(uiState);
        const urlForUiState = uiStateToUrl(uiState, INDEX_NAME);

        nextRouter.push(urlForUiState, undefined, { shallow: true });

    return (
        <InstantSearchSSRProvider {...serverState}>
            <InstantSearch searchClient={algoliaClient} indexName={INDEX_NAME} onStateChange={onStateChange}>
                <RefinementList />
                <Hits />
            </InstantSearch>
        </InstantSearchSSRProvider>
    );
}

export default AlgoliaCollection;

So you now control the updating of the UiState yourself, and use this to update the NextRouter accordingly. However this is not enough, it works one way only. On onStateChange the route changes, but if you route through Next (e.g. press the back button) the UiState does not update accordingly. To be able to do this you need to be able to setUiState on a routing event, but InstantSearch does not propegate a setUiState function outside of the onStateChange prop (can we please get that Algolia?). However, this function ís available in child-components in the useInstantSearch hook. I abused this to set the UiState based on routing changes, something like this:

const UpdateStateBasedOnRoute: React.FC<{ uiStateFromAlgolia: UiState, indexName: string }> = ({ uiStateFromAlgolia, indexName }) => {
    const { setUiState } = useInstantSearch();
    const nextRouter = useRouter();

    // This fires on every uiStateFromAlgoliaChange
    useEffect(() => {
        // Create a URL based on the uiStateFromAlgolia (which is set in `AlgoliaCollection` based on the onStateChange event
        const urlFromUiState = uiStateToUrl(uiStateFromAlgolia, indexName);

        // Create a URL based on the actual route
        const urlFromRouter = nextRouter.asPath.includes('?') ? `?${nextRouter.asPath.split('?')[1]}` : ``;

        // These URLs should be identical, if not, routing has probably changed and thus the UiState should be updated accordingly
        //
        if (urlFromUiState !== urlFromRouter) {
            const newUiState = urlToUiState(`${process.env.NEXT_PUBLIC_WEB_URL}${nextRouter.asPath}`, indexName);
            setUiState(newUiState);
        } else {
            setUiState(uiStateFromAlgolia);
        }
    }, [uiStateFromAlgolia, nextRouter]);

    return null;
};

// uiStateFromServer is a URL to UiState done on the server, so the `uiStateFromAlgolia` is correct on first load
const AlgoliaCollection: React.FC<any> = ({ serverState, uiStateFromServer }) => {
    const nextRouter = useRouter();

    const [uiStateFromAlgolia, setUiStateFromAlgolia] = useState(uiStateFromServer);

    const onStateChange: InstantSearchProps['onStateChange'] = ({ uiState }) => {
        setUiStateFromAlgolia(uiState);
        const urlForUiState = uiStateToUrl(uiState, INDEX_NAME);

        nextRouter.push(urlForUiState, undefined, { shallow: true }).then(() => {});
    };

    return (
        <InstantSearchSSRProvider {...serverState}>
            <InstantSearch searchClient={algoliaClient} indexName={INDEX_NAME} onStateChange={onStateChange}>
                <UpdateStateBasedOnRoute uiStateFromAlgolia={uiStateFromAlgolia} indexName={INDEX_NAME} />
                <RefinementList />
                <Hits />
            </InstantSearch>
        </InstantSearchSSRProvider>
    );
}

export default AlgoliaCollection;

Note that I pass uiStateFromAlgolia as a prop to UpdateStateBasedOnRoute , but it is also available from useInstantSearch however I found passing it made it update more smoothly (it is a hacky solution!). With again a disclaimer that this works in a development environment but I haven’t used it in production yet.

This would work a lot more smoothly if we could actually get a setUiState prop directly on InstantSearch so this can all be controlled within the main component instead of in an empty child component.

[tadinski]

Experiencing the same routing problem as described by @dsbrianwebster in n.2 issue.

[AryanJ-NYC]

@JulesVerdijk your solution mostly worked but broke our infinite scrolling.

We've decided to go back to the old instantsearch package which is a shame.

@dhayab, is there an ETA on a fix?

[tadinski]

@dhayab posted a workaround using Next useRouter and useEffect in a discussion. Worked for me :)

#3376 (comment)

This workaround works for me.

[dhayab]

Hi, here's a sandbox with another workaround that shares some similarities with @JulesVerdijk : https://codesandbox.io/s/rish-next-router-handler-is22ev?file=/pages/%5Bcategory%5D.tsx.

It consists of a useNextRouterHandler() Hook that returns:

• an initialUiState that needs to be passed to <InstantSearch> (for SSR)
• a <NextRouterHandler /> empty component that should be mounted in <InstantSearch> (to be able to use Hooks from React InstantSearch Hooks)

It required an explicit definition of the route/state mapping, and supports Next.js dynamic routes (by specifying the route query to inject).

I tested it on some sandbox shared in the issues, and it works well. Feel free to share below if there are edge cases that are not handled by this workaround.

[AryanJ-NYC]

Hi, here's a sandbox with another workaround that shares some similarities with @JulesVerdijk : https://codesandbox.io/s/rish-next-router-handler-is22ev?file=/pages/%5Bcategory%5D.tsx.

It consists of a useNextRouterHandler() Hook that returns:

• an initialUiState that needs to be passed to <InstantSearch> (for SSR)
• a <NextRouterHandler /> empty component that should be mounted in <InstantSearch> (to be able to use Hooks from React InstantSearch Hooks)

It required an explicit definition of the route/state mapping, and supports Next.js dynamic routes (by specifying the route query to inject).

I tested it on some sandbox shared in the issues, and it works well. Feel free to share below if there are edge cases that are not handled by this workaround.

Is this workaround permanent or will react-instantsearch-hooks natively support next.js in the future?

[dhayab]

It's a temporary solution until we finish implementation and ship native support for third-party router later this year.

[tremby]

@dhayab, in my implementation it's not practical to enable the server-side rendering. I tried simply not wrapping with InstantSearchSSRProvider but while everything appears to be working, I get some Error: Loading initial props cancelled messages in the console, which concern me.

Am I right to be concerned? If so, what can I do? If not, do you know how can I suppress these errors?

Thanks so much.

[dhayab]

Hi @tremby, could you share a code sandbox where you can reproduce your issue? You can use https://codesandbox.io/s/rish-next-router-handler-is22ev?file=/pages/%5Bcategory%5D.tsx as a starting point if that helps.

[jacobsfletch]

I was able to partially fix this by syncing history changes to next/router in the background from within the createURL method, like this:

import Router from 'next/router';
import { InstantSearch } from 'react-instantsearch-hooks-web';

<InstantSearch
  routing={{
    createURL() {
      const href = 'YOUR_HREF'
      Router.push(href, undefined, { shallow: true });
      return href;
    }
  }}
/>

For more context, my project is server rendered but does not server render this component. My implementation continues to use history from the instant search router, but reports changes to next/router as they happen. Here is more of my component:

import Router from 'next/router';
import { InstantSearch } from 'react-instantsearch-hooks-web';
import algoliasearch, { SearchClient } from 'algoliasearch/lite';
import { history } from 'instantsearch.js/es/lib/routers';

const searchClient: SearchClient = algoliasearch(YOUR_APP_ID, YOUR_API_KEY);
const algoliaIndex = YOUR_ALGOLIA_INDEX;

...

<InstantSearch
    searchClient={searchClient}
    indexName={algoliaIndex}
    initialUiState={{
        [algoliaIndex]: {
            configure: {
                hitsPerPage: 12,
                filters: allFilters,
                facetingAfterDistinct: true,
            },
            ...initialURLState
        }
    }}
    routing={{
        router: history({
            parseURL({ qsModule, location }) {
                const search = location.search.slice(1);
                const parsedSearch = qsModule.parse(search) as UiState;
                return parsedSearch;
            },
            createURL({ qsModule, location, routeState }) {
                const { origin, pathname, hash } = location;
                const queryString = qsModule.stringify(routeState, {
                    encode: true,
                    arrayFormat: 'repeat',
                    addQueryPrefix: true
                });

                const encodedString = queryString // try and keep a human-friendly url, decode brackets
                    .replace(/%5B/g, "[")
                    .replace(/%5D/g, "]");

                const href = `${origin}${pathname}${encodedString}${hash}`;

                Router.push(href, undefined, { shallow: true });

                return href;
            },
        }),
        stateMapping: {
            // @ts-ignore
            stateToRoute(uiState: UiState): IndexUiState {
                const indexUiState = uiState[algoliaIndex];
                delete indexUiState.configure;
                return indexUiState;
            },
            // @ts-ignore
            routeToState(routeState: IndexUiState): IndexUiState {
                return routeState
            },
        },
    }}
>
    ...
</InstantSearch>

[jacobsfletch]

^ To add to my comment above, this is considered a "partial fix" because it only fixes full-page transitions, not shallow ones. Here's a breakdown:

Works:

1. Filter the search
2. Click a result
3. Once there, click "back" using native browser navigation
4. Returns to previous page with the previous filters correctly applied

Does not work:

1. Filter the search
2. Click "back" using native browser navigation
3. Changes the URL correctly but does not apply the search filter