evelynhathaway / triton-poll Goto Github PK

Triton Poll was commissioned by a university club, so v1.0.0 was what I scoped out with the client in the time that I had between my classes and before their conference. However, I kept a list of what I would've done if I had any more time. So now I'm adding this list for when I possibly circle back to this project for fun.

• Error catching
  • v1.0.0 trusts the client to not send non-destructurable data, this is a no-no
• Audit security and sanitization
• Passwords for joining a room as a speaker (auth system?)
• CSS grid the placards for the speaker? (#6)
• Larger placard for the audience?
• Anything with TODO in the project
• Don't send member data to the server, instead use the server state and UUIDs
  • This is partially completed
• Move Maps to objects?
  • I didn't have the resources to analyze the performance (hashmap, interaction, etc.) considerations
• Share more code between audience and speaker
• Use more limited states (not global state, etc)
  • React Hooks seem like an amazing solution for my coding style
• Make components functional components with React Hooks and helper functions instead of methods
• Code splitting
  • Speaker/audience are mutually exclusive in most scenarios which helps
• Hot reload on dev instead of browser-sync
• Speakers list management
  • Allow the speakers to add to the speakers in any position, reorder, and remove
  • Display speakers list to the students
• Don't use bootstrap?
  • It's very heavy for what it's currently being used for in this small project
• Fix linting issues
• Make conference name, session number, etc. come from a config file and interpolated on build
• Stop using alert() to show errors to the user (alert sucks, can also technically disconnect a user if they keep it open as long as the ping-timeout is)
  • <AlertBanner> should be extended to use Bootstrap's dismissable banners
• Use a database instead of a volatile, single-node object
  • Prune old rooms and members
• Don't randomly make profane room codes
  • The chances are extremely low and the speaker could just not use that room, but retext would be pretty much plug-and-play
• Initial set and reset state using a single source default/initial state
• Send only needed audience/speaker member changes (not whole audience list)?
  • Possibly toast when a new audience member joins (speaker side only)?
• Bundle Bootstrap/jQuery
• Prefix/compile CSS
  • I manually did this, but adding it to the build step would be a great addition
• Pass Lighthouse audits
  • Mainly network-related and PWA tests
• Room code served as route, prompt for the country on load when the UUID isn't in the server state, join
• Make sure tree shaking works, analyze bundle
• Unit tests, add Lighthouse CI to GitHub tests

• Make placards (audience and speaker side) buttons
• Improve contrast ratios on .btn-primary (from Bootstrap) buttons
• Improve contrast ratios on raised placards
• Use headings for app name and committee name at the top (use heading group for when in a room)
• Make placard titles styled text
• Check accessible texts/labels for buttons and placards
• Run a more extensive accessibility audit