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

arch(wizards): support async bindPrompter functions (ContextOptions) #6094

Closed
justinmk3 opened this issue Nov 22, 2024 · 0 comments · Fixed by #6166
Closed

arch(wizards): support async bindPrompter functions (ContextOptions) #6094

justinmk3 opened this issue Nov 22, 2024 · 0 comments · Fixed by #6166
Labels
architecture feature-request New feature or enhancement. May require GitHub community feedback. refactor wizard

Comments

@justinmk3
Copy link
Contributor

Problem

  1. showWhen clause does not support async function provider for operation like file lookup (skip prompter)
  2. setDefault in both ContextOptions and FormElement support async function provider

Background: historically the ContextOptions functions were non-async because they are called in constructors. But now that we have async init() (example) as an "async" way to construct Wizards, the door is open to support async variants of these wizard ContextOptions.

Expected behavior

Support async variants of the ContextOptions functions:

  1. change their signatures to optionally return a Promise. example:
    showWhen?: (state: WizardState<TState>) => boolean | Promise<boolean>
    
  2. in the Wizard / prompter base class(es), check if (result instanceof Promise) (example) to decide how to handle the async variants:
    • if async, require that init() is used to construct the Wizard. It is an error to define async ContextOptions on a wizard that calls bindPrompter in its constructor (where async functions cannot be awaited).
  3. await the functions inf bindPrompter

Note

This is just a proposal. If it turns out that bindPrompter can safely accept async ContextOptions functions that can be await'd just-in-time when the Wizard is run, then we can more easily support this without needing to care about "regular constructor vs init()".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture feature-request New feature or enhancement. May require GitHub community feedback. refactor wizard
Projects
None yet
1 participant