List options dynamically

[rasouza]

What would you like to be added:

• I'd like to be able to render a list of options for the user to choose in a dynamic way

Why is this needed:

• Example: List all github repos from a given user, marked as Template repository, for the user to choose which repo to clone.

Explanation

There are cases that I don't know all the options before hand so I can't just type them in config.json, so I'd like to render these options in runtime, by calling an external service or something alike.

In my example, this external service would be GitHub API, and then ritchie-cli would render according to the JSON response.

Another example would be: I want to perform an operation in a pod in my k8s cluster, this operation is so verbose that I decided to keep it in a ritchie formula. As you know, pods are all ephemeral and have a unique name during their lifetime, so I wouldn't be able create a formula for that since I don't know my pods' names before hand to put in config.json's list. The external service in this case would be the Kubernetes API

Solution suggestion

I understand that the way you guys designed ritchie, it would require to change a little bit of its architecture in order for dynamic lists to work. So I was thinking about a sort of workaround for that, which could serves well. Feel free to adapt it whenever you believe you should

We could make a new type in config.json (let's say dynamic) together with a file path in the current formula's language (e.g. src/inputs/my_dynamic_call.js). This file, with its proper shebang (this is the workaround), gets executed by Golang's ritchie and it would be responsible for making the request to the external service and returning a JSON response to Golang in a defined structure (let's say 2 fields: name and value). Then the CLI would just render all name fields to the list (by unmarshalling the JSON) and when you select an option, the value field gets passed to the formula ENV variables as it normally would in a static way.

This way we can offer the feature without restricting the Formula's language through the shebang interpreter

So to illustrate:
config.json

"inputs": [
    {
      "label": "My Standard option",
      "name": "standard_option",
      "type": "text"
    },
    {
      "label": "My Dynamic option",
      "name": "dynamic_option",
      "type": "dynamic",
      "path": "src/inputs/my_dynamic_call.js"
    }
]

my_dynamic_call.js

#!/usr/local/bin/node
...
const data = await fetch('https://myapi.com/')
return data.map(item => {
    {
        "name": item.name,
        "value": item.value,
    }
});

ritchie-cli: Executes my_dynamic_call in SO level and receives a previously-agreed structure:

  [
    {
      "name": "option1",
      "value": "value_from_option1"
    },
    ...
  ]

It then unmarshalls this JSON response, renders in terminal and, once an option is selected, pass the value field to the environment so I can continue my business rule with the selected option.

Comment

It would be complementary to #390

However, it's still possible to deliver one value without accomplishing the other: if I create a static step-by-step in config.json, it would be possible to switch between options, without making it dynamic, by creating a new term in your config.json DSL. E.g.:

"inputs": [
    {
      "label": "My Standard option",
      "name": "standard_option",
      "type": "text"
    },
    {
      "label": "My Conditional option",
      "name": "conditional_option",
      "type": "text",
      // New term bellow...
      "if": "standard_option > 10"
    }
]

The #390 only suggests that I can hide some options from the formula execution. This #389 serves a bigger purpose indeed and may solve both issues depending on how you implement it.

[victor-schumacher]

Hi @rasouza!
An idea for this implementation is to add a field on config.json called list, and use the survey.List on cli.

Changes goes on this file:

ritchie-cli/pkg/formula/runner/inputs.go

Line 99 in c4017a5

case "text", "bool":

[rasouza]

I'm not sure if I understood correctly, is it implemented already? I can't find the survey package the survey package, can you explain a little bit more? I'd be very glad to implement it :)

Thanks!

[victor-schumacher]

@rasouza sorry for the delay, I think I misunderstood on the first moment. The feature is a dynamic list in which command or situation?

[rasouza]

There are cases that I don't know all the options before hand so I can't just type them in config.json, so I'd like to render these options in runtime, by calling an external service or something alike.

In my example, this external service would be GitHub API, and then ritchie-cli would render according to the JSON response.

Another example would be: I want to perform an operation in a pod in my k8s cluster, this operation is so verbose that I decided to keep it in a ritchie formula. As you know, pods are all ephemeral and have a unique name during their lifetime, so I wouldn't be able create a formula for that since I don't know my pods' names before hand to put in config.json's list. The external service in this case would be the Kubernetes API

Solution suggestion

I understand that the way you guys designed ritchie, it would require to change a little bit of its architecture in order for dynamic lists to work. So I was thinking about a sort of workaround for that, which could serves well. Feel free to adapt it whenever you believe you should

We could make a new type in config.json (let's say dynamic) together with a file path in the current formula's language (e.g. src/inputs/my_dynamic_call.js). This file, with its proper shebang (this is the workaround), gets executed by Golang's ritchie and it would be responsible for making the request to the external service and returning a JSON response to Golang in a defined structure (let's say 2 fields: name and value). Then the CLI would just render all name fields to the list (by unmarshalling the JSON) and when you select an option, the value field gets passed to the formula ENV variables as it normally would in a static way.

This way we can offer the feature without restricting the Formula's language through the shebang interpreter

So to illustrate:
config.json

"inputs": [
    {
      "label": "My Standard option",
      "name": "standard_option",
      "type": "text"
    },
    {
      "label": "My Dynamic option",
      "name": "dynamic_option",
      "type": "dynamic",
      "path": "src/inputs/my_dynamic_call.js"
    }
]

my_dynamic_call.js

#!/usr/local/bin/node
...
const data = await fetch('https://myapi.com/')
return data.map(item => {
    {
        "name": item.name,
        "value": item.value,
    }
});

ritchie-cli: Executes my_dynamic_call in SO level and receives a previously-agreed structure:

  [
    {
      "name": "option1",
      "value": "value_from_option1"
    },
    ...
  ]

It then unmarshalls this JSON response, renders in terminal and, once an option is selected, pass the value field to the environment so I can continue my business rule with the selected option

[brunasilvazup]

Hi @rasouza,
Thanks for the more detailed explanation, we are now able to fully understand your suggestion.

Another question I was left with:
Was this PR suggestion not enough to resolve this second issue of yours #390, what do you think?

[rasouza]

Hello o/ sorry the late reply

They are complementary to each other in a way, yes. Probably the solution you're envisioning solves both issues, so we're good here.

However, it's still possible to deliver one value without accomplishing the other: if I create a static step-by-step in config.json, it would be possible to switch between options, without making it dynamic, by creating a new term in your config.json DSL. E.g.:

"inputs": [
    {
      "label": "My Standard option",
      "name": "standard_option",
      "type": "text"
    },
    {
      "label": "My Conditional option",
      "name": "conditional_option",
      "type": "text",
      // New term bellow...
      "if": "standard_option > 10"
    }
]

The #390 only suggests that I can hide some options from the formula execution. This #389 serves a bigger purpose indeed and may solve both issues depending on how you implement it.

Please let me know if I left anything unclear. I'm looking forward to discuss it through :)

[GuillaumeFalourd]

Hi @rasouza , Thank you again for your suggestion !

I'm currently reviewing all ISSUES and I think we could add the #HacktoberFest tag (https://hacktoberfest.digitalocean.com/) to the ISSUE your created.

However, I believe it would be interesting to update the first ISSUE comment with your detailed explanation of how you imagined it (with the dynamic type on the config.json file and so on) to make it easier for the community to understand before eventually contributing.

Do you want to it or would you prefer if I update it for you ?

[rasouza]

Hello! Sorry late reply again

Yeah, it's no problem at all. I think you know it better how this should be done, so do you mind updating it for me?

Thanks!

[GuillaumeFalourd]

No problem @rasouza , I updated the ISSUE and associated labels. Thank you again 👍

Note: The documentation (https://github.com/ZupIT/ritchie-gitbook) will need to be updated afterwards.

[henriquemoraeszup]

Pulling the issue to the cli team, the implementation will be a bit simplified for the sake of delivering value on the short time. Having a per-language request implementation might affect multiple points and become complex to implement, we might be implementing it inside Ritchie

[rasouza]

It makes sense, let me know if I can serve you anyhow

[henriquemoraeszup]

Implemented by #605
We will open a new issue to enhance the capabilities, such as other http verbs and authentication