Algolia Search returns objects but they aren't visible - Uncaught (in promise) TypeError: e.hierarchy is undefined

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I’m using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

building a site to help people working with medical device regulations.

When inspecting network packets on the site (regardless of netlify or localhost) I see search results in the algolia response but the search widget doesn’t show them.

When search is used the console throws this error Uncaught (in promise) TypeError: e.hierarchy is undefined

This bug occurs even with a fresh project npx create-docusaurus@latest standlet_fresh2 classic (and the typescript version)

(I disabled contextualSearch, set APIkey, AppId, indexName)

Here my index config from algolia perhaps its related to searchableAttributes? I tried adding hierachry.lvl0 … lvl6, but that didn’t work (also seemed random)

{ "settings": { "minWordSizefor1Typo": 4, "minWordSizefor2Typos": 8, "hitsPerPage": 20, "maxValuesPerFacet": 100, "searchableAttributes": [ "unordered(content)", "unordered(section)", "unordered(title)", "unordered(permalink)" ], "numericAttributesToIndex": null, "attributesToRetrieve": null, "allowTyposOnNumericTokens": false, "unretrievableAttributes": null, "optionalWords": null, "queryLanguages": [], "attributesForFaceting": [ "content", "section", "title" ], "attributesToSnippet": null, "attributesToHighlight": null, "paginationLimitedTo": 1000, "attributeForDistinct": "permalink", "exactOnSingleWordQuery": "attribute", "ranking": [ "typo", "geo", "words", "filters", "proximity", "attribute", "exact", "custom" ], "customRanking": null, "separatorsToIndex": "", "removeWordsIfNoResults": "none", "queryType": "prefixLast", "highlightPreTag": "<em>", "highlightPostTag": "</em>", "snippetEllipsisText": "", "alternativesAsExact": [ "ignorePlurals", "singleWordSynonym" ], "indexLanguages": [], "renderingContent": { "facetOrdering": { "facets": { "order": [ "title", "content", "section" ] }, "values": { "content": { "sortRemainingBy": "count" }, "title": { "sortRemainingBy": "count" } } } } }, "rules": [], "synonyms": [] }

Reproducible demo

https://github.com/ottozastrow/indexAnyFrontend

Steps to reproduce

npm run build npm run serve search something and what console network log

Expected behavior

display algolia search results

Actual behavior

displays nothing in search widget and throws error on console.

Your environment

• Public source code:
• Public site URL:
• Docusaurus version used:
• Environment name and version (e.g. Chrome 89, Node.js 16.4):
• Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Self-service

• I’d be willing to fix this bug myself.

[shortcuts]

algolia asks to send them the formatted data.

Indeed, but DocSearch requires a hierarchical structure of records to reflect it in the UI, we have a small description here: https://docsearch.algolia.com/docs/legacy/how-do-we-build-an-index/

(Seems like in the past there was only their crawler, which is now proprietary)

The open-source scraper is still available if you’d like to use it or replicate the indexing/record structure. It’s hosted on the algolia/docsearch-scraper repository

[shortcuts]

ah interesting - will try that. But I understand correctly that in theory both methods should work (docsearch crawler vs me using my existing structure).

You can use any way to index data, but the record structure in the Algolia index must match the one read by the frontend library (hierarchical). The alternative of keeping your structure would be to apply pre-rendering logic on the frontend (via transformItems for example), but it would have an impact on your performances/users.

But that I should try the other (docsearch), that is kind of “legacy” but still in practice

It’s not what we use in prod anymore so it’s legacy but would still do the job for most of the websites