The Epochtal web frontend is a mess, at least compared to the rest of the code. Sure, it's documented, it's readable, you can understand how and why it does what it does. But it lacks structure.
There is tons of code duplication everywhere, and the only thing preventing this from going out of hand is the fact that our front page is one HTML file. Even that has duplicated code with only slight variances in each instance. And that, of course, doesn't cover cases where a separate page is needed (e.g. Epochtal Live).
I propose these features be given class structures:
Popups. Specifically, one barebones parent class used for basic "alert" popups, and other child classes inheriting this to add things like input fields, additional buttons, etc.
Error handling. In the current codebase there are at least 3 different inconsistent styles of try/catch with massive inline "ERR_***" blocks. One error class could be extended with handlers for each possible context, like SubmissionError, ProfileError, LobbyError, etc.
Handling /api/users/whoami calls. This is less significant, but the code for this still gets duplicated a lot.
Time parsing. The tools.js file already contains procedures for converting between ticks and a time string, but a universal class for speedrun time wouldn't hurt.
Generating HTML. The code for generating voting map list entries is used (and duplicated) twice on the home page, once in lobbies, with minor differences. Leaderboard entries could run into a similar issue.
There's probably more, this isn't an exhaustive list.
The Epochtal web frontend is a mess, at least compared to the rest of the code. Sure, it's documented, it's readable, you can understand how and why it does what it does. But it lacks structure.
There is tons of code duplication everywhere, and the only thing preventing this from going out of hand is the fact that our front page is one HTML file. Even that has duplicated code with only slight variances in each instance. And that, of course, doesn't cover cases where a separate page is needed (e.g. Epochtal Live).
I propose these features be given class structures:
/api/users/whoamicalls. This is less significant, but the code for this still gets duplicated a lot.tools.jsfile already contains procedures for converting between ticks and a time string, but a universal class for speedrun time wouldn't hurt.There's probably more, this isn't an exhaustive list.