This is one part of getting to #245: getting rid of the manual Refresh button actions.
This PR solves one of the original reasons for having that button (instead of having e.g. a timer / message refresh it in the background). The problem was that whenever the scores.json was reloaded from the server, any in-progress edits would be 'reverted'.
Now, edits can be made while scores.json is reloaded from server.
An edit will be cancelled whenever the server version also changed the score that's being edited (or it was removed).
Note that this doesn't yet solve other aspects (e.g. automatically refreshing, non-atomic merges on the server, etc.). This was already the case, and is a subject for further PRs.
poelstra
commented
6 years ago
This is one part of getting to #245: getting rid of the manual Refresh button actions.
This PR solves one of the original reasons for having that button (instead of having e.g. a timer / message refresh it in the background). The problem was that whenever the scores.json was reloaded from the server, any in-progress edits would be 'reverted'.
Now, edits can be made while scores.json is reloaded from server. An edit will be cancelled whenever the server version also changed the score that's being edited (or it was removed).
Note that this doesn't yet solve other aspects (e.g. automatically refreshing, non-atomic merges on the server, etc.). This was already the case, and is a subject for further PRs.