feature_request(output): show all results

[Kristinita]

1. Summary

It would be nice, if would be possible to display all search results by click/tap.

2. Example of expected behavior

The user types text in input field of Stork → gets more results than in setting displayed_results_count → now if he clicks to Show all results, all found results will be shown (20 in the example below).

3. Argumentation

As a search user, I often want to see all the results found. Unfortunately, for now, perhaps the most important result or the one user need may be hidden because of the limit on the displayed results. It would be nice to see all results without limit.

3.1. “displayed_results_count” setting performance limitations

Yes, we have displayed_results_count setting. But it seems that the big value of this setting — as displayed_results_count: 1000 — isn’t a best practice. As written in the documentation, “pushing this too high will result in performance issues”.

Showing all results for a click/tap is probably the better solution, as it won’t create unnecessary performance issues.

4. Search for duplicate requests

1. Look at the required setting in Stork Configuration File Reference
2. Look at the project roadmap to see where Stork is going, what features are coming down the pipeline, and what Stork author hopes to accomplish
3. Look at the existing feature issues to make sure the feature you’re requesting hasn't already been requested.

Thanks.

[jameslittle230]

Hi @Kristinita - thanks for writing, sorry it took so long to reply.

This isn't something I'm willing to support, because of the potential for a poor user experience. The performance issues would exist even if all results are shown on tap, and could result in the webpage freezing while Stork collects and displays all the results. If there are too many matches, it might freeze or crash the webpage.

These are the same performance issues that your users might encounter if you push displayed_results_count too high, and this is why pushing that value too high is not recommended.

[jameslittle230]

I'm happy to keep chatting about this, but would prefer to do this in Github Discussions if so.