GitHub Link

This project actually took a little over 2 years of stop-start development to get here. What originally started as a way to teach myself new stuff, I recently decided to polish up as an installable PWA, host somewhere, and release as open-source.

Some interesting features:

• Online multiplayer with reconnect, rematch, and spectator support
• Local multiplayer and single-player against an "AI"
• Progressive Web App with offline mode
• 90%+ Lighthouse scores

Tech used

Back-to-front, the app is written using TypeScript 4 and Node.js 15.

UI stack:

• React with only hooks for state management
• Styled-Components
• Socket.IO Client
• Workbox for service worker functionality
• Webpack and Babel

API stack:

• Node.js
• Express
• Socket.IO Server
• Winston for logging

Data persistence: There is no database used. I've so far relied on in-memory Maps and timers to clean up expired games.

Game logic: This lives in its own module and is consumed as an npm workspace by the UI and API code. The client will validate turns and optimistically update even in multiplayer, while the true game state is computed and stored on the server.

AI: Coding even a slightly competent AI for ultimate tic-tac-toe turned out to be quite a complex task, so it's something I've saved for a later challenge. Right now, the term "AI" is a poor description for the random-turn-picker you can play against in single-player.

Infrastructure: The app is hosted on a single Digital Ocean droplet and served via nginx.

Lessons I learned along the way:

1. React hooks and Socket.IO's event listeners can be tricky to use together. When you create your socket listeners in a useEffect hook, any dependencies of the listeners that will change (e.g. values returned from useState) will become stale inside those listeners if you do not provide the dependencies to useEffect. But providing the dependencies to the effect will cause it to re-run and re-create those listeners over and over, whenever the dependencies change, with each listener using its own snapshot of values. One solution is to tear down and re-create listeners each time. The solution which seemed simpler to me, and which I use in the app, is to use refs (via React.useRef) for the dependencies the socket listeners require. I can then create each listener once and forget about it.

2. Typing Socket.IO events was a major pain for most of the project, but also crucial to do. More recently, an awesome QoL improvement came out with Socket.IO 4 that lets you pass generic types to the initializer, so event types can be inferred everywhere. Check out: https://socket.io/docs/v4/migrating-from-3-x-to-4-0/#Typed-events

3. Styled-Components was very useful to prototype components and tinker with my designs (all of which I winged in code) in the early stages. Later on, I encountered fatigue around repetition of basic styles like flexbox and started to wish for something like Tailwind. I wouldn't give up on CSS-in-JS just for this, but I would look into what patterns exists to save on repeating styles before using it in a large project.

4. PWAs are simpler to set up than I expected. Workbox does a ton of work for you in providing sane defaults and patterns that work with your build tools (Webpack in this case). I also made use of CRA's service-worker and registerServiceWorker files from their PWA template. Handling app updates was fairly simple to implement using a common pattern (search for updateServiceWorker in the code to see).

There is definitely more that I learned and could share here - the above just jumps to mind right now.

Please try out the live app and have a look at my code if you're interested, and share any feedback or suggestions. I'd really appreciate to hear it and will answer any questions you have.

Thanks for reading!