Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: a function property for confirm type #1080

Open
GHNewbiee opened this issue Jan 21, 2022 · 1 comment
Open

Feature request: a function property for confirm type #1080

GHNewbiee opened this issue Jan 21, 2022 · 1 comment

Comments

@GHNewbiee
Copy link

The case
After answering a confirm type question, third values have to be conditionally calculated and get saved to a (generator's config) file. Some of these values, later on, will also be used as defaults to some other questions.

The problem

  • Third value calculations and their storage cannot be done right after the answer of the questions but later on.
  • Some third value calculations have to be done in the next questions in 'default' property which is not the ideal place and at the same time to get stored in the config file since they are ready.
  • The remaining values have to be calculated and get stored in the promise part.
  • So, there are two different places from which calculations and storage take place.

Potential solution
A new function property (eg action) could be added as a degree of freedom. User would decide in which part - question object or promise (then()) - additional tasks will be written. For example, tasks that require different answers are written in the promise part but tasks based only on a question input could be written in the action property.

Note: In other types where filter is available, local tasks "smartly & abusively" take place through its function which finally just returns the input unchanged; a solution not so elegant. So, imho, a separate function property for individual tasks based on single input would be a nice feature which does not break backward compatibility, too.

Tia

@GHNewbiee
Copy link
Author

Consider also #1082.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant