Alternative cancellation handling with callbacks

[aqeelat]

Context

This came up while evaluating @clack/prompts as a potential replacement for enquirer.js, comparing it with enquirer.js and @inquirer/prompts.

Related: #83
Related PR: #544
Split out from: #550

Problem

Every prompt call site that handles Ctrl+C currently needs the same boilerplate:

const result = await confirm({ message: 'Continue?' })

if (isCancel(result)) {
 cancel('Operation cancelled.')
 process.exit(0)
}

This works, but applications with many prompts often centralize cancellation handling. Today, that has to happen after each prompt resolves.

Proposal

Consider supporting an optional cancellation callback on prompts:

const result = await confirm({
 message: 'Continue?',
 onCancel: () => {
 cancel('Operation cancelled.')
 process.exit(0)
 },
})

If the callback returns never, the prompt result type could narrow to exclude the cancel symbol:

// result: boolean

If the callback returns normally, the return type should remain unchanged:

// result: boolean | symbol

Notes

This is mainly about discussing whether callback-based cancellation belongs in clack at all. If the preferred approach is to keep cancellation exclusively result-based through isCancel, this can be closed.

[43081j]

Can you explain where you think having a callback would help?

I'd like to hear from you rather than your agent on this. You personally think it'd be better to have an onCancel handler? Can you explain why?

keep in mind you can do this today:

const exitIfCancelled = (obj: unknown) => {
 if (isCancel(obj)) {
 process.exit(0);
 }
};

// elsewhere...

const value = await prompts.text(options);
exitIfCancelled(value);

// do other stuff with value

[arsnl]

I find myself in the same situation. I agree with @aqeelat (or his AI agent… 😅) about the lack of a centralized way to handle cancellation in Clack right now. However, this proposal still puts onCancel on every individual prompt rather than solving that centrally, so I'm not so sure about what this proposal is about.

@43081j do you think adding an onCancel field to ClackSettings and updateSettings could be an option? It wouldn’t be perfect however. Spinner has its own cancel machinery, and group already exposes onCancel at the batch level, so there’d be some overlap to sort out. But it might still be a useful global default for the common interactive-prompt case.

[43081j]

the risk is that we're then maintaining two different approaches for achieving the same thing. given we haven't seen much demand for it, that'd mean introducing more complexity for no real gain.

my thoughts:

• an onCancel for every prompt doesn't make sense. use isCancel - it'll be the same amount of code
• a global onCancel may have some use but wouldn't work very well with types and wouldn't be as clear IMO (compared to seeing at the call site how a cancellation is handled)

i think this should be handled either by the CLI builder (clink in future, the new bombshell project) or by a wrapper so the exit handling still happens at the call site (await exitIfCancelled(prompts.text(opts)))

[43081j]

we're going to close this for the time being.

in future, if there's demand, we may look into exposing some kind of exitIfCancelled helper. This particular change (having onCancel callbacks) is unlikely to ever happen since it would just duplicate the existing cancellation pattern in a different place.