Add an option to limit the number of max results

[klassm]

The idea is to provide an option to limit the number of results that can come back. The project where I use this library in partially renders 15000 rows. When > 150 rows come back from the search, it starts to stutter. Nobody has to use it, but it is kind of convenient to stop when a threshold has been reached and then report back to the user.

[klassm]

This PR should become green as soon as #783 has been merged.

[Domino987]

Hi ,interesting. Would you mind creating a sandbox for the usecase? There would also need to be a indicator that the currently shown items are not all the items

[klassm]

Demo is added :-)

[klassm]

For the indicator - I would actually leave that to the calling application. This is very much individual on how to show it. Or what do you think? The demo also includes an example for it.

[Domino987]

Yes I saw that you added a demo but can you create a demo where the problem that you mentioned problem is present?

[klassm]

Well this will be difficult. This is a nested tree structure with > 10000 items. When analyzing why it feels sluggish then, it boils down to opening the tree and rendering those items - it is just too much.

[Domino987]

Well this will be difficult. This is a nested tree structure with > 10000 items. When analyzing why it feels sluggish then, it boils down to opening the tree and rendering those items - it is just too much.

So its not necessary the search count but the amount of stuff rendered aka the nested tree views? and with the reduced numbers you just reduce the items within the tree?

it feels like this it is just a hotfix for an underlying problem honestly.
And I think there should be a at least overridable way but always present display that some things are missing.
Is there a way for the end user to show all the items anyway? This feels restrictive for the dev to just block the results with a hard forced cap. Depends on the system etc wheter or not the amount is sensible anyway.

[klassm]

Yes exactly. On my instance I set it to 150, telling the user to refine it. Otherwise the browser will render > 5-10 seconds, turning the whole page unresponsive.
And yes, this is restrictive. But the library should at least give the option to restrict it. Currently I have a pretty hacky workaround to still make this work - everything is better than having a browser render 5-10 seconds.

[Domino987]

@klassm I am not sure if restricting the search results is the correct way of handling this particular case. This seems more like a hotfix for your specific deeply nested tree view.

And the way you proposed to change the filter does not seem intuitive, since the filtering itself is not the problem.
So we could just do something like this:

if (this.searchedData.length > maxResults) {
   this.searchedData = this.searchedData.slice(0,maxResults);
   setExceded = true
}

But again, maybe we should look at the actual problem: the tree depth, which is the primary problem.
Here a sandbox would be helpful to see where the main problem is.

What is your current hacky workaround?
What do you think?

[klassm]

Well I guess the tree data is the one thing I cannot provide - and actually it is probably also not helpful. It is just a huge clunky amount of nested data.
The current workaround is rather a hackaround - there is a custom filter function, that keeps the found results in a ref (!), as there is no way to do anything in the library. So I would really appreciate having a way to limit the number of search results in the library itself.

[klassm]

I've also changed the implementation as you proposed, directly with a slice and the check in the data-manager.js. There is one red test though: Detailpanel render › It displays the detail as is array (Edit: now it is locally green again, maybe a blinker?)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You can reopen it if it required.

[klassm]

Not sure how to go forward with this, not it is becoming stale :-)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You can reopen it if it required.