Conversation
This is not mergeable code, but demonstrates the idea. Define per scoring type a rendering function and a sorting function on the front-end. Should be refactored and rebased on `main`.
|
In general, using our API to provide data and then doing rendering on the client side is fine and promising. However, I dislike adding sorting functions into the client. We should keep a single source of truth in the backend, e.g. by exposing the |
Having two implementations of sorting is indeed tricky. For this PoC, I explicitly used the backend-provided sorting for the "normal" scoreboard view, and only implemented some custom sorting for a pass/fail problem type to sort on a single problem. I think that implementing a sorting function for these non-standard cases in the frontend is fine, but would love to hear other's opinions. |
What's the argument against exposing the sort_key in the API so you don't have to re-implement sorting functions in multiple places? |
I might have missed some changes, but as far as I am aware I could not sort on the individual problems based on merely the overall sort key. We could introduce sort-keys per-problem. |
| } | ||
|
|
||
| let sortCmp = (a, b) => ((a < b) ? -1 : ((a > b) ? 1 : 0)); | ||
| let sortProblem = (a, b) => { |
There was a problem hiding this comment.
Basically, to reproduce this (ugly) implementation
|
Do I understand correctly that you want to be able to filter columns and not just rows? Just rows would be trivial by the sort_key, filtering columns is indeed problematic |
2 participants
This is not merge-able code, but demonstrates the idea to start a discussion whether or not this is a direction we want to go.
Currently, we have core logic about what is visible to users on both the API, the mobile scoreboard, and the normal scoreboard. There have been some issues that some information was visible which should not have been given configuration settings. If we render the scoreboard on the frontend, we can eliminate this complex but important logic.
The other benefit is that it enables advanced features on the frontend. If we define per scoring type a rendering function and a sorting function on the front-end, we can dynamically sort and filter without putting a huge load on the DOMjudge server.
For the static scoreboard, the JSONs should be included, similar to how the submission data is stored. This is not included in this PoC.
As this is a draft, created some time ago, I have not rebased on main. If we think this is a good direction to go, I can work on a proper implementation and on current main.