-
Notifications
You must be signed in to change notification settings - Fork 14k
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: Keep Report modal open when there's an error #17988
fix: Keep Report modal open when there's an error #17988
Conversation
Codecov Report
@@ Coverage Diff @@
## master #17988 +/- ##
=======================================
Coverage 67.07% 67.08%
=======================================
Files 1609 1611 +2
Lines 64905 64929 +24
Branches 6868 6872 +4
=======================================
+ Hits 43537 43556 +19
- Misses 19502 19506 +4
- Partials 1866 1867 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
Looks good, I just have a couple questions.
} | ||
|
||
onClose(); | ||
if (onReportAdd) onReportAdd(); |
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.
Is this the format preferred by prettier these days? I learned that braceless if clauses should be avoided because they can lead to subtle errors.
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's not preferred by prettier, I thought it was just a prettier way to do it, haha. I didn't realize there were subtle errors possible with this though, thanks for this catch! I'll change it back.
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 a single line is OK, since it's simple enough. The use that is discouraged is:
if (onReportAdd)
onReportAdd();
Which I think prettier
would remove.
I think it's fine to leave the way you did, I was just curious. :)
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.
Oh okay awesome, I'll keep an eye out for that behavior in the future just in case! Thank you! 😁
}).then(({ json }) => { | ||
dispatch({ type: ADD_REPORT, json }); | ||
dispatch(addSuccessToast(t('The report has been created'))); | ||
}); |
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.
What happens when the endpoint returns an error?
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 moved the catch functionality into the report modal here, this should handle any errors for this endpoint. Should I also put a catch in the action?
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.
Ah, makes sense, because we're no longer showing the error in the toaster, but in the modal. Thanks for clarifying! :)
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.
No problem! 😁
} | ||
label="Description" | ||
placeholder="Include a description that will be sent with your report" | ||
errorMessage="" |
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.
where do you display the error message?
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 spoke with Sophie separately and she said that this field doesn't currently have any restrictions so it won't have any errors applicable to its field. I left this blank since errorMessage
is a required field, and figured the error handling for this could be set up in the future if the description field ever ends up getting restrictions.
@@ -363,16 +374,16 @@ const ReportModal: FunctionComponent<ReportProps> = ({ | |||
|
|||
<StyledCronPicker | |||
clearButton={false} | |||
value={currentReport?.crontab || '0 12 * * 1'} | |||
value={t(currentReport?.crontab || '0 12 * * 1')} |
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 a translation is necessary here.
@@ -181,11 +193,10 @@ const ReportModal: FunctionComponent<ReportProps> = ({ | |||
const [currentReport, setCurrentReport] = useReducer< | |||
Reducer<Partial<ReportObject> | null, ReportActionType> | |||
>(reportReducer, null); | |||
const onChange = useCallback((type: any, payload: any) => { | |||
const onReducerChange = useCallback((type: any, payload: any) => { |
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.
curious why the switch from onChange to onReducerChange. If I'm reading this right, when the reducer changes, you update the reducer?
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.
In cases like this one, there was originally an onChange
nested into another onChange
. I thought that since there were two onChange
functions in the component it could get confusing, so I renamed the reducer's onChange
to onReducerChange
to clarify that onReducerChange
is specifically the function that the reducer uses to change state. Is that an unnecessary clarification, or is there maybe a better name I can use here?
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.
Ok, I gotcha. Normally the naming convention will be the element that is changing, rather than the function that is used to do the change, thus the confusion. Maybe something like onInputChange
would make sense.
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.
Good call, onInputChange
sounds a lot better! I'll change the naming once I reopen this to fix it.
errorMessage={ | ||
currentReport?.name === 'error' ? t('REPORT NAME ERROR') : '' | ||
} | ||
errorMessage={currentReport?.error || ''} |
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.
how/when does this error get cleared out? Does it stay visible until they hit submit again? I'm not sure if we discussed how this should look @yousoph?
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.
Currently the error stays until the user submits the form again. Once they hit submit it will rerun, if there's still an error it will stay open with that error. If the error is corrected it will close. I think it would be nice to have the error cleared as soon as the user fixes it, but I think that would require front end validation vs. just back end.
SUMMARY
The report modal was only using toasts for responses - error or success - so the user would have to reopen the modal to fix an errored report. The error is now brought into the modal directly and displayed underneath the name field, and will not close until the error is corrected.
Note: The name field is currently the only field that takes this type of error. The cron scheduler is the only other thing that has an error in this modal, and it has its own separate error handling already set up.
Note II: I also did some code cleanup in the report modal.
ANIMATED MOV
This demonstrates the modal correctly staying open and closing and also keeping correct values in the following events:
successfulError.mov
TESTING INSTRUCTIONS
ADDITIONAL INFORMATION