Fix waitUntilExit() not resolved with sync errors

[fantua]

Fixes #542

[fantua]

fix for Unhandled rejection in test/errors.tsx

[vadimdemedes]

Unhandled rejection is getting thrown because exitPromise is being rejected when waitUntilExit hasn't been called, so no one is handling failure of exitPromise.

I like the solution of initializing exitPromise in the Ink constructor, but with the unhandled rejection it's a breaking change now.

To avoid it, we should add something like a isWaitingForExit boolean property to Ink and set it to true in waitUntilExit method. Then check that property in unmount and if no one is waiting for that promise to resolve or reject, don't call rejectExitPromise or resolveExitPromise.

That way we can catch synchronous errors without introducing breaking changes.

How does that sound?

[fantua]

To avoid it, we should add something like a isWaitingForExit boolean property to Ink and set it to true in waitUntilExit method.

With synchronous errors waitUntilExit is never called. I can add some prop to render method maybe. Wdyt?

[vadimdemedes]

Hm, wasn't that the purpose of this PR? To resolve/reject the promise returned by waitUntilExit for synchronous errors?

[fantua]

I'm saying that the proposed solution won't work. Let’s go over this pseudo-code and try to execute it:

const App = () => {
  throw new Error('');
  return null;
}

const { waitUntilExit } = render(<App />);
	
await waitUntilExit();

1. Execute render()
   1. Set isWaitingForExit to false
   2. Throw error
   3. Call unmout with error
   4. Don't call rejectExitPromise becuase isWaitingForExit == false
2. Execute waitUntilExit
   1. Set isWaitingForExit to true
3. We are stuck 🤷‍♂️

[vadimdemedes]

Hm, that's not good. Whatever solution we decide to go with, it needs to work with this use case, but without unhandled rejection promises.

[fantua]

Hey @vadimdemedes. I've pushed new implementation, please have a look 🙂

[vadimdemedes]

I'm not a fan of an option that makes waitUntilExit work. As a user of Ink, I'd expect it to just work when I call it.

It looks like this problem isn't solvable without breaking changes. Perhaps we can think what the better API would look like if we weren't constrained by the presence of waitUntilExit and ship this in a major release.