Create a configurable search api processor for XB data

For example, Search API ships with a 'Rendered entity' processor plugin that lets you configure a view mode to use for each entity-type bundle. During indexing this plugin renders the entity and the results can be used in a search API index. This is typically combined with something like a strip HTML processor and one that weights e.g. h2/h3 higher. This is however not very precise, if you have a common footer component on every page those elements end up in the index for every page.

The proposed solution should provide a list of enabled component config objects and a checkbox for each of their props.
For example, you might have a card component with fields for image, title and teaser text.

It's not clear to me how this would interact with non-XB field data on the entity (title, intro, hero image etc.)

Let's assume that those entity-level fields are configured within an XB layout, then does the processor also handle how those are rendered for search indexing, or do you need to set up both a search view mode and this processor side by side - one for the entity-level fields, and one for the XB props?

This is however not very precise, if you have a common footer component on every page those elements end up in the index for every page.

We are using the view builder for an entity to run this, so footers/header will not be included directly, this should only render the main content, so that's only the case of a call to view() also includes a header and footer.
https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/src/Plugin/...

The proposed solution should provide a list of enabled component config objects and a checkbox for each of their props.
For example, you might have a card component with fields for image, title and teaser text.

This means that for every new component I create, I need to configure this processor? Or will it include new ones by default? Why would we do this at the Search API level and not on a new view mode?

As one of the people who's written parts of Search API's backend interface, I wonder how well that UI will work for the target audience of drupal cms. Search API is very powerful, but that power also gives you quite some configuration options. I don't think the target audience of experience builder will find joy in using our UI.

I also wonder how this will work with react components that are created through the ui, will we have to do some kind of parsing to get their data out? What if it uses some kind of API or Javascript service to create content, will those we have to render the javascript from the backend?

I think instead of creating a new processor, we might have to create a new DataSource instead? That datasource could do the specific rendering/fetching of data without it having to go in a processor with it's own form.

I think supporting this through an alternative view mode, is probably the better way to go instead of using a processor like this?

Heck yes to configuration via view mode please.