async submission scenario

[PavelZhuravlev]

Hey, thank you for developing this interesting library! The idea behind it is excellent, and the library's compact size is impressive.

I’m currently exploring the possibility of integrating it but have encountered a challenge with one particular scenario: displaying a modal in a loading state while processing an async operation upon confirmation. Perhaps I’m missing something, but based on what I see in the source code, the library seems to immediately resolve the provided promise and unmount the modal when call.end() is executed. The unmount is a result of the internal stack update (which is iterated to render instances).

While the current call.end() approach works perfectly for common scenarios, introducing additional API options to allow more granular control could expand the library’s range of use cases. Specifically, decoupling the instance's removal from the stack from promise resolution could help address this scenario.

For example, here’s a potential API that could provide more control:

type Props = {
  message: string;
  loading: boolean;
};

export const Confirm = createCallable<Props, Response>(({ call, message, loading }) => (
  <div role="dialog">
    <p>{message}</p>
    <button onClick={() => call.resolve(true)}>Yes</button> //resolve without unmount (detaching from the stack)
    <button onClick={() => call.end(false)}>No</button>
  </div>
));

Usage:

const accepted = await Confirm.call({ message: 'Continue?' });

if (!accepted) {
  return;
}

// Possibly could be achieved without .update() in favor of passing prop through Confirm.Root
Confirm.update({ loading: true }); 
await someAsyncOperation();
Confirm.dismiss(); // unmount (by detaching from the stack)

This is just an illustrative proposal, and I’m sure there are better ways to implement such functionality. A more granular API, layered on top of the current one, could also cater to feature requests for animation support (as an alternative to using timeouts).

Please let me know if I’ve overlooked anything and if the mentioned use case is achievable with the current API.

Thank you!

[desko27]

Hi @PavelZhuravlev, thanks a lot for your ideas and examples! As I understand the requested features working together are:

1. Resolve from the component without unmounting/detaching from stack.
2. Delegate some control to the caller scope, so the call can be controlled from outside (update props, close, etc).

These features will cover new interesting use cases, I agree. They come at the cost of some bundle size increase though, but looks worth it to me!

EDIT: (2) will be handled in #26 since there's a proposal and could work separately, so we can focus on (1) here!

[desko27]

Hi @PavelZhuravlev, after considering some options I'm coming up with this:

const promise = Confirm.call({ message: 'Continue?' }, { unmountOnEnd: false })
const accepted = await promise

if (accepted) {
  Confirm.update(promise, { loading: true });
  await someAsyncOperation()
}

Confirm.unmountResolved(promise)

I think this way the implementation of the user component remains untouched (same end method inside), but it can be used differently depending on the desired flow for a given call.

[desko27]

I'm also considering to provide overloads to update and such methods for a closer version to your original example, so they don't require the associated promise to identify the active call, because I understand some of you may be dealing with a singleton as requested in #21 and don't need the kind of features meant to manage multiple active calls (as in toasts and such).

That way, the whole thing could also be used like this:

const accepted = await Confirm.call({ message: 'Continue?' }, { unmountOnEnd: false })

if (accepted) {
  Confirm.update({ loading: true });
  await someAsyncOperation()
}

Confirm.unmountResolved()

EDIT: Method overloads coming in #36