showWhen clause does not support async function provider for operation like file lookup (skip prompter)
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.
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).
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()".
Problem
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:
Promise
. example:if (result instanceof Promise)
(example) to decide how to handle the async variants:init()
is used to construct the Wizard. It is an error to define async ContextOptions on a wizard that callsbindPrompter
in its constructor (where async functions cannot be awaited).await
the functions infbindPrompter
Note
This is just a proposal. If it turns out that
bindPrompter
can safely acceptasync
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 vsinit()
".