Can we update the 'Retrieve component' and 'Reload component props' endpoints to distinguish between 'options' and 'string_options' like 'Configure component prop' does to allow dynamic loading of all prop options?

Bugs
1

This topic was automatically generated from Slack. You can find the original thread here.

Hey team!

The Configure component prop endpoint distinguishes between options and string_options, but Retrieve component and Reload component props does not.

Can we update the latter two so they also make that distinction? The current inconsistency is preventing me from dynamically loading all options of a prop on-demand.

2

Not sure if it’s intended, will check with the team

3

But why is it preventing you, are you able to mark that field as nullable?

4

I think there might be some misunderstanding here.

A component definition (returned by the retrieve component endpoint) includes the props that can/must be configured in order for it to be used.

The reload component props is a special case of the retrieve component endpoint, as the props of some components have to be dynamically determined based on the configuration values of some previous props. The classic examples are Google Sheets components, where props such as “column name” depend on the worksheet previously selected. Think of this endpoint as re-defining a new component on demand. The new component would be the original one merged with whatever the reload component props returns. Think of this endpoint as redefine component props or something like that.

The configure component prop endpoint is the one that actually returns options. These options are the possible values that you can use for the prop being configured. Each prop can be configured with some set of values, also based on the values of previously configured props. Perhaps the correct name for this endpoint would be something like retrieve prop options.

The distinction between options and string_options is somewhat unfortunate, but the gist of it is that options is a list of objects, each containing a label and a value entry, ideal for the UI. string_options is a list of strings, as if label and value were equal. Depending on how the component is defined you’ll get one or the other (most of the time it’s options since the actual values are usually cryptic IDs used by the corresponding app).

Does that clarify things for you Mikael?