Oh yeah, I can see in the JSDoc comments for the ConfigurableProp type
/**** If true, calls to `configureComponent` for this prop support receiving a `query` parameter to filter remote options */
useQuery?: boolean;
I feel like this presents a bit of a usability issue. The example trigger I’m using to test this internally is Hubspot > New Events. The objectIds configurable prop has >5,000 options, and it seems like I can’t control the page size - it defaults to a page size of 10 for this prop, and I need to wait for each request to complete before I know if there are more to load (cursor pagination). My browser took a few minutes to make the first 500 requests, and then I gave up because I didn’t know how many more pages there were to load.
From an end-user’s point of view (e.g. a user of the app I’m working on), they would need to be able to type in a deal name (e.g. "Acme Corp"), and see all deals that relate to their search within a few seconds. For this to work, I’d either need:
• To be able to load all of the options (>5000, I don’t know exactly how many) within a matter of seconds, so we can filter on the frontend
• To have the ability to filter this prop. Page size doesn’t matter so much now because they can simply narrow down their search term if it’s not in the first few pages.
Without either of these, I feel like it becomes impossible to configure props where there’s a combination of large # of options and small page size.