Re: [w3c/manifest] Add installation prompt control flow (#417)

So, playing around with the updated implementation... I'm now wondering if we need to error on when `promp()`ting more than once at all? 

Consider, a custom BIP that has the `userChoice` provided. This means that the UA can just resolve like this:

```JS
// This sets the internal [[promptOutcome]] immediately: 
const bip = new BeforeInstallPromptEvent("beforeinstallprompt", {"userChoice": "accepted"});
bip.prompt().then(({userChoice}) => userChoice === "accepted");
bip.prompt().then(({userChoice}) => userChoice === "accepted");
// And so on... 
```

So you can call `.prompt()` as many times as you like. You always get the same outcome.  

Now consider a real/trusted `BeforeInstallPromptEvent`:

```JS
event.defaultPrevented();
// Some time later
const p = event.prompt();   // 1. IPC request, internally waiting.
const p2 = event.prompt(); // 2. We are waiting, so just return a new promise and wait.  
// Wait, these just resolve to the same thing... (e.g., "accepted")
Promise.all([p1, p2]).then(results => results.every("accepted") === true);
setTimeout(()=>{
   // We can even check later what it resolved to...
   ev.prompt().then({userChoice} => console.log(userChoice))
}, 10000);
```

The drawback of the above is that we need to keep a queue of promises that are waiting an outcome. 

I don't have a strong opinion - we can keep "[[didPrompt]]" as a guard to throw InvalidStateError if already prompting. 

However, I do want to allow resolving `.prompt()`'s promise if the promptOutcome is already known (either ahead of time, as in the case with the user-constructed event, or after the prompt has resulted in a value).
 
Thoughts? 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/417#issuecomment-257785053