Allow configuring index settings from the queries

[janosh]

I need to specify certain attributes to be snippetable. Unlike highlighting, snippeting has to be enabled proactively on a per-attribute basis.

Of course, I can manually specify snippetable attributes in Algolia's web interface. However, it appears as though gatsby-plugin-algolia overwrites these settings on every build. Having to reset those regularly would be quite the hassle.

The docs state that this can also be done programmatically using something like

index.setSettings({
  attributesToSnippet: [
    'content:80',
    'description'
  ]
});

Does this carry over to gatsby-plugin-algolia and if so could this be documented somewhere?

FYI, I tried the following without success:

const queries = [
  {
    query: pageQuery,
    transformer: ({ data }) =>
      data.pages.edges.map(({ node }) => ({
        title: node.title.title,
        slug: node.slug,
        ...node.body.data,
        objectID: node.id,
      })),
    indexName: `Pages`,
+    setSettings: {
+      attributesToSnippet: [`excerpt:15`],
+    },
  },
]

[Haroenv]

It's not a feature I added initially, since you were able to set them manually, but the change to never-down indexing broke that, since it now will move that staging index into the production index.

We have two options here:

1. gatsby-plugin-algolia is the main source of truth

   adds the settings to the Gatsby plugin, always set them and override anything set in the dashboard

2. the dashboard is the source of truth

   No settings allowed via Gatsby, but it will copy over those from the main index.

I'm personally leaning towards the first option; since it allows you to declaratively set the settings with the code.

Another option is something between those two options, where we can merge from the dashboard and the code, but that's likely going to cause confusion.

What's your POV on this?

[janosh]

What's your POV on this?

Same here. I also think declaratively is the way to go. Otherwise people who fork the repo would have to manually pick those settings, meaning you would have to include them in the readme. It's usually a lot nicer to keep everything self-contained.

Perhaps you could offer a flag by which people could choose themselves between options 1 and 2 and make option 1 the default.

[Haroenv]

One option to avoid the flag is to check if settings is available in the config, and only set & override if it's given.

[janosh]

Ah yes, that would work nicely as well!

And regarding the possibility of merging dashboard and code settings, I agree that would likely cause more trouble than it's worth.

[syivanes]

Hello guys! I need some practice and this project and issue both look interesting. Which route should I go with for the settings?

[Haroenv]

Hey @syivanes! The way to go is:

1. add settings key (optional) to the queries array
2. read it, and call setSettings on the index to the temporary index, before it's moved to the main one
3. test it out on the example

Ideally there'd be real tests here, but I didn't add them yet, because I was still unsure which parts of the Gatsby life cycle to mock and which not to.

This should comfortably fit in a trial & community Algolia plan, but let me know your appId if you need bigger quota.

Let me know if you have any questions!

[syivanes]

Cool! Gatsby and Algolia are both foreign to me, but I'll dig in.

[Haroenv]

Don't hesitate to reach out in a more direct medium like twitter DM (I'm in EU time zone though) if you have any more questions) for this!

[janosh]

@Haroenv I implemented the ability to specify settings programmatically in PR #17. Also tested it.

[Haroenv]

PR has been merged, I'll test some things out in the coming weeks and try to add tests, then I will release it, in the meantime you can use your own fork :)

[janosh]

Okay. Would be great though, if this could be released sooner rather than later. Let me know if I can help with the tests.