-
Notifications
You must be signed in to change notification settings - Fork 31
Give warning for duplicate results #282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
jonatanklosko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks for looking into this, I dropped some comments :)
| setBatchResults([ | ||
| ...batchResults.filter((result) => result.id !== editedResult.id), | ||
| { id: editedResult.id, attempts, enteredAt: nowISOString() }, | ||
| { id: editedResult.id, attempts, person, enteredAt: nowISOString() }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should be storing the whole person object in local storage.
What we could do is, right before calling attemptResultsWarning, we can build a copy of results with changes applied. We can map over results and look for a batch result entry with a matching id, if the is one, we take its attempts.
One issue with checking against batch results is that once we show the warning, it may be confusing, because there will be no visible results for the conflicting person (they are in the batch). But I guess it's better than not showing the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! I decided to create a new combinedResults array in the AdminRoundContent component so that it can be recalculated only when it needs to change. Let me know if that looks good to you; I'm not a React expert by any means!
I also realized that this warning would pop up if you pulled up a result and tried to enter it without changing anything. I saw a couple people using this functionality to refresh results data without needing to refresh the entire page. In the interest of not breaking current users' workflows, I opted to filter out the current result from the duplicate check.
…he batch or round changes
…eck-for-duplicate-results
…und changes, so this useEffect can just use `round` as a dep
| // We don't want to show a duplicate warning if the user is submitting | ||
| // already-entered results for the correct competitor. This is often used | ||
| // as a quick way to refresh data without refreshing the whole page. | ||
| const resultsToCheck = combinedResults.filter( | ||
| (res) => res.id !== result.id, | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would compute combinedResults together with the filter here.
Computing them upfront, as in the current version, doesn't have any benefit, because it would be recomputed after every submission anyway.
| const combinedResults = [...results]; | ||
| batchResults.forEach((batchedResult) => { | ||
| const i = combinedResults.findIndex((res) => res.id === batchedResult.id); | ||
| combinedResults[i] = { | ||
| ...combinedResults[i], | ||
| attempts: batchedResult.attempts, | ||
| }; | ||
| }); | ||
| return combinedResults; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw. you can also write it like this:
| const combinedResults = [...results]; | |
| batchResults.forEach((batchedResult) => { | |
| const i = combinedResults.findIndex((res) => res.id === batchedResult.id); | |
| combinedResults[i] = { | |
| ...combinedResults[i], | |
| attempts: batchedResult.attempts, | |
| }; | |
| }); | |
| return combinedResults; | |
| return results.map((result) => { | |
| const batchResult = batchResults.find((batchResult) => batchResult.id === result.id); | |
| if (batchResult) { | |
| return { ...result, attempts: batchResult.attempts }; | |
| } else { | |
| return result; | |
| } | |
| ); |
I consider it slightly more direct in terms of readability, though either version is fine :)
I saw this issue #274 and thought I'd give it a try.
Breaking changeIn order to check for duplicate results in the current stored batch, I changed the format of the stored batch results in localStorage to include thepersonattribute. I figured that made more sense than fetching it each time, since theoretically this should affect few people (only data batches which are in-progress before deployment and need to be refreshed after); but maybe this is a rare enough case that it's better not to introduce a breaking change. What do you think?Removed after discussion, in favor of creating a
combinedResultsarray