This topic was automatically generated from Slack. You can find the original thread here.
The clickup-get-task-comments component does not have a reloadProps flag for the prop workspaceId. I think that is a mistake?
Does the `clickup-get-task-comments` Component Lack a `reloadProps` Flag for the Prop `workspaceId`?
I don’t see any reloadProps flag nor additionalProps definition in any of the clickup components. What makes you say that?
Because as far as I can tell, several other properties cannot be revealed until workspaceId is defined?
Props that have async options (aka remote options) often depend on previous ones. They should usually be called in sequential order. This is a common example - selecting the workspace first, then you get available boards for the selected workspace. But the “board” prop is defined the same way, it just receives the workspaceId as an argument.
reloadProps is usually for cases where the entire prop definition depends on previous configuration, such as selecting an object type, then getting multiple different fields depending on which object type you provided.
I see. I guess what I am looking for is a way to infer from the component schema whether I can expect a remote option to be available instantly or if not which other prop it depends on. What’s the best approach to that?
There’s no way to define which specific prop(s) they depend on. So I believe the best approach is what our UI does: to only allow retrieving remote options for a prop when all the previous (required) props, in the order they were defined, have a value set
So can I always assume that props should be configured in the same order they appear in the schema?
The ones with remoteOptions at least, yes.
Ok, that is helpful, thanks!
Defining which specific props a given prop depends on is a helpful suggestion too, and something I’ve run into before - hopefully we can implement this at some point 
I guess I can assume that if prop 1 has been configured and prop 3’s remoteOptions is empty, then it’s because prop 3 depends on prop 2?
Likely. Most get an error (since these parameters are usually resource ids), though it could still be empty just because there’s no resources to load in that scenario (e.g. no boards in the selected workspace)
Ideally, if prop 2 also has remoteOptions, then you shouldn’t call (or allow your user to call) remoteOptions for prop 3 until prop 2 is configured
That dependency does not always exist, but it usually does - I’d say in 90% of cases or so
And unfortunately we don’t have a way of flagging when it does
Ok. My challenge is all this back and forth really slows down my my LLM interactions. So up until now I’ve been attempting to configure as many props as possible in first go, but it sounds like that is not a sustainable approach.