Skip to content
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

Merged
merged 18 commits into from Jun 30, 2023

Conversation

Jexsie
Copy link
Contributor

@Jexsie Jexsie commented Jun 7, 2023

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

  • Updates the patient banner to fit the designs
  • Fixes the relationships resource error
  • Fixes issue of not displaying address keys in the address column inside the patient banner
  • Updates configuration of the customAddressLabels

Screenshots

image
image
image

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

{
  "@openmrs/esm-patient-banner-app": {
    "useCustomAddressLabel": {
      "enabled": true,
      "customAddressLabel": {
        "address1":"New Adress1 name",
        "district": "County",
        "address4": "Ward",
        "state": "Sub county",
        "city": "Village",
        "postalCode": "Postal Address",
        "country": "Location",
        "address5": "Sub Location",
        "address2": "Landmark"
      }
    }
  }
}

image

@vasharma05
Copy link
Member

Please add screenshots to get the review started.
Thanks!

@vasharma05
Copy link
Member

This is not specific to just tablet and desktop. The width of the patient banner will decide this.
For eg. on the advance patient search, the banner’s width is less and hence it will require 2 columns instead of 4.
This is implemented on the patient search, but will also include places where banner is being used in the workspaces.

@vasharma05 vasharma05 changed the title (fix) Update the Patient Banner to fit the designs (fix)O3-2177: Update the Patient Banner's show more details sections to match the designs Jun 8, 2023
@vasharma05 vasharma05 changed the title (fix)O3-2177: Update the Patient Banner's show more details sections to match the designs (feat) O3-2177: Update the Patient Banner's show more details sections to match the designs Jun 8, 2023
@Jexsie Jexsie marked this pull request as ready for review June 13, 2023 18:48
Copy link
Member

@vasharma05 vasharma05 left a 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 👏

const currentRef = patientBannerRef.current;
const resizeObserver = new ResizeObserver((entries) => {
for (const entry of entries) {
setIsPatientBannerSmallSize(entry.contentRect.width < 1023);
Copy link
Member

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;
Copy link
Member

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.

Copy link
Contributor Author

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.

Comment on lines +18 to +27
enabled: {
_type: Type.Boolean,
_description: 'whether to enable using custom address labels',
_default: false,
},
customAddressLabel: {
_type: Type.Object,
_description: 'custom labels for addresses',
_default: {},
},
Copy link
Member

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.

Copy link
Contributor Author

@Jexsie Jexsie Jun 15, 2023

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

Copy link
Contributor

@brandones brandones Dec 27, 2023

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.

Comment on lines +156 to +161
const extractName = (display: string) => {
const pattern = /-\s*(.*)$/;
const match = display.match(pattern);
if (match && match.length > 1) {
return match[1].trim();
}
return display.trim();
};

Copy link
Member

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!

Copy link
Contributor Author

@Jexsie Jexsie Jun 15, 2023

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

@denniskigen
Copy link
Member

@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 () => {
Copy link
Contributor Author

@Jexsie Jexsie Jun 15, 2023

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

@Jexsie Jexsie requested a review from vasharma05 June 15, 2023 18:12
@denniskigen denniskigen changed the title (feat) O3-2177: Update the Patient Banner's show more details sections to match the designs (feat) O3-2177: Tweak the patient banner details section to match designs Jun 21, 2023
Copy link
Member

@denniskigen denniskigen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks, @Jexsie.

@denniskigen denniskigen merged commit ea17f83 into openmrs:main Jun 30, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants