-
Notifications
You must be signed in to change notification settings - Fork 19
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 bug on hearing details page where email error messages weren't being displayed #15044
Conversation
Generated by 🚫 Danger |
Code Climate has analyzed commit d98fe9a and detected 0 issues on this pull request. View more on Code Climate. |
…ges made to the virtual hearing
…ative timezone back to the initial value
…deo-virtual hearing
…ng modal is being displayed
@@ -148,7 +148,7 @@ export const HearingConversion = ({ | |||
<div className={classNames('usa-width-one-half', { [noMaxWidth]: true })} > | |||
<Timezone | |||
errorMessage={errors?.representativeTz} | |||
required={virtualHearing?.representativeEmail} | |||
required={Boolean(virtualHearing?.representativeEmail)} |
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.
Fixes a console PropType
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.
Thank you so much for fixing this!
@@ -55,7 +56,7 @@ export const VirtualHearingFields = ({ | |||
<div className="usa-width-one-third"> | |||
<Timezone | |||
errorMessage={errors?.representativeTz} | |||
required={virtualHearing?.representativeEmail} | |||
required={Boolean(virtualHearing?.representativeEmail)} |
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.
Fixes a console PropType
warning
<p> | ||
<strong>Representative Email</strong> | ||
<strong>POA/Representative Email</strong> |
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.
Makes this label match the pop-up that shows for formerly central virtual hearings
@@ -15,7 +15,7 @@ def update_hearing | |||
end | |||
|
|||
def hearing_updated? | |||
super || advance_on_docket_motion_attributes&.present? | |||
super || advance_on_docket_motion_attributes.present? |
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.
Small fix so this returns false
instead of nil
if advance_on_docket_motion_attributes == nil
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.
Logic looks great! Just mentioned a few things I think we should address, thanks!
hearing: { ...state.hearing, ...value }, | ||
formsUpdated: !isEmpty(deepDiff(state.initialHearing, { ...state.hearing, ...value })) | ||
}); | ||
const setUpdated = (state, value) => { |
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.
Refactoring this way doesnt change the logic at all, I think we should leave this as is
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.
IMO the refactor makes it a bit easier to understand what's going on. Previously, the expression which represents the merged new hearing, { ...state.hearing, ...value }
, was repeated twice. I think the intention of the call to deepDiff
is to determine if there are changes between the new hearing and the initial hearing, which I think the refactor captures a bit better.
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.
Refactoring this way also adds mutation to the function because instead of using the splat operator to assign the formsUpdated value, you are first creating an object and then assigning the value. I really think we should leave this as is because it follows functional programming guidelines of not-mutating
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 generally agree with not-mutating, but I don't see the downside here because we are mutating a local that's declared and instantiated inside the function. I could see it being a bigger problem if we were mutating the field of an argument that was being passed in.
One alternative way of doing this could be:
const setUpdated = (state, value) => {
const newHearing = { ...state.hearing, ...value };
return {
...state,
hearing: newHearing,
formsUpdated: !isEmpty(deepDiff(newState.initialHearing, newHearing))
};
};
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.
That refactor is better because it does not mutate. While I don't agree that this makes the code easier to read IMO it actually makes it more difficult, this does follow guidelines so I will concede
client/app/hearings/utils.js
Outdated
@@ -63,9 +63,15 @@ export const deepDiff = (firstObj, secondObj) => { | |||
const secondVal = secondObj[key]; | |||
|
|||
if (_.isEqual(firstVal, secondVal)) { | |||
result[key] = null; | |||
delete result[key]; |
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.
Can we refactor this to be a pure function? I am concerned about using delete
because it can lead to unintended side-effects that are hard to debug due to JavaScripts asynchronous data access.
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, removed the calls to delete! Please take a look again!
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.
LGTM thanks!
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.
LGTM
Resolves #14990
Description
update => update!
)Acceptance Criteria
Testing Plan
123456
User Facing Changes