Show me the Guest List

Last week, we allowed players to have their own game, but we couldn’t see who joined and how many players were playing.

This week, we’ll improve that by allowing the user to have a name, and see the list of players.

Server side (commit)

On the server side, we need to handle two new “actions”:

• When a user changes her name
• And when we broadcast that new name to everyone else

We add these actions to the server’s actions.js file, here.

Then, we need to add the list of players to the room object (line 44). It’s initially empty of course, but as soon as a player joins, her name is added to the list, along with her socket ID.

The Socket ID will be the unique identifier that will be used to identify a single user, even if the user changes her name. We do that on line 69.

Once that’s done, you just need to handle the RENAME_USER action on line 101, and write the handler on line 86 so that when a user changes her name, the user object is found in the room (via the unique socket ID), the name is changed, and then the new list of players is broadcast to all the other players. Easy peasy!

Client side (commit)

On the client, we need to store that list of players and update it when it changes, while also allowing the user to update her own name.

First of all, we add a new array on the state, to hold the list of players (line 43).

Then, on line 66, we listen to the RECEIVE_PLAYER_LIST action, to update the list of players when we receive it.

If you look on line 109 and 110, you can see that we added two components: one Input to allow the user to change her name, and a UserList that takes a list of players and display their names.

When the user enters something on the Input, the onChange prop is called, which will both set the new name in the state (line 95), and emit a RENAME_USER action on line 98.

What could we improve?

Our app is now taking shape, we can now make a list of what we should improve going forward.

The App.js file is doing too much

The App.js file, in the client, is doing way too much and getting too complex. It does handle:

• The Socket IO connection and disconnection
• The Socket IO listening of actions
• The UI workflow of selecting cards
• The display of current players
• The layout of the app

We need to break that up into smaller components, and have a state management strategy in place. We could either use Redux, MobX or the new React context.

The application doesn’t have a router

At the moment, we have one “page”, and the room/game ID is derived from the URL in a very crude way.

To make things better, we will need to use react-router to manage the routing in a better way.

The application doesn’t remember the user

Ideally, the user shouldn’t have to type their name every time they launch a game session.

What we are going to do to is store the username in local storage so it can be re-loaded in the future.

The Server doesn’t persist

Right now, the server stores the game information in memory, so they are lost every time the server restarts. Not ideal of course, so we will add some server side persistence (using a database).

All of these problems will be tackled in the coming weeks, before our first release to production!

Stay tuned.