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
(feat) O3-2177: Tweak the patient banner details section to match designs #1197
Conversation
Please add screenshots to get the review started. |
This is not specific to just tablet and desktop. The width of the patient banner will decide this. |
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.
Some nitpicking
Great work altogether 👏
packages/esm-patient-banner-app/src/banner/patient-banner.component.tsx
Outdated
Show resolved
Hide resolved
const currentRef = patientBannerRef.current; | ||
const resizeObserver = new ResizeObserver((entries) => { | ||
for (const entry of entries) { | ||
setIsPatientBannerSmallSize(entry.contentRect.width < 1023); |
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.
Why 1023?
@@ -60,6 +76,7 @@ describe('PatientBanner: ', () => { | |||
const user = userEvent.setup(); | |||
|
|||
const patientBannerSeachPageProps = { ...testProps, onClick: mockNavigateTo }; | |||
window.ResizeObserver = ResizeObserverMock; |
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 you try adding the test to check that on decreasing the window size, the count of columns is changing or not.
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 have catered for this in the Contact details component.
enabled: { | ||
_type: Type.Boolean, | ||
_description: 'whether to enable using custom address labels', | ||
_default: false, | ||
}, | ||
customAddressLabel: { | ||
_type: Type.Object, | ||
_description: 'custom labels for addresses', | ||
_default: {}, | ||
}, |
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.
Why this change?
This change might break the other implementation.
Changing the config should be announced in the PR's description, as this will affect other people using the old config.
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.
This is to fix the issue of not displaying the address keys.
We were using customAddressLabel
object to conditionally the custom labels here
There is a solution, using
Object.keys(customAddressLabel).length > 0 ? ... : ...
but I thought adding the enabled boolean might be more explicit
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.
@vasharma05 @denniskigen Please let's be a little more careful defining config schema, since as you say Vineet, changing things can affect existing implementations.
Having a boolean like this is redundant and not useful. Put yourself in the implementer's shoes and think about how they build a config. The only thing a boolean like this does is adds confusion and complexity, breaking things that should work.
Also, the way this has been implemented, the implementer has to provide every piece of the address as a key to the object or else it silently screws up (displays nothing where there should be a label). A better solution is to make it so an implementer only needs to provide configuration keys for the address labels they want to change.
But actually, I don't see why we don't just handle this using translation overrides? These strings go through translation. I suspect this isn't needed at all.
const extractName = (display: string) => { | ||
const pattern = /-\s*(.*)$/; | ||
const match = display.match(pattern); | ||
if (match && match.length > 1) { | ||
return match[1].trim(); | ||
} | ||
return display.trim(); | ||
}; | ||
|
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.
@dkayiwa , please review this.
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.
If the display property contains an identifier and a name, such as "100304E - John Doe", the regular expression pattern /-\s*(.*)$/
will match the hyphen and any subsequent whitespace characters. It captures the remaining part of the string (the name) using the (.*)
group. The extracted name is then returned by the extractName
function.
On the other hand, if the display property doesn't contain a hyphen and identifier, such as "John Doe", the regular expression pattern won't find a match. In that case, the extractName function will simply return the original display property string, trimmed of any leading or trailing whitespace.
Let me hope we won't have the display being "John Doe - 10008E"
, there it will break
packages/esm-patient-banner-app/src/contact-details/contact-details.component.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-banner-app/src/contact-details/relationships.resource.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-banner-app/src/contact-details/relationships.resource.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-banner-app/src/hooks/usePatientListsForPatient.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-banner-app/src/hooks/usePatientListsForPatient.tsx
Outdated
Show resolved
Hide resolved
@donaldkibet @CynthiaKamau @makombe do you anticipate that these changes might break anything in your current config? |
describe('ContactDetails', () => { | ||
it('renders an empty state view when relationships data is not available', async () => { |
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 removed this case since it was catered for in the empty view case for all sections
80627ab
to
22b4768
Compare
f7e3119
to
2e1ea3a
Compare
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, @Jexsie.
Requirements
Summary
address
keys in the address column inside the patient bannercustomAddressLabels
Screenshots
Screencasts
Screencast.from.2023-06-15.12-19-21.webm
Related Issue
https://issues.openmrs.org/projects/O3/issues/O3-2177
Other
Might require checking on #1175
Sample Config