O3: Autocomplete Component (searchable dropdown)

Development
, , ,
1

@sinte from @ICAPEthiopia has been working the last 3 days on the Address Hierarchy component for O3. It’s getting close!

We want the address fields to be searchable with typing, but Carbon does not support auto-complete behaviors in a dropdown field UI. For now @sinte has started an Autocomplete Component (component class) to handle this. But we wanted to see what others have done.

@dkibet I believe you implemented this for Ampath Forms. Would that approach extend to a component/widget, or is it limited to in-form display?

I did just see this one: How to make Class autocomplete and allowaddmore But I imagine it’s not applicable directly to O3?

CC @mksd @zacbutko @bistenes

2

Hi @grace and @sinte , are you maybe looking for ComboBox? This would allow users to type to search for a member of a list. For address this could be used to select country, state, etc.

Screen Shot 2022-05-13 at 3.53.53 PM
Screen Shot 2022-05-13 at 3.53.53 PM868×694 26.4 KB

Does this fit your needs or are you looking for something else?

3 Likes
3

Hay @zacbutko thanks for your kind reply. ComboBox works for pre-defined values but in our case it’s different we need to search and get our values from API as soon as the user types a key. we need a text box with autocomplete feature. I sow its not implemented in Carbo UI and users are requesting this feature Implement auto-complete textfield allowing for selection of existing value (like ComboBox) or specifying a new value · Issue #1605 · carbon-design-system/carbon · GitHub

2 Likes
4

@sinte I see. Would it work to use ComboBox as a base component and refresh the options with api results?

The article you reference mentions how this is working already in MaterialUI. Looking at MUI now it seems like they also are using ComboBox for their Autocomplete Search. I think same behavior can be achieved with Carbon.

5

Thanks, @zacbutko, and @grace for your help I have successfully implemented ComboBox as a base component and refreshing values from API workes for me image

3 Likes
6

It has also cascading functionality from ComboBox to ComboBox and is very important to implement address hierarchy feature

1 Like
7

@sinte , looks great! Can’t wait to try it out. Will you be able to show your work at the Frontend Squad call next week?

8

Woohooooo!! Nice job @sinte!!! Can you share a link to the repo or pr for this? Or is there anything you need from the OpenMRS GitHub org to get you a community repo for this?

Many folks around the world are going to be excited to use this :cowboy_hat_face:

9

yes, we can do that I need also some idea to put it on the registration page and save the data

10

Yes, actually It is in ethiori repo with a new branch GitHub - CDC-HIS/openmrs-esm-ethiohri at address_hirarchi_component but yes I need a community repo to integrate my job, a slot on the registration page and maybe a setting to modify names.

1 Like
11

@sinte well done. Maybe @samuel34 or @pirupius can help you with that

12

Thanks @eudson I will communicate with them

13

Update: A large org in Rwanda is very very interested in using this feature as well :slight_smile: So @zacbutko maybe you and I can unblock Sinte promptly - could you create an openmrs/esm-… repo for him for this?

14

@samuel34 & @pirupius can you please confirm if you can create the slot in the esm-registration-app for Sinte? Otherwise please ping @zacbutko ASAP so we can keep this moving :slight_smile:

15

@zacbutko the work done on the address hierarchy widget has reached a point where we need to add it to the registration page but there are already existing address fields on that page so adding a slot will just cause duplication. Should we consider removing the current address fields completely in favour of the new widget?

1 Like
16

FWIW @pirupius I agree with this approach - IMHO the new widget should be the way forward at least for the RefApp. :slight_smile: