Allow pagination in slot resolvers

Hey ​@andrewwhitley - the problem here is that you have too many results and we don’t present them all to the user?

More or less. If I need to have a slot be one of the options in a particular list of options in a external application, due to this restriction, the number of possible options is determined based on how the application handles pagination. One app may only return 50 results per call while another may be more or less. I have a mixture between 10, 50, 100, and 500 currently based upon the app and api call. Therefore I cannot use dynamic resolver strategies for multiple slots and instead have to either leverage it as a string with a strict validator, or a static resolver strategy.

Got it ​@andrewwhitley - how would you envision the UX presented to the user? Today we can’t do pagination but if the list of options is large, let’s say 100+, then we don’t present it all and the user can either ask for more or if they know the option they want the can type it out and the assistant will find it.

Usually, we’d want to do search before pagination because conversationally paginating isn’t very intuitive and it can be slow as well

We are never shown more than 20 options anyways. However if it was aware of all 100+ items and the person says I want a abc option, the user can be presented with the various options that are similar to abc to choose from.

I have another plugin where it relies on search beforehand and it always has issues as the search is static and doesn’t account for minor changes like special characters, spaces, etc. I helped it by having the search slot only contain a keyword, but that can result in many options to return. Therefore search before pagination doesn’t 100% solve the problem either, as the search can still return with paginated data and we are now restricting the options the user has available.

Hey ​@andrewwhitley - we talked internally and we will revisit the idea in a future date to see if it fits our roadmap.

Thanks!