Asynchronous
You seem to think in synchronous way, but that's not how you should think about this. You are issuing a command to the server, but you should not wait for the response, because:
- the command might never arrive, for ex. due to Internet connectivity issues
- the server might be down
- the server might error out your command and never respond
- the other player might never receive the message
- the other player might never answer the message
- the server might never receive the other player's command
- the server might error out the other player's command
- the server might never send you the notification
- you might never receive the notification
So many point of possible failure on the one hand. And... Javascript is single-threaded on the other hand. So, if you wait for the other player to respond, then your UI will froze in the meantime (with the exception of Web Workers, but that's a more advanced topic, for now, let's view Javascript as a single-threaded environment)
Instead you should think asynchronously. In fact, in the achronim of AJAX, the first "A" stands for "Asynchronous". This means that you issue a request and define what you will do when a response is received. This "what will you do" is called the callback. Your client-side will work and be responsive in the meantime and when a response arrives it will know what to do.
Not only your request, but the other's response
Okay, now that we think asynchronously, we need to consider our options to handle when the other player decides to join your game:
Polling
You may issue periodic requests to the server via setTimeout
and AJAX requests and once the response notifies you about the game being accepted, handle it accordingly. See: https://davidwalsh.name/javascript-polling
Push notifications
The server may send notifications to the users once an event occurs. See: https://onesignal.com/lp-web-push?utm_source=google&utm_medium=cpc&utm_campaign=general&gclid=CjwKCAjw4_H6BRALEiwAvgfzq9s03BR1OhlvxwN6SCn6Q_bIKODk3bQK05gwdaHTpwvzV2d7mXQU9hoCSl4QAvD_BwE
But you may want to use something that's compatible with what you are using at the server.
WebSockets
WebSockets are duplex channels, which are kept open. If the framework is implemented and supported, then client A and client B would both be connected, client A would send a command via WebSocket, the server would receive that and notify client B via WebSocket. When client B decides to accept the challenge, he would click on the button, which would issue a command of his own to the server via WebSocket and the server would notify client A via WebSocket. See: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
Summary
It's better to view this as a series of events and event handlers, rather than waiting for a response.