Add ability to control the number of values in the Search API views fields

Sounds like useful functionality, thanks a lot for posting!
However, your patch doesn’t apply, and also contains lots of unrelated formatting changes. Could you please try again to only create a patch for the relevant parts, based on current dev?

Also, even though this seems pretty straight-forward, it would be great if we could add some test coverage for this to \Drupal\Tests\search_api\Functional\ViewsTest.

Re-rolled to help with review. Still needs tests

@drunken monkey, what should be tested here? This changes the rendered output so it can't be included in the query.

Maybe it could be included in the test for submitting the field handler config form.

Thanks for posting the re-roll, and sorry that I apparently overlooked it back then.

The patch looks like a good approach, but I do have a few comments:

•   +++ b/src/Plugin/views/field/SearchApiFieldTrait.php
    @@ -1228,6 +1238,9 @@ trait SearchApiFieldTrait {
    +      if ($show = intval($this->options['multi_show'])) {
    +        array_splice($items, $show);
    +      }
    

  This doesn’t seem like it would work correctly for positive values. I think you’ll need to check whether the value is positive or negative. (Also, array_slice() seems like a better fit than array_splice() – but both would work, of course, when called correctly.)

• I think the form element type should be number, not textfield. The trick with “all” currently only works in English (or languages which, by chance, have the same word for “all”) anyways, and would be a bit awkward to make work in a multilingual way, I think.
  Please also see the improvements made in the meantime to \Drupal\views\Plugin\views\field\EntityField::multiple_options_form() and apply those to the patch. Seems like this would improve the translatability of the label.
• Why is the option called multi_show, and not delta_limit like in Core?
• Whatever the option is called, it will need to be added to search_api.views.schema.yml.

@drunken monkey, what should be tested here? This changes the rendered output so it can't be included in the query.

Maybe it could be included in the test for submitting the field handler config form.

The rendered output should be tested, of course: Configure a field with multiple values to display only a subset, and then verify that the results are displayed correctly in the search view.
But testing the config form, especially if we add validation, might also make sense.

Thanks everyone for your efforts.

I created a MR that implements the full feature as it is in core's EntityField.

It provides four new options, following core's approach:
1. delta_limit
2. delta_offset
3. delta_reversed
4. delta_first_last

A test covering all of the above options was also added.

Attaching a static patch file to use with composer.

Brilliant, thanks a lot for your work! Looks very good, I just made a few small modifications. Do these look good to you?

In any case, would be great to get feedback from someone else, too, but if no-one pipes up I’d still merge this in a week or two, I think. A functional test would have been nice to have, too, but should be fine as-is. It’s already better tested than most of our Views integration, I think.

Hi Thomas,

The changes you made do look good to me, thanks!
Regarding the functional test, I can't promise but I'll try to add one when I have some time.

Great, thanks for your feedback!
I now just merged the MR, but if you find the time to create a functional test, feel free to create a new ticket and MR for that and ping me (for instance, via Slack) so we can get it merged quickly.
In any case, thanks a lot again, everyone!