Updating the Client: Functions

ClickStart

Of course, we’ll need to update the function passed to the component as clickStart to accept and handle these new arguments.

The clickStart function sent to the StartForm came from the SignInScreen, which got it from App, the top-level component. It’s useful to review where we left it:

startGame(nameValue, langValue) {
    axios.post(APIURL + 'api/games',
               { username: nameValue, language: langValue })
        .then( response => {
            console.log(response.data);
            if (response.data.message === 'success') {
                const gameId = response.data.game_id;
                this.setState({
                    username:nameValue,
                    language:langValue,
                    gameId:gameId,
                });
                axios.get(APIURL + `api/games/${gameId}`)
                    .then(response2 => {
                        this.setState({
                            badGuesses: response2.data.bad_guesses,
                            guessed: response2.data.guessed,
                            playerId: response2.data.player,
                            revealWord: response2.data.reveal_word,
                            usage: response2.data.usage,
                            gameStatus: 'active'
                        });
                    })
                    .catch( error => {
                        alert('Oops. Server is not cooperating.');
                    });
            };
        })
        .catch( error => {
            alert('Oops. Server is not cooperating.');
        });
}

We can summarize this as follows. First, it attempts to make a new game by passing in the username and language. If it’s successful, it updates the application state and then gets the rest of the game details using the games API’s GET method. It handles failures using the catch method and an alert, which creates a pop-up message in the browser.

New approach

Our new approach is more complex. There are many cases, but they should follow from common sense or from the type of experience we’ve come to expect from web pages. We’ve outlined it below:

1. Get logged in:
   1. If the new account checkbox is checked:
      • Register a new account with POST on the auth API and retain the login token.
        • If this fails, flash a message and leave the gameStatus as is.
   2. If the new account checkbox is not checked:
      • Log into the account with PUT on auth and retain the login token.
        • If this fails, flash a message and leave the gameStatus as is.
2. When logged in, create a new game with POST on games using the login token
   1. If successful:
      • Retain the game access token and the game ID.
      • Use the login token with GET on games to get game details.
        • If this fails, flash a message and leave the gameStatus as is.
      • Set gameStatus to active, which will update the screen.
   2. If game creation fails, flash a message and leave the gameStatus as is.

Use of flash message

This plan uses a flash message, which appears on the screen to notify the user. These messages can be used for various reasons, but they’re most often used to indicate issues that should be addressed. This will be done using a new component that shows the message when it’s non-empty. We’ll also need a way to clear the flash message. When should that happen? It should be cleared when the user interactions are proceeding normally. In particular, we’ll clear the message when the game status is changed or when a letter guess is successfully processed.

Implementation

Here’s one way to implement this logic. Note that it flashes a message by setting the flashMessage field within the application state. Also, the access tokens are provided by using the base axios constructor rather than the conventional methods, for example, the POST and GET methods.