Allow rendering an entity viewmode when using fields in views

This seems quite major feature. Is there any other way to get rendered entity + excerpt at the moment? I don't want to add fields to the view because different content types have different fields and they are a lot easier to manage in the display mode settings.

Are you sure this was possible in D7?
But it's a good idea anyways, sure. Just not a priority at the moment.

The attached patch adds a Rendered Entity views field for Search API.

Updated search_api.views.schema.yml with the new field.

I haven't tested the patch yet, but it already looks pretty good, thanks a lot!
However, I do have several high-level remarks:

1. Why do you add the field to the datasource tables, and not the index table? Seems to me, this should go into _search_api_views_data_special_fields().
2. (If it's on the datasource table, it also doesn't make sense to have the view mode setting per entity type – there's only ever at most one entity type in a datasource.)
3. It's unnecessary to restrict this feature to entities: we already have all of this abstracted for any search item in general. The whole functionality can really just be copied from SearchApiRow. In my opinion, it should just work exactly the same way.

Yes, this was loosely based on

1. I was try to get it added to hook_views_data and _search_api_views_data_special_fields() does not get passed the $datasource which was needed to determine $entity_type->hasViewBuilderClass().

2. You can configure a mixed entity type index. In the index configuration, check on Content and Taxonomy Term. Use case = Taxonomy vocabularies that are used as landing pages for all the content tagged with their terms. That said, it's probably best practice to have common view modes for each entity type.

3. This was loosely based on Drupal\views\Plugin\views\field\RenderedEntity and SearchApiRow. The former was used to get the translation rendering correct. If the datasource viewItem() does this, then entity types could be abstracted out of it.

Here is a new patch loosely based on @recrit's patch.

I've tried to take on board your suggestions.

There is now one Rendered Entity field per datasource.

In the options form the UI could be improved. I notice that in some views' fields view modes can be chosen per bundle, in others per entity type. So I tried to support both.

Missed some dependency..

Phew..

A lot better already, thanks!

Still some complaints, though:

1. You completely ignored my remark #3 – as said, it doesn't have to depend on entities, just take the code from \Drupal\search_api\Plugin\views\row\SearchApiRow.
2. It should then probably also be called "Rendered item", "Result item", or similar – not really sure why we left "entity" in the label for the row plugin.
3. The Views data definition missed the optional 'real field' entry which the other "special fields" have – see attached patch.
4. I don't think there actually is a field_item:rendered_entity data type? Why do you add that? The field handler isn't even designed to work with an individual field, so even if the declaration had any effect, it would just be to produce a bug.
5. getEntity() can just use $values->_item->getOriginalObject(), which will always work.
6. Also, this definitely needs tests before we can commit it. Probably just need to add the field to one of the test views in ViewsTest, though.

Back again, thanks for all your suggestions:

re 1&2 - I've renamed everything to Item/_item and used more or less a copy of SearchApiRow as you suggested.
re 4 - no idea, but removed now
re 6 I'm trying to work on this now

Fix schema

Thanks, good job! Found some minor problems (some of them also present in the row plugin), but otherwise this only seems to need tests. (Unless my edits broke something.)
In the future, please just also include an interdiff when posting new patch revisions. (Though, I guess, in the case of #14 the interdiff is pretty useless.)

Oops, sorry, stupid mistake – confused the Views' special defineOptions() with the Plugin API's defaultConfiguration().

I'm getting the following PHP warning with patch #18 (Search API 8.x-1.7):

Strict warning: Drupal\search_api\Plugin\views\field\SearchApiRenderedItem and Drupal\search_api\Plugin\views\field\SearchApiFieldTrait define the same property ($entityTypeManager) in the composition of Drupal\search_api\Plugin\views\field\SearchApiRenderedItem. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed in require() (line 192 of modules/contrib/search_api/src/Plugin/views/field/SearchApiRenderedItem.php).

It still works fine though.

Here we go. The entityTypeManager property as well as corresponding getter and setter are already declared in SearchApiFieldTrait.

Thanks for spotting and already fixing this, looks good!
Now it seems this just needs tests and we can commit it. (Additionally, other people confirming it works for them would of course also be great.)

many many thanks for this patch!

it saved me in leaflet based view where i can select a node display or fields for the popup in normal views, but only fields in search api based views.

so RTBC from my side (as soon as tests are implemented)

Patch #20 works great for me.
Thanks a lot, guys!

Alright, thanks for reporting back!
Since there seems to be a lot of interest (and positive feedback), I now went ahead and also added the tests. If the attached patch still works for everyone (and passes the tests), I can finally commit it.

Tested patch #24 with Drupal commerce (Product entity) and there it works perfectly fine!

I read through the patch-code, but kinda superficial. Code itself looks very clean to me. No typo's or obvious misbehaviours.

What comes to mind that might need review are these edge cases. I didn't see test-coverage for these edge cases.
- Behaviour of bundles without view-modes
- Behaviour of entities without bundles
- Behaviour of bundles/entities with only non-standard view-modes (no full, no teaser)

Thanks a lot for both testing and reviewing, very much appreciated!

I think we can get away with not having automated tests for those special cases – the worst that could happen is that it doesn’t work there and we have to fix and add regression tests – but I’m pretty sure these situations should all be handled fine.

Unfortunately, this now needed a re-roll, but with this it should be RTBC (if the test bot agrees).

The testbot agrees, and I do as well.

Awesome, thanks for reviewing!
Committed.
Thanks a lot again, everyone!