If your Search API server defaults limit (the number of results to get when a view does not define a limit) are very high and because our Search API (solr) driven Entity Reference Display Plugin does show previews (which the DB based does not) we can get time outs.
Also, on other modules we use these type of views as sources for dynamic data (e.g Open API in Format Strawberry field) and for Manifest renderings (list of children) too, so having at least an option to A) respect that choice correctly via a Code set Limit (e.g $this->view->setItemsPerPage($options['limit'])). Entity Reference Displays DO not allow pagers, but at least on the Open API implementations we do allow it to be set. We might want to document that?
I don't want to "set" limit on the preview to a Pager (which can be set, but won't be used by default without our own code) bc it Might give users the impression that it is being enforced by Drupal. Which as you know might not be the case.
What?
If your Search API server defaults limit (the number of results to get when a view does not define a limit) are very high and because our Search API (solr) driven Entity Reference Display Plugin does show previews (which the DB based does not) we can get time outs. Also, on other modules we use these type of views as sources for dynamic data (e.g Open API in Format Strawberry field) and for Manifest renderings (list of children) too, so having at least an option to A) respect that choice correctly via a Code set Limit (e.g $this->view->setItemsPerPage($options['limit'])). Entity Reference Displays DO not allow pagers, but at least on the Open API implementations we do allow it to be set. We might want to document that?
I don't want to "set" limit on the preview to a Pager (which can be set, but won't be used by default without our own code) bc it Might give users the impression that it is being enforced by Drupal. Which as you know might not be the case.