Sengoku 1.0's architecture had a tree of React components subscribed to changes in the game state via a Phoenix channel. That worked well enough, but had some performance struggles. I'm interested to play with LiveView, and its performance from sending minimal data over the wire is impressive (plus I'd rather be writing Elixir than JavaScript).
So, Sengoku 2.0 removes all React and custom JS in favor of a single LiveView component, GameLive. Instead of a Phoenix channel, the game's state is pushed to each player's LiveView over Phoenix.PubSub. Some other changes:
Browsers are now identified by a secure session identifier rather than a token in localStorage, which is more secure (and avoids even more JS dependency)
The board is now made up of hexagons rather than geographic regions. While not strictly necessary, this simplified the markup for the LiveView and creates a solid foundation for more/custom maps, which is a goal of mine with the project
yakryder
commented
4 years ago
Sengoku 1.0's architecture had a tree of React components subscribed to changes in the game state via a Phoenix channel. That worked well enough, but had some performance struggles. I'm interested to play with LiveView, and its performance from sending minimal data over the wire is impressive (plus I'd rather be writing Elixir than JavaScript).
So, Sengoku 2.0 removes all React and custom JS in favor of a single LiveView component,
GameLive. Instead of a Phoenix channel, the game's state is pushed to each player's LiveView overPhoenix.PubSub. Some other changes: