combinedAnswers.attributesToDisplay?.filter is not a function

[omidontop]

🐛 Current behavior

In a custom template, we used to be able to send in a dictionary as the attributesToDisplay in order to provide some additional attributes for the template engine to display. The referenced line breaks that possibility.

instantsearch/packages/create-instantsearch-app/src/cli/postProcessAnswers.js

Line 68 in c841133

attributesToDisplay: combinedAnswers.attributesToDisplay?.filter(

Here's en example of how our config looks like:

    "attributesToDisplay": {
        "title": {
            "href": "url",
            "text": "hierarchy.lvl2",
            "highlight": true
        },
        "subtitle": {
            "text": "hierarchy.lvl1"
        },
    },

🔍 Steps to reproduce

1. Use a dictionary as the value of attributesToDisplay parameter.
2. Run create-instantsearch-app.

Live reproduction

https://codesandbox.io/p/devbox/lh2cmc

💭 Expected behavior

Run ./create in a terminal and witness the error.

Package version

4.64.2

Operating system

macOS 14.2.1

Browser

Firefox 122.0

Code of Conduct

• I agree to follow this project's Code of Conduct

[Haroenv]

attributesToDisplay is meant to be an array of strings, I wonder if what you're looking for is a separate data-bag to store these more "static" information. Would that help your use case?

Something along the lines of:

{
  // ... other configuration
  "attributesToDisplay": [],
  "data": {
    "hit": {
      "title": {
        "href": "url",
        "text": "hierarchy.lvl2",
        "highlight": true
      },
      "subtitle": {
        "text": "hierarchy.lvl1"
      }
    }
  }
}

If you're interested in that, we'd be happy to see a PR adding a new data field from config that's copied over to the template variables.

[omidontop]

Thanks for the response @Haroenv. Well the benefit of being able to use a dictionary rather than an array is extending its usability which also eliminates the need for a loop when it comes to using them in the template. Unless there is an easier way to know whether attributesToDisplay contains title for example which seems to be a handlebars shortcoming. Consider this usage:

{{#if attributesToDisplay.title}}
{{#if attributesToDisplay.title.href}}
<a class="text-decoration-none" href="\{{attributesToDisplay.title.href}}">{{attributesToDisplay.title}}</a>
{{/if}}
{{/if}}

The attributesForFaceting seems to tolerate non-array structures:

{
    attributesForFaceting:
        Array.isArray(combinedAnswers.attributesForFaceting) &&
        combinedAnswers.attributesForFaceting.filter(
            (attribute) => attribute !== 'ais.dynamicWidgets'
        ),
}

[Haroenv]

I see your use case, but attributesForFaceting also doesn't tolerate non-array shapes, it in fact completely ignores the value and will put false if you put anything but an array of strings. I'm still happy to approve a purpose-built feature though. You're right that attributesForFaceting and attributesToDisplay are inconsistent, so I'll make a fix to reject non-arrays in both in the same way.

[omidontop]

@Haroenv Perfect! Since I'm using it in a custom template, I can live with that for now. Thank you :)