-
-
Notifications
You must be signed in to change notification settings - Fork 737
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
fix(1-3173): clear "removed tags" when you bulk update tags #8952
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
const submitAndClear = () => { | ||
onSubmit(payload); | ||
dispatch({ type: 'reset' }); | ||
}; |
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.
maybe submitAndReset
? Clear is related to removing also "initialValues" because of reason === 'clear'
on an Autocomplete
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.
Yes, good point. I agree with this. But do you have a different word for clear, because having both is really confusing me. Maybe "resetToInitialValues" or something?
This PR fixes a bug wherein the list of tags to remove from a group of tags wouldn't be correctly updated.
Repro steps
frontend/src/component/feature/FeatureView/FeatureOverview/ManageTagsDialog/ManageBulkTagsDialog.tsx
'sManagebulkTagsDialog
. Log the value of thepayload
variable.Discussion points
This gives us both a
clear
and areset
event, which is unfortunate because they sound like they do the same thing. I'd suggest renaming theclear
event (because it doesn't really clear the state completely), but I'm not sure to what. Happy to do that if you have a suggestion.I have not tested that submission of the form actually resets the state. I spent about 45 minutes looking at it, but couldn't find a way that was sensible and worked (considered spying: couldn't make it work; considered refactoring and extracting components: think that's too much of a change). I think this is benign enough that it can go without a test for that thing actually being called.
I did, however, test the different reducer commands.