That will require caution regarding who can "reconnect" to a given user's session.
This might require authentication, or some means of identification (cookie?).

Navigating between routes is something that people naturally do.
We need to respect all possible states in all screens to accommodate for unexpected navigations, and also add better navigation within the application itself to get back to the "expected" route.

Example problems:

• pressing the "back" button from the game browser to go to the homepage: it doesn't properly trigger the home saga and doesn't listen to the change name event anymore (see #114 and #116)
• pressing the "back" button while in the lobby: ideally the game should handle this event as a "leave lobby" action, or at the very least the browser screen should respect this state and provide a button to get back to the lobby
• pressing back from the game browser after leaving a game from the score board button. It currently brings us back to the score board, but the game is supposed to be deleted at that moment.

Currently the scoreboard is modal and doesn't allow to check out the other boards for a "debriefing".
This is usually a nice moment at the end of the game, we want to allow this!

Deserialization of the score board fails, preventing the end of the game

We should find a way to generate a documentation of the websocket API to make it easier to maintain.

Swagger seemed to be an option, but is fundamentally tied to REST, and thus not adequate to use for websockets as-is:
swagger-api/swagger-socket#47
OAI/OpenAPI-Specification#55

JsonDoc looks like a viable option, but we should first have a closer look at how it works.

As a simple informative tool, we could add a button to check the rules of the game.
At least displaying the card-chaining tree could be useful.

It looks like we don't get the expected gold when playing "bazar" (we should get 2 coins per grey card of each direct neighbour and on our own board). My latest test seems to show that only the cards from the right neighbour are taken into account. To be confirmed.

The bug seems to also occur with the equivalent card yielding coins for brown cards of neighbours and self ("Vineyard").

The option to either play

1. Only A
2. Only B
3. Allow the player to choose which side to play
4. Random, as it is right now
   would be nice.
   The default random choice could potentially lead to unbalanced games.
   Thanks in advance

We can't see errors in the UI, in particular connection drops.
It would be nice to add toasts with errors for all server errors, and maybe reset the redux state for missing heart beats indicating a connection drop.

Right now, all files are separated by functionality (containers, components, redux, etc)

I suggest that we refactor to group files by functionality.
eg:

src/
  |-features/
    |-gameBrowser/
      |-GameBrowserContainer.js
      |-ducks.js
      |-sagas.js
      |-{specific components for game browser}.js
    |-...
  |-layout/
    |-LayoutComponent.js
  |-shared/
    |-...
  |-utils/

It is sometimes useful to look around and check other players' boards while waiting for other players to play.

It'd be nice to display the players in the lobby in a circle representing the table. The way I see it is:

• the current user is at the bottom in the center (each client sees from its point of view)
• the host of the game can reorder players (with a randomize button for now)
• each user receives reorder updates and the list animates accordingly

It is annoying if a player leaves or forgets to play for a while. We should add a time setting, and then start a timer when the hands are sent to the players.

If the limit is reached, we could, for instance, automatically discard the first card of each player that has not prepared his move yet.

When the card we just played happens to also be in our new hand, it is displayed as if we had prepared it immediately after clicking the "ready" button.

Pressing "ready" to receive the next hand doesn't serve any real purpose from the point of view of the user if the turns don't have a timer. There is no need for everyone to get his/her hand at the same time.

Using Immutable JS has proved to be a pain, especially because the cumbersome API is not contained in the reducers but leaks out in the React components. As far as accessing the data is concerned, I dislike not being able to do it the native way, well supported by IDEs. What's more, using strings in such accesses is not refactoring-friendly and it obscures the errors when we make typos.

Using .toJS() in each selector could seem to be a solution to avoid such accesses in React components, but given Alex Faunt's experience, it does not seem to be a good idea as it destroys performance.

Seamless Immutable seems to be our life savior, providing immutability with an equivalent mutation API, yet keeping native read accesses.
We should try to migrate, not forgetting to use redux-seamless-immutable for a compatible combineReducers() and routerReducer().

This would appear on the player's own board and other boards in the full previews.
This shouldn't be important enough to be displayed in the summary.

Following this stackoverflow thread, we should probably use one of redux-persist or redux-storage.

Some sagas being tied to routes is debatable. I reckon the only sagas we should keep bound to routes are the ones that listen to multi-clients web socket events.
For instance, the saga watching the list of games is coupled to the game browser route, which makes sense. If we were to keep this saga running all the time, we would be flooded with events even in times where we don't display the game list and don't care about it (like during a game or in the lobby), and we can't afford the extra processing (especially when the number of users grows).

On the other hand, sagas that listen to dispatched actions don't need to be coupled to routes.
For instance, the createGame saga sends messages on the socket when the REQUEST_CREATE_GAME action is dispatched. This saga does not need to be linked to the game browser route. If we're not on this route, then the REQUEST_CREATE_GAME action will never be dispatched and there will be no issue having the saga running (in a blocked state). If ever this action is dispatched outside of this route, then we'd better send that message to the server, because that would mean there is a new situation in which we want to send this action.

On hold because readiness status might not be relevant at the moment, see #3

From the lobby, other players may leave the game but the owner cannot.
The server doesn't prevent the owner from leaving, but it brings the owner's client to a weird state (it doesn't get the update about the left game).
Also, there is no UI currently to do this.

We would need 2 main actions:

1. owner leaves, making someone else the owner (and removing the game if the owner was alone)
2. owner disbands, kicking everyone out of the game and removing the game

The CSS is referenced from an HTTP url, which is blocked for security reasons.
This file should in fact be embedded in the app rather than fetched from the internet all the time. This would also ensure reliability.

The 'ready' button does not change colour/indicate you clicked it nor does the counter show how many people have clicked 'ready'.
This is cosmetic only. The game is still playable.

While on the subject: is it really necessary to click 'ready' after every playing action?

Some players get 28 points for war even though only 18 are possible

The possibility to select from whom the resources are bought (when both neighbours have the resource) would be nice, as this could be used tactically and is the intended way as per the rules.

The fantasy font in Firefox 70.0 on Fedora is not displayed. Manually changing to e.g. arial helps... but I think it is some addon causing this, as others on firefox do not have this issue

Scenario:

• enter player name and click "play now"
• you arrive on the game browser
• press the browser back button
• you arrive on the home page
• enter another player name
• click "Play now": nothing happens

When Halicarnassus (B) plays the last card of age 3 to upgrade its wonder the game ends before a card from the discard pile can be chosen.

When playing as Olympia B-side, upon building the first wonder stage (buy neighbouring resources for one gold), it becomes impossible to buy more than two resource units of the same type from the same neighbour, even though the neighbour has more than enough available and the player has enough gold.

It is impossible to start a new game. Neither hitting enter nor clicking the "plus" button work (tested on FF on Linux, Chromium on Linux, FF on Mac, Safari)

The hand component is not suitable for showing a lot of cards, which happens sometimes when a player picks from the discarded pile. The cards go out of the screen on both sides, especially on smaller screens (see screenshot).

We should have a specific component for that (e.g. a grid, or something with scroll)

We should show which players have prepared their cards, to know who to push 😄

Additionally, a loading element in place of the prepared card when the user hasn't prepared his move yet would be great.
(seeing stuff move makes it more lively)

It is sometimes strategic to give money to another neighbour even if the resulting price is more expensive overall.

However, options where we pay more to both neighbours make no sense and should never be selected.

Currently, players that joined a lobby can't get out unless they complete the game.