Recommend's hooks does not handle errors

[axel-lcdp]

Description

Recommend React's hooks does not gracefully handle errors, and errors cannot be caught in React's ErrorBoundary.

For more context :

We are using Algolia's recommend on production and staging environment.

The production environment's index works. The staging environment's index does not build as it has not enough data (less than 1'000 events).

However, when we are running our tests against the staging env, all requests fail because the index does not exists (as it cannot build). The problem, is that all errors cannot be caught and results in React throwing an error.

For instance, in useFrequentlyBoughtTogether.js line 42 :

useEffect(() => {
  setStatus('loading');
  getFrequentlyBoughtTogether({
    // ...
  })
    .then((response) => {
      setResult(response);
      setStatus('idle');
    })
    // missing catch, resulting in error not being catch by React
}, [
  // ...
]);

It would be great to gracefully handles errors in each hook.

Reproduction

The linked codesandbox does not work. It results with an error /app.tsx: Unexpected token (133:105).

Steps

To reproduce the error, you may :

1. Configure recommendClient with a wrong client
2. Use an index that does not build
3. Ask for a non-existent objectIDs

Expected behavior

Error should be gracefully handled by React / hooks.

Environment

• OS: macOS
• Browser: Chrome
• Library version: 4.14.3

[raed667]

Hey @axel-lcdp thank you for raising this issue and the proposed fix, we are looking into it!

As for the codesanbox, apologies for the inconvenience, we just pushed a fix. You can find both the React example for reproduction.

[GeryDuComptoirDesPharmacies]

Hi @raed667 any news about when the fix proposed by @axel-lcdp will be merged ?

[raed667]

Hey @GeryDuComptoirDesPharmacies

We're looking on how to handle error boundaries in a consistent way across the different libraries.

The change proposed above (as well as #137 ) is a breaking change so we're careful to get it right if we go this route about error management.

Edit: I removed the code example, because status: "stalled" could also happen in case of a slow network response and not just for errors.

Out of curiosity what kind of errors are you trying to catch in your use-case ?

[GeryDuComptoirDesPharmacies]

Hi @raed667,

There is the error we are trying to catch.

{
    "name": "ApiError",
    "message": "Index does not exist",
    "status": 404,
    "transporterStackTrace": [
        {
            "request": {
                "data": "{\"requests\":[{\"indexName\":\"<unknow_index>\",\"objectID\":\"xxx\",\"threshold\":0,\"fallbackParameters\":{},\"model\":\"bought-together\"},{\"indexName\":\"<unknow_index>\",\"objectID\":\"xxx\",\"threshold\":0,\"fallbackParameters\":{},\"model\":\"bought-together\"}]}",
                "headers": {
                    "content-type": "application/x-www-form-urlencoded"
                },
                "method": "POST",
                "url": <URL>,
                "connectTimeout": 1,
                "responseTimeout": 2
            },
            "response": {
                "content": "{\"message\":\"Index does not exist\",\"status\":404}",
                "status": 404,
                "isTimedOut": false
            },
            "host": {
                "protocol": "https",
                "url": "xxxx-dsn.algolia.net",
                "accept": 1
            },
            "triesLeft": 3
        }
    ]
}