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-1831: Registration: Support person attribute of type Location #1032

Merged

Conversation

usamaidrsk
Copy link
Collaborator

@usamaidrsk usamaidrsk commented Mar 13, 2024

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

This PR add support for person attribute type Location, on patient registration.

test config

{
  "@openmrs/esm-patient-registration-app": {
    "fieldDefinitions": [
      {
        "id": "Health Center",
        "label": "Heath Center",
        "type": "person attribute",
        "uuid": "8d87236c-c2cc-11de-8d13-0010c6dffd0f"
      }
    ],
    "sections": [
      "demographics",
      "contact",
      "relationships",
      "extraInfo"
    ],
    "sectionDefinitions": [
      {
        "id": "extraInfo",
        "name": "Extra info",
        "fields": [
          "Health Center"
        ]
      }
    ]
  }
}

Screenshots

register-location.mp4

Related Issue

O3-1831

Other

@usamaidrsk usamaidrsk closed this Mar 13, 2024
@usamaidrsk usamaidrsk reopened this Mar 18, 2024
@brandones
Copy link
Contributor

@usamaidrsk Seems like this is very close. Can you wrap it up and I'll review?

@brandones brandones changed the title (feat) - O3-1831 Registration: Support person attribute of type Location (feat) O3-1831: Registration: Support person attribute of type Location Jun 21, 2024
@brandones
Copy link
Contributor

Ping @usamaidrsk ? It's still failing CI and still a draft.

@usamaidrsk
Copy link
Collaborator Author

usamaidrsk commented Jul 10, 2024

This work is being blocked by TRUNK-6246
cc @brandones cc @ibacher

@brandones
Copy link
Contributor

@usamaidrsk Looks like the blocking issue has not been resolved, this is still in draft, and CI is failing. Why did you review request me and Ian?

@brandones
Copy link
Contributor

Ping @usamaidrsk , it's been a month...

@brandones
Copy link
Contributor

Ping again, @usamaidrsk

@usamaidrsk
Copy link
Collaborator Author

Ping again, @usamaidrsk

Hi @brandones
I am following up on this PR to be merged.
Thanks cc @mherman22 @ibacher

@usamaidrsk usamaidrsk force-pushed the ft-add-support-of-location-attribute branch from 294d56b to 014ab66 Compare September 23, 2024 06:17
@usamaidrsk usamaidrsk marked this pull request as ready for review September 27, 2024 16:14
@usamaidrsk
Copy link
Collaborator Author

Hello @brandones, this PR is now ready for review
Thanks

packages/esm-patient-registration-app/src/config-schema.ts Outdated Show resolved Hide resolved
packages/esm-patient-registration-app/src/config-schema.ts Outdated Show resolved Hide resolved
Comment on lines +51 to +60
if (locationOptions.find(({ label }) => label === value)) return;
// If the input is a new value, set the search query
setSearchQuery(value);
// Clear the current selected value since the input doesn't match any existing options
setValue(null);
Copy link
Contributor

Choose a reason for hiding this comment

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

I would feel more confident about this if you'd posted a video showing you testing a few cases—starting to type a valid location name, typing nonsense, typing a location name exactly, selecting a location, changing the input text after having selected a location. I think this code makes sense but I don't have 100% confidence in it.

urlSearchParameters.append('_summary', 'data');

if (!debouncedSearchQuery) {
urlSearchParameters.append('_count', '5');
Copy link
Contributor

Choose a reason for hiding this comment

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

The screenshot you posted shows more than 5 locations, with no search query. I guess the screenshot is out of date? Please update it. Ideally with a video.

Also, why such a small number?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have added the video on the description, and for the count being 5, I was trying to eliminate the scroll on the select dropdown, but I can change that to a number you suggest.
Thanks

@brandones
Copy link
Contributor

Thanks @usamaidrsk . The code looks much better, and the video is helpful. Unfortunately the UX seems quite bad, based on your video. You type "out" and "Outpatient clinic" disappears, you see all options disappear, and then nothing comes up, etc.

As a starting point for improving it, I think the list of options should not be cleared until results from the search have been returned by the server. It might also be nice to put a loading spinner on the right side of the input box while new results are loading, to indicate that the user's input to the search input box is being responded to.

@usamaidrsk usamaidrsk force-pushed the ft-add-support-of-location-attribute branch from 7813ad8 to 92637ef Compare October 16, 2024 13:42
@usamaidrsk
Copy link
Collaborator Author

@brandones
Copy link
Contributor

Much better, thanks @usamaidrsk . But having the loading indicator push the dropdown downward creates layout shift, which is a bad UX. Please adjust the loading indicator so that it doesn't create layout shift. Maybe it could float with absolute positioning toward the right side of the input box or something.

@usamaidrsk
Copy link
Collaborator Author

Thanks again @brandones for your feedback on the review.

Please adjust the loading indicator so that it doesn't create layout shift. Maybe it could float with absolute positioning toward the right side of the input box or something.

Regarding the loading indicator, at first I had it as you're suggesting. On desktop, I positioned the indicator on the right side of the input field. However, for tablet view, where the input spans full width, placing the indicator on the right required shrinking the input width while loading and then expanding it back once loading is complete, which seemed not good UX too.

I wanted to let you know about that before I do as suggested.
I would like to hear your thoughts on this again.

Thanks

@ibacher
Copy link
Member

ibacher commented Oct 17, 2024

@usamaidrsk We should be using a Dropdown here which has a skeleton state to indicate that it's loading.

@usamaidrsk
Copy link
Collaborator Author

@usamaidrsk We should be using a Dropdown here which has a skeleton state to indicate that it's loading.

Thanks @ibacher
I believe this might be a slightly different use case. In this scenario, the loading indicator is shown while the user is actively searching/typing. Replacing the entire input with a a skeleton loader could potentially be confusing in this context.

cc @brandones

@ibacher
Copy link
Member

ibacher commented Oct 17, 2024

I see. I'd probably opt for a loading indicator inside the combo box on its right edge.

@usamaidrsk
Copy link
Collaborator Author

I see. I'd probably opt for a loading indicator inside the combo box on its right edge.

Yeah, that sounds good. Could we have done something similar, that I can refer too.
Thanks

@brandones
Copy link
Contributor

@usamaidrsk We haven't, but it's just CSS, should be pretty straightforward. Adding something to the right side of an input box (e.g. an eye icon, an x icon) is a very common thing to do, I'm sure there's plenty of info on Google/SO/etc.

@usamaidrsk
Copy link
Collaborator Author

@usamaidrsk We haven't, but it's just CSS, should be pretty straightforward. Adding something to the right side of an input box (e.g. an eye icon, an x icon) is a very common thing to do, I'm sure there's plenty of info on Google/SO/etc.

Hi @brandones, I have improved it, see this here!
https://github.com/user-attachments/assets/570ed2c3-dbe4-4320-abbd-328e7491eddd

Thanks

@usamaidrsk usamaidrsk force-pushed the ft-add-support-of-location-attribute branch from 92637ef to 83d841b Compare October 22, 2024 16:58
@brandones
Copy link
Contributor

That looks really nice @usamaidrsk , great work. Hopefully the UX reasoning is clear to you, for future work.

Copy link
Contributor

@brandones brandones left a comment

Choose a reason for hiding this comment

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

LGTM

@brandones
Copy link
Contributor

I still think it might be nicer to have a higher limit for the number of locations to load. Feel free to merge this as it is, or to up the limit. Since loading takes so long it might be nice to minimize how many times the user has to wait for that loading to happen in order to find the location they want to select, which I figure would be accomplished by loading a longer list of locations each time.

@brandones
Copy link
Contributor

(please post a video if you do change it)

@usamaidrsk
Copy link
Collaborator Author

(please post a video if you do change it)

I have increased the number of loactions loaded on searching from 5 to 10. Here is the video
https://github.com/user-attachments/assets/89da941a-a4dd-4f9d-a4e9-4d9054b269cf

@brandones
Copy link
Contributor

Yeah I think that makes more sense to me. Thank you @usamaidrsk . And if someone wants to change that number again in the future it's easy enough.

@usamaidrsk
Copy link
Collaborator Author

Hopefully the UX reasoning is clear to you, for future work.

Thanks @brandones , it was great work here!
I will merge this now

@usamaidrsk usamaidrsk merged commit fe14d60 into openmrs:main Oct 22, 2024
6 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
Development

Successfully merging this pull request may close these issues.

4 participants