is anyone using `react-instantsearch-nextjs`? I ha...
# community-help
f
is anyone using
react-instantsearch-nextjs
? I have a problem with cases when the typesense server is down. I'm trying to add support for error boundaries for the instant-search component but without any success 😞 The Axios error: "unhandledRejection: ref *2 AxiosError [AggregateError]..." crashes my entire nodejs server 😕
basically this breaks the whole nextjs server
the error comes from the ApiCall.ts in the typesense-js
j
CC: @Fanis Tharropoulos
f
Could you create a reproducible example so I can take a look at it myself?
f
Sure, I'll prepare it over the weekend
🙌 1
Hi @Fanis Tharropoulos! 👋 Have take a look: https://github.com/fnowacki/nextjs-typesense-instantsearch-bug I prepared the basic demo. To run: npm install & npm run start and then try to navigate to the localhost:3000 - the nextjs instance will crash&loop It's a 1:1 with my original issue from the thread, I'd be happy to solve this issue with you.
f
I'll have to look at this tomorrow morning (it's 9PM in Greece atm). Will report back once I've figured this out
f
Sure! We're almost in the same timezone. Have a good night! We're in touch 🤙
🙌 1
f
Have a great night yourself! 👋🏻
Just checked this out. So, when you're using a non-existing host / address, the process hangs and can't be `^C`'d (though it can be done when running in a dev env). What would the desired behavior would be in that case?
f
Yeah, that's the point, whenever the typesense server is not available (I mean !== 2xx), I'm not able to try-catch this. In the ideal world, it would be nice to somehow handle this and show the error message on the frontend instead of crashing the nextjs server
f
This seems to be an SSR problem. Since this is all handled in the server, you can't try-catch the rendering process. You could just use client-side rendering if you do have many cases where you might call out to a non-existing typesense server. But ultimately, it comes down to it serving the html from the server itself. Verified that it continues to service the other endpoints, and just hangs on that one. So the server itself isn't crashing
You could even use
useEffect
for the searchclient to verify that a healthcheck will pass and then try to serve the page
f
so we can't add support for unavailability of the typesense server in the adapter? or at least add a handler to catch it in try-catch?
f
What the adapter itself does is just change the request params / request response to match what Typesense expects as opposed to the Algolia implementation. It then uses the Typesense js library to make that call out to typesense itself. So if anything were to change in some of the two libraries, it would most probably be in the ts/js main library. When using InstantsearchNext, all the requests to Typesense happen before rendering, so the resulting can't be rendered and as such, no page will be visible. The try-catch behavior you're describing would be applied to which part of the code, though? Could you provide an example of how you would want to use try-catch logic?d
f
That's clear. Hmm, maybe something like this?
Copy code
// ...
try {
return (
<InstantSearchNext client={typesenseAdapter}>
// ..
</InstantSearchNext/>
)
} catch () {
// ...
}
But you've right, probably the fix needs to be applied in the main lib
f
This involves changing InstantsearchNext's implementation, as the render function there is responsible for the end error thrown. If you're adamant on using both SSR with some sort of unstable typesense server, I'd suggest fetching the health result of your typesense server, before returning the jsx, e.g.:
Copy code
export default function Search() {
  try {
      await client.health.retrieve();
  } catch (error) {

  }

  return (
    <InstantSearchNext
      searchClient={typesenseInstantsearchAdapter.searchClient}
      indexName="games"
      routing
      future={{ preserveSharedStateOnUnmount: true }}
    >
...
f
that's a good workaround, thanks for your help! ❤️
🙌 1
f
Copy code
'use client';

import type { SearchClient } from 'instantsearch.js/es/types';
import { InstantSearchNext } from 'react-instantsearch-nextjs';
import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter';
import { Client } from "typesense"
import { Hits } from './hits';

const adapter = new TypesenseInstantSearchAdapter({
    server: {
        nodes: [
            {
                host: 'wrong-host',
                port: 8808,
                protocol: 'http',
            },
        ],
        apiKey: 'xyz',
        retryIntervalSeconds: 2,
    },
    additionalSearchParameters: {
        per_page: 20,
        query_by: 'name',
    },
});

const client = new Client({
    nodes: [
        {
            host: 'wrong-host',
            port: 8808,
            protocol: 'http',
        },
    ],
    apiKey: 'xyz',
    connectionTimeoutSeconds: 2,
    retryIntervalSeconds: 2,
})


export async function Search(): React.ReactNode {
    try {
        await client.health.retrieve();
    }
    catch {
        console.error('Failed to connect to Typesense server');
        return <div>Failed to connect to Typesense server</div>;
    }
    return (
        <InstantSearchNext searchClient={adapter.searchClient as SearchClient} indexName="example_index" future={{ preserveSharedStateOnUnmount: true }}>
            <Hits />
        </InstantSearchNext>
    );
}
This is the full file of
search.tsx
that addresses this, hope this provides some help!
❤️ 1