SSR support for Next.js 13 /app directory?

[pruthvi145]

Hi Team, do you have any plan to support Next.js 13, specially for the SSR?

I tested for the client-side rendering, seems working so far. Few routing issues but those are already addressed here.

However, SSR is not working at all with the /app directory (beta). Feels like need the changes in the react-instantsearch-hooks-server package.

[Haroenv]

We haven't yet tried the beta app directory. At the moment I'm not sure where it would fit in, as they expect usage of fetch directly, while we use our own API client, and it requires knowing which widgets will be rendered in a two-pass process.

[philwolstenholme]

We (http://shop.coop.co.uk) are starting to rebuild our site in Next 13 and we would love to see support for the new app router. At the moment it looks like we'll be using the app directory for the majority of our site, and it will be a bit inconvenient to have to also set up page layouts etc to work with the pages directory just for InstantSearch.

@Haroenv it might be worth engaging with some of the Next/Vercel developer relations team (led by @leerob) to see if they can give any advice on your query/thought above.

I also noticed that the Next 13 app router docs have a section on data fetching without fetch (it's not mandatory): https://beta.nextjs.org/docs/data-fetching/fetching#data-fetching-without-fetch and there is also the use hook (https://beta.nextjs.org/docs/data-fetching/fetching#use-in-client-components) that can be used on the client-side to play nicely with React Server Components.

[Colton]

My team would also benefit from support for SSR in the /app directory. I would be happy to contribute as well.

[christiankaindl]

The react-instantsearch-hooks-router-nextjs package also doesn't support the NextJS 13 app directory at the moment. Is there a roadmap for app dir compatibility?

[aymeric-giraudet]

From what I've experimented, it seems the app router does not rely on having __N is history state anymore, so I don't think it'll be needed. Back button should work out of the box.

[philwolstenholme]

The app router (previously known as the app directory) in Next.js just got made stable, so it's now a stable target to start working on, and I imagine adoption in Algolia's customers will increase: https://nextjs.org/blog/next-13-4

[Colton]

Hey all,

Just wanted to bump this issue again. We worked around this by going client-side but I'd like to know if there's any plans for addressing this on the roadmap. Thanks!

[naseef0]

Any updates on this?

I'm also waiting for a proper solution with Next js 13 app dir.

[tilman]

@Haroenv can you give an update on this topic? Is it on your roadmap or can we expect to build a solution on our own with direct API access if we want to realize a app-router project within the next half year?

[Haroenv]

#5413 (comment)

[Haroenv]

While use is not yet stable, we do have an example on how to use React InstantSearch Hooks with React Server Components.

There are some caveats that prevent us from documenting this officially

• React's use is not stable, sometimes causing infinite renders
• access to the router isn't possible / straightforward in Next App dir
• all code (including renderToString) is bundled for the client as well
• in some cases getServerState is executed client-side, which isn't needed and can cause more network requests than needed

Those caveats taken in account, here's an example: https://codesandbox.io/p/sandbox/interesting-rhodes-4pgtu6?file=%2Fapp%2Fpage.tsx

"use client";

import React, { use } from "react";
import algoliasearch from "algoliasearch/lite";
import { Hit as AlgoliaHit } from "instantsearch.js";
import {
  DynamicWidgets,
  InstantSearch,
  Hits,
  Highlight,
  RefinementList,
  SearchBox,
  InstantSearchSSRProvider,
  InstantSearchServerState,
} from "react-instantsearch-hooks-web";
import { renderToString } from "react-dom/server";
import { Panel } from "../components/Panel";
import { getServerState } from "react-instantsearch-hooks-server";

const client = algoliasearch("latency", "6be0576ff61c053d5f9a3225e2a90f76");

type HitProps = {
  hit: AlgoliaHit<{
    name: string;
    price: number;
  }>;
};

function Hit({ hit }: HitProps) {
  return (
    <>
      <Highlight hit={hit} attribute="name" className="Hit-label" />
      <span className="Hit-price">${hit.price}</span>
    </>
  );
}

type SearchPageProps = {
  serverState?: InstantSearchServerState;
};

function Search({ serverState }: SearchPageProps) {
  return (
    <InstantSearchSSRProvider {...serverState}>
      <InstantSearch
        searchClient={client}
        indexName="instant_search"
        insights={true}
      >
        <div className="Container">
          <div>
            <DynamicWidgets fallbackComponent={FallbackComponent} />
          </div>
          <div>
            <SearchBox />
            <Hits hitComponent={Hit} />
          </div>
        </div>
      </InstantSearch>
    </InstantSearchSSRProvider>
  );
}

function FallbackComponent({ attribute }: { attribute: string }) {
  return (
    <Panel header={attribute}>
      <RefinementList attribute={attribute} />
    </Panel>
  );
}

export default function SearchPage() {
  const serverState = use(
    getServerState(<Search />, {
      renderToString,
    })
  );

  return <Search serverState={serverState} />;
}

Remember as well that when you use App dir, you don't have to convert your entire app at once, you can leave the search page as a regular "pages" component.

[destino92]

Can you add routing to this snippet please?

[aymeric-giraudet]

Hi @destino92 you can see it in this comment : #5413 (reply in thread)

Although it's still pretty unstable because of use

[philwolstenholme]

Remember as well that when you use App dir, you don't have to convert your entire app at once, you can leave the search page as a regular "pages" component.

This is what we're doing at the moment for our search page and category/taxonomy page, but it's not ideal – there is a hard browser navigation/load as users move between the app router and pages router, and it also means some duplication of our layout approach to support both router types, remembering to wrap both app and pages with the right context providers when we add new providers, etc.

Thanks a lot for sharing the experimental example, it's great to see that your team have been looking into this :)

[timmeade]

Not really an option for us as we are converting to new app dir in next js and going backwards to the pages folder just is not an option. We have instantsearch working under new structure except for routing section. And nothing we try seems to work.

Could be the algolia deal breaker. Seems we would have a working option by now. It's been months. Answer above is not "answer" as it does not contain routing.

[philwolstenholme]

@leerob - sending a big +1 from this Vercel customer and Next user for seeing if the Vercel devrel team can help out the Algolia team with their app router implementation, please and thank you!🙏

[timmeade]

@leerob another +1. @aymeric-giraudet Thanks for the work. The CSB looks good. Let me dig through it and see if we can make it work.

[timmeade]

@aymeric-giraudet maybe you can help.

We have it working except we are using a CustomHits component. On the old pages version when an item was clicked using a Link tag the window closed.

Under the app dir when the item is clicked the url does change and new pages load, but the window/modal opened in CustomHits stays in place on top. The data under the open search actually changes. I think if we were to 'clear' the current search during the click on Link that it would go away. Any of this ring a bell?

Thanks again

[timmeade]

The sandbox above does not work in code.

  const serverState = use(
    getServerState(<Search serverUrl={serverUrl} />, {
      renderToString,
    })
  );

triggers the

Unhandled Runtime Error
Error: async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding 'use client' to a module that was originally written for the server.

[destino92]

@leerob +1 please

[aymeric-giraudet]

Hey all, I'm updating this discussion with news !

We released an experimental package which supports Next.js App Router, you can check its usage there : https://www.algolia.com/doc/guides/building-search-ui/going-further/server-side-rendering/react/#app-router-experimental

Don't hesitate to provide feedback right here !

A few drawbacks we already know of are that using the browser's forward button from one InstantSearch page to another can have issues, and there currently is a useless query being made on the client but it will be fixed by #5854

[aymeric-giraudet]

@buesing

If React 19 releases with use working as it does, i.e. pausing the component rather than hook, I think we could provide an option to have our hooks such as useRefinementList not call use themselves, and provide a hook like useWaitForResults that you could call after all these hooks. Can't think of another alternative for now but at least this would work.

Thanks again for your feedback, we'll make sure to address this once we release the stable version !

[LuudJanssen]

Hi @aymeric-giraudet, another alternative might be to work towards a more promise-based API, where the developer is in control of using use in the component itself (and also prevent possible waterfalls). This would create a more bloated syntax, but as a tradeoff for flexibility. Example:

"use client";

function SearchResults() {
  const { query, resultsRequest } = useInstantSearch() // resultsRequest is just a promise
  const otherWorkRequest = doSomeOtherWork(query) // also returns a promise
  
  const [results, workResponse] = use(Promise.all([resultsRequest, otherWorkRequest]))
  
  // ...
}

I'm not convinced this is the right approach, but I would like the flexibility of preventing a request waterfall (if useInstantSearch() would suspend, doSomeOtherWork wouldn't be called until after the suspension of useInstantSearch() was resolved).

[Haroenv]

@LuudJanssen, that may make sense for the initial query on server, but likely wouldn't work for any subsequent requests, where the promise shouldn't prevent rendering (otherwise you can't do optimistic UI)

[LuudJanssen]

Hi @Haroenv! If you want to do optimistic UI, resultsQuery could be a resolved promise. I believe use() won't suspend if the promise is already resolved. Am I understanding you correctly?

[bartfluitsma]

@aymeric-giraudet I have the same issue as @wesleyjanse is experiencing. Also, when I load my page that contains the InstantSearchNext directly, I don't get any warnings. But if I start at a different page (like my homepage) and browse to or switch between the page with InstantSearchNext, I get a mounted/unmounted warning. I gets pretty messy with the multiple renders of results.

Guess that's the same issue others are experiencing. Is there a way around it for now?