Here are some screenshots of a request I made with the query “zzzzz”. All options are returned, despite the fact that none of them match the filter. Without this working, the endpoint is kind of useless, as some configurable props can return thousands of options, and it can take minutes to load them all.
query might only work if the prop has useQuery=true set on it, but let me double check. If so, that’s definitely missing from the docs :face_palm::skin-tone-2:
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.
Yea the complexity comes from not all APIs supporting a search argument, so we have no choice but to paginate through all the options then do the filtering on the client side. cc do you know if that’s the case for HubSpot? Can we use useQuery for any of the configurable props there?
Thanks very much for looking into this so quickly.
In general, what kind of priority would be given to requests to add support for the query parameter to other apps in future? I’m asking because Hubspot just happened to be the first app I tested for this. We’re running a pilot internally with ~15 different apps, but I know we hope to have hundreds of apps in the near future. Client-side filtering should be fine for any props where we can load all the options in a few seconds, but if it takes more than a few seconds we’re likely to have our users complain and that would flow through as requests to you guys!
As Danny said that depends more on the endpoint itself supporting a search/query parameter to return server-side filtered results, so this has to be done on an individual basis
For HubSpot I think we could call the “search objects” endpoint instead of the “list objects” one, when a query is passed to the options method.
The objectType prop has reloadProps: true, meaning you have to obtain the dynamic props which includes the actual searchValue prop you’re looking for, among others