What has been done to verify that this works as intended?
New tests, trying it locally.
Why is this the best possible solution? Were any other approaches considered?
The main decision point was how to modify the odataEntities resource after deletion. After looking at how odataEntities is used, I ended up concluding that it was simpler not to modify odataEntities.value. We will just hide the deleted row. Taking that approach allows EntityList and SubmissionList to stay more consistent and avoids re-rendering EntityTable. odataEntities will now store the number of deleted entities.
Another thing I thought about was concurrent requests. If you check the checkbox to not ask again before deletion, then you will be able to send multiple, concurrent deletion requests. You can also have a deletion request at the same time as a request to refresh the table or change a filter (which will replace the table). I thought about trying to prevent some of those cases, but in the end, I don't think it's really needed: it's actually pretty easy to handle most of those cases, so there aren't many bad states to prevent. I do know of an edge case where the entity count ends up being wrong, but it's pretty unlikely, and it also doesn't seem like a big deal. Overall, I think it's better not to lock down the interface.
Before submitting this PR, please make sure you have:
[x] run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
[x] verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced
Closes getodk/central#584.
What has been done to verify that this works as intended?
New tests, trying it locally.
Why is this the best possible solution? Were any other approaches considered?
The main decision point was how to modify the
odataEntitiesresource after deletion. After looking at howodataEntitiesis used, I ended up concluding that it was simpler not to modifyodataEntities.value. We will just hide the deleted row. Taking that approach allowsEntityListandSubmissionListto stay more consistent and avoids re-renderingEntityTable.odataEntitieswill now store the number of deleted entities.Another thing I thought about was concurrent requests. If you check the checkbox to not ask again before deletion, then you will be able to send multiple, concurrent deletion requests. You can also have a deletion request at the same time as a request to refresh the table or change a filter (which will replace the table). I thought about trying to prevent some of those cases, but in the end, I don't think it's really needed: it's actually pretty easy to handle most of those cases, so there aren't many bad states to prevent. I do know of an edge case where the entity count ends up being wrong, but it's pretty unlikely, and it also doesn't seem like a big deal. Overall, I think it's better not to lock down the interface.
Before submitting this PR, please make sure you have:
npm run testandnpm run lintand confirmed all checks still pass OR confirm CircleCI build passes