Collapse the params text area field in the action selector as it is an optional field.

[vinay-appsmith]

No description provided.

[vinay-appsmith]

The params section has been a source of confusion as seen in user tests, repeatedly. For an optional field and one that is not at all used -- it occupies prominent space in the action selector. We could address this by hiding this section by default when there are no params configured. (This should be in-line with the behaviour of a JS function which does not have any params configured)

https://pasteboard.co/SzHNaENv54iU.png

[rishabhrathod01]

@vinay-appsmith

• we will need more information in regards to data that helps us understand this property is not at all used.

it occupies prominent space in the action selector.

It does and we have similar params input field for navigateTo. There is also a point where this helps user understand that Api.run(params) is supported in appsmith. If we remove it, docs will be the only way user could know appsmith supports params.

We could address this by hiding this section by default when there are no params configured. (This should be in-line with the behaviour of a JS function which does not have any params configured)

Could you please elaborate what do you mean by params configured for API or query?

• Only show params option when this.params is used in API or query?
  • if yes then it looks like a chicken and an egg problem to me where to explore this.params syntax action selector params field will be helpful.

[vinay-appsmith]

@rishabhrathod01

TL;DR: Parameters that are optional should not show upfront when calling a function, in the action selector. Docs is probably a better way to discover them.

Let me illustrate the point by using navigateTo scenario as an example:

• The params here are labeled as 'query params' while they are not. They are params related to the page? So, perhaps 'Page params' is a better word.
• This is optional. We don't communicate that this is optional.
• For an optional field, showing it upfront using text-area field takes up extra space and creates clutter.
• This needs to be collapsed by default and the user needs to toggle it to add params.
  https://pasteboard.co/S1Tr30yW5QLC.png

APIs have a params section in their config. page. And, these are optional too. https://pasteboard.co/avjKN7BObHJO.png
Why do we have to show the text-area field in the action selector if no params have been configured by the user in the first place? If people define params, then it then makes sense to show the field in the action selector so that they could pass values.

In my understanding -- the params section in the action selector, technically, is the place to pass arguments and not to define params. Coming to action selector to define params and then going back to the query to refer these as this.params is a disjointed and a convoluted experience.

I see that there is a problem with SQL queries because there is no way for a person to define the params while writing their query. And, action selector seems to the only way for a person to deduce that params could be passed. Still, this is a convoluted way. We can solve this by introducing a means for one to define params while writing the query itself (similar to defining inputs in query modules), but that is a different task.

[rishabhrathod01]

APIs have a params section in their config. page. And, these are optional too. pasteboard.co/avjKN7BObHJO.png
Why do we have to show the text-area field in the action selector if no params have been configured by the user in the first place? If people define params, then it then makes sense to show the field in the action selector so that they could pass values.

I believe there is a misunderstanding here due to use of params as a section name in API editor instead of query params. The params section in the API editor helps in configuring query params for the API and hence the value entered gets appended to the API url.

I see that there is a problem with SQL queries because there is no way for a person to define the params while writing their query. And, action selector seems to the only way for a person to deduce that params could be passed. Still, this is a convoluted way. We can solve this by introducing a means for one to define params while writing the query itself (similar to defining inputs in query modules), but that is a different task.

According to point mentioned above, the problem is for all queries and APIs.

In my understanding -- the params section in the action selector, technically, is the place to pass arguments and not to define params. Coming to action selector to define params and then going back to the query to refer these as this.params is a disjointed and a convoluted experience.

Yes, correct. We only pass params using action selector. I agree that we can hide or collapse the section and let it be optional. I was not in favour of removing the params input.
@vinay-appsmith

[rishabhrathod01]

Had a discussion with @vinay-appsmith, and we came to a conclusion about the need for an arguments section and the confusion about the params section in the API editor with this.params.

Vinay will add more details about future planning for this task for now we can move this back to product backlog.

[vinay-appsmith]

More details:
Systemic solve: Introduce a means for us to define params when writing the query and only show the corresponding arguments in the action selector. When there are no params defined, there will not be any corresponding section shown in the action selector. This will be done as a separate task, preferably as part of query pane redesign in the IDE 2.0 project. cc @momcilo-appsmith @pedro-santos-rodrigues

Interim solve: Make the optional params field collapsed by default in the action selector (will solve for taking up additional space in the action selector window). https://pasteboard.co/S1Tr30yW5QLC.png

If the usage of the current params, for queries, in the action selector, is very low (< 5% of users who call queries), remove this functionality altogether and solve this via the systemic route. Else, do an interim fix of collapsing the field. cc @Nikhil-Nandagopal

Irrespective of the solution route, the optional params section needs to be collapsed in actions like NavigateTo.