-
Notifications
You must be signed in to change notification settings - Fork 61
Add Confirmation Before Dev Tool Removal and Modification [AARD-2033
]
#1265
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: dev
Are you sure you want to change the base?
Add Confirmation Before Dev Tool Removal and Modification [AARD-2033
]
#1265
Conversation
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 think it would be better to say that the zones were defined in the field file/asset file/mirabuf file and avoid all reference to the developer tools. I think that, in theory, the developer tools are used by us to add this information to the cached files that people download, and so we shouldn't expect that they've used them / know they're there.
Also, this doesn't handle modifying the zones
AARD-2033
]AARD-2033
]
6f24ff1
to
988f39a
Compare
} | ||
|
||
return ( | ||
<Dialog open={isOpen} onClose={onClose} maxWidth="sm" fullWidth> |
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 think it's fine to make language consistent rather than doing this ternary stuff. Removing a zone is a modification or change to the field, and I think it makes the code a lot cleaner to use the same words
<strong>Temporary {actionType === "modification" ? "modification" : "removal"}:</strong>{" "} | ||
{actionType === "modification" | ||
? "Save changes until next field reload. Original zone will reappear when you refresh or reload the field." | ||
: "Remove zone until next field reload. The zone will reappear when you refresh or reload the field."} |
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.
"refresh or reload the field" is kind of a weird expression, "refresh the page" is much clearer IMO
<Typography variant="body2"> | ||
<strong>Permanent {actionType === "modification" ? "modification" : "removal"}:</strong>{" "} | ||
{actionType === "modification" | ||
? "Save changes to the field file cache. This will persist your modifications on future loads." |
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.
"Save changes to the local asset file. This will persist your modifications until you remove it from the cache."
actionType?: "removal" | "modification" | ||
} | ||
|
||
const DevtoolZoneRemovalModal: React.FC<DevtoolZoneRemovalModalProps> = ({ |
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.
should probably be renamed if this is being generalized
|
||
const editor = new FieldMiraEditor(parts) | ||
|
||
if (zoneType === "scoring") { |
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 it makes very much sense to have all of this in this conditional, it looks like you can generalize this for either zone type and avoid making unnecessarily specific code
devZone.name === originalZone.name && | ||
devZone.alliance === originalZone.alliance && | ||
devZone.parentNode === originalZone.parentNode && | ||
JSON.stringify(devZone.deltaTransformation) === JSON.stringify(originalZone.deltaTransformation) |
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.
it appears you're using these properties because they overlap on the two different zone preferences types. I think it would make sense to enforce this more rigorously by having a BaseZonePreferences
type with the common properties that they both extend. This would be basically the same as ScoringZonePreferences|ProtectedZonePreferences
, except that it would be robust aginst changes to those types
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.
Alternatively, generating IDs on load for the zone preferences objects (they don't need to persist in the cache or across reloads) might be a more robust way to compare two zones that doesn't require the structuredclone
Task
Add a confirmation dialog when removing a Dev Tools–placed scoring zone, allowing the user to either remove it temporarily (current behavior) or permanently by also deleting it from the Dev Tools cache.
Jira Ticket
Symptom
Currently if you remove a protected zone or scoring zone from the configure field panel that is placed by the dev tool it will remove it until the next refresh. Only the dev tool is able to cache scoring zone placement.
Solution
Popup a confirmation window when we remove a scoring zone that was placed by dev tools, and give us the option of removing it from dev tools as well (saving to cache).
Verification
Before merging, ensure the following criteria are met: