princemaple
Minesweeper - built with liveview and other recent tools
TLDR: https://minesweeper.fly.dev built with liveview and other recent tools.
Most relevant code at mine_sweeper/lib/mine_sweeper_web/live/session_live at main · princemaple/mine_sweeper · GitHub
Hi All,
My most familiar stack is building frontend with Angular and using phoenix as an API backend. I briefly tried liveview when it first came out. That was pre-heex, pre-component era. I’ve been wanting to try the shiny new stuff and stay up to date.
I could’ve chosen a different game if I simply wanted to build something interactive and realtime. I chose minesweeper because 1. it’s one of my favorite games, 2. it requires a lot of state keeping and inter-component communication (I initially thought each component would be a separate process) and 3. it requires quite a bit interaction (event handling). I thought it’s a good game to build to test all these things out.
Plus, there has been a couple other things on my listing waiting to be checked out.
- fly.io deployment
(I’ve used the one-click to launch livebook. It’s great) - phoenix with esbuild and tailwind
(they are not new to me, I just haven’t built a phoenix app that uses them to build the assets)
So, I decided to build this minesweeper game with liveview, with the assets built with esbuild & tailwind, and deployed to fly.io
A few notes:
- as previously mentioned, I initially thought each component was a separate process. That wasn’t the case. So there isn’t really much “inter-component communication”. I built the game with GenServers, while liveview and components were solely used to render and interact.
forinheexseems to update all or nothing. I thought it would be able to only update the ones with thier assigns changed. Easy workaround though, just check the new assigns with the assigns on socket.- somewhat often, changes in assets, sometimes also in GenServers, don’t get reflected in the running app. Not sure if building on Window directly had something in it. I normally dev with docker and this is not an issue.
Overall everything went pretty smoothly.
GitHub - phoenixframework/esbuild: An installer for esbuild · GitHub and GitHub - phoenixframework/tailwind: An installer for tailwind · GitHub do a very good job getting me started, and provide very sensible docs and defaults. Deploying to fly.io was also easy, fly launch made it almost a no brainer. It generates a very good dockerfile and other relevant deployment related files. Heex is great to great to work with. Components do a good job separating small parts of the UI, encapsulating both their rendering and logic, allowing easy reuse.
I feel like I’ve got an OK understanding of latest liveview.
Things left to explore later: I did try out deploying to multiple regions on fly.io, which was easy, but I didn’t know how its routing works and whether you could reliably hit your closest server, so I reverted back to single server. Maybe a fun thing to do is to deploy a multi continent cluster and have the games shown globally. (oh, did I mention that you can enter others’ games and mess with help them)
Reviews and comments are welcome. Questions too!
Stay safe.
Most Liked
03juan
Late to the party but for funsies ![]()
def neighbours2({x, y} = orig) do
for x_mod <- [1, 0, -1],
y_mod <- [-1, 0, 1],
x_new = x + x_mod,
y_new = y + y_mod,
x_new in 0..8 and y_new in 0..8 and {x_new, y_new} != orig do
{x_new, y_new}
end
end
qhwa
Awesome project, congrats!
I had the same question before and ended up using the following approach with a CDN test tool to confirm that it was routed to the nearest region.
# config.exs
config :my_app, region: System.get_env("FLY_REGION", "unknown")
# my_plug.ex
conn |> put_resp_header("x-fly-region", Application.get_env(:region))
Anycast is amazing.
LostKobrakai
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









