Code smell: Setting state twice in a row Example: Solution: Eliminate showDialog state. Derive state instead. If userToEdit has a value, show the dialog. If userToEdit is null, hide the dialog. Benefits: -Less state to manage -Avoids illogical combinations (it's illogical for userToEdit to be null when showDialog is true).

Problem: You need to represent an empty number. Hack: Use 0, -1, or "". The real solution: Use null. That's what it's for. Null says, "This has no value". 0, -1, and "" are a lie.

Problem: 🚫 Your project has unused files. 🚫 It has unused npm dependencies. 🚫 It has unused TypeScript exports. But you haven't noticed, because these things are hard to spot. Solution: knip I just used knip to find and resolve dozens of issues. github.com/webpro/knip

Problem: When you deploy a new version of your SPA, users with a tab open will keep using the old SPA code. Yesterday, I shared one solution. People suggested dozens of useful variations and alternatives. 🙏 So, here are the best options in the massive thread. 6 ways to tell the SPA a new release is available, simplest options first: 1. Write the version from package.json into index.html as part of the build process. Poll index.html every x minutes and compare the server's index.html to the client's index.html. 2. Create an endpoint on the UI web server that reads the package.json version, and returns it. Poll this every x minutes. This is more efficient than option 1, because the payload is smaller. 3. Use web sockets or server sent events to push a notification to the UI after a deploy instead. This is especially attractive if you’re already using these technologies. 4. Use a service worker to notify the user when the UI is stale. For example, Vite's PWA plugin supports this. 5. Use an API proxy like Cloudfront to fetch the version without involving the backend. More here: rehanvdm.com/blog/using-a-cl… 6. Specify the app version in each HTTP call from the UI via a x-app-version header (or whatever name you like). Validate the x-app-version header on the API server. If x-app-version doesn't match the server's version, notify the UI in the response, either via an HTTP 205, 400, or 422 (the HTTP response you return depends on whether you want calls from a “stale” UI to succeed).

Sometimes, a performance problem is actually a design problem. Example: “How do we fix the performance of this page showing 1,000+ items?" Answer: Stop showing so much stuff at once. What user can absorb 1,000’s of items? Make it easy for the user to find what they need.