Suggested architecture for managing Board states

[jakehsiao]

Currently, I'm using vanilla React stateful component for Board, Board states controls how moves are called, for example adjusting the parameters(https://github.com/dadiaogames/arknights-card-game). It's like using Board as frontend and Game as backend.

Now I am thinking about adding a redux store to frontend(Board) but the Game itself is a redux store, two stores does not fit the rule "one single source of truth".

Then here are several possible architectures to choose for writing games:

• Use vanilla React stateful component(currently using)
• Use another Redux store for frontend
• Manage all states, including frontend states, in Game, via moves, and let all Board components stateless

Which one is suggested?

[delucis]

Hi @jakehsiao — I think any number of approaches are valid — it can depend on the game and the nature of the UI. I think the “single source of truth” practice refers above all to using a single source per data element, rather than a single source for everything. So if a Redux store managing board state in addition to the store provided by boardgame.io works for you, great! I’ve used something similar in the past with React context and the useReducer hook. However, if the state is simple enough and not shared across components too much, stateful components can be enough too.

The one option I would avoid would be storing frontend state in the boardgame.io store. For example, you don’t really want to use a move, incurring a server round-trip and updates for all players, to open a modal. It can complicate game logic significantly if you need to allow multiple players to make moves simultaneously just so they can mutate their client state when it’s not their turn.

Regarding the “single source of truth,” I think if needed you can probably still design a local store to depend on the boardgame.io state. When the board props update, you could dispatch an action to the board state reducer with the new props and check if you need to change state (e.g. dismiss some client UI to make sure the player sees the result of the game update).

I would be curious to hear what solutions other users have come up with and if there some particular pain points people encounter managing this kind of thing.

[adngdb]

For in-game front-end specific state, I use component state all the time. As @delucis said, it is a bad idea to store that in the shared state, as it involves sending that data over to the server and to all other players, which is useless.

For out-of-game state, I currently also use component state, but I think I'm soon going to be using a different, local redux store. That makes sense to me, as both stores have completely different purposes. I'm not sure how that's going to work out regarding providers and context, though, but I guess with strict components delineation that will be fine.