Appointment Scheduling Refactoring to React

Tags: #<Tag:0x00007fe2df04ea60> #<Tag:0x00007fe2df04e998> #<Tag:0x00007fe2df04e8d0>

@snehabagri what are we talking about here, the project for the new appointment scheduling UI?

Will this be an ES6 module then, how are we settling this in regards to the microfrontends effort?

Hi @mksd

Yes, this would be ES6 based.

We are going to have discussions with Angshu, to see how we can be more aligned towards micro-frontend architecture. We might not go ahead and do that immediately, instead have a more aligned design to move towards it subsequently.

I would therefore add a new openmrs-esm-appointments under /openmrs and have it part of the MF offer.

The module is very specific to Bahmni, as the backend api consumed sits only in Bahmni.

Surely there will be a JS API layer to consume the appointments-specific REST endpoints?

While the Java backends are duplicated, can we not unify things through one JS API layer? That one would consume both OpenMRS’ Appointments Scheduling REST API and Bahmni’s Appointments REST API.

That would mean we need to have similar kind of data getting stored for OpenMRS and Bahmni, which is not the case today I guess.

What rather needs to be aligned is the way this JS API layer to come is producing results to be sent to the UI components.

Yes, we will keep the JS API layer as an abstracted layer, which can be substituted with something new at a later point, will that make sense?

Without a common model, its is impossible to do that. In the MF squad we have been discussing this, and thats why you would have seen lots of discussions on adopting FHIR. However, thats unlikely to happen anytime soon (actually forseeable future). Also, the MF squad is not really thinking of “shared” code at component level. We are targeting app/feature level to start with.

I would like to also voice support to consider figuring out how we might integrate this into the MF architecture. There are currently a number of organizations looking to build a new appointment manager. The MF architecture has the potential to create one feature and share it across all implementations.

@angshuonline, is it possible to imagine moving the bahmni backend dependency into something more generic to openmrs? I also don’t think we should rule out considering adding support to the FHIR module for appointments and then relying on that as the api of preference. It’s less work than one might think to add the fhir functionality to the openmrs fhir module. Moreover, if we agreed on a common representation, it should be possible to build a single ui that consumes that data.

@snehabagri, from your early posts (you will be moving people on and off this project and finish it in phases) it seems there may be some leeway to use this a model project to advance a common architecture across openmrs. Though I’m sure other opportunities will arise, this has great potential to be a unifying force within our community.

Thanks,

JJ

Hi @jdick,

I am scared until the backends are similar we will be able to achieve that.

Just want to +1 this approach to MF architecture + FHIR as the common model linking the backends. It would be great to see if we can make this approach work here.

.

We would like to call the new repository as ’ * openmrs-module-appointment-frontend’.

We would be moving all the code required for appointment scheduling in bahmniapps - common, to a new node module called ’ * bahmni-common-ng’.

Any components that we foresee as a common react component, which can be used across modules will be added to ’ * bahmni-common-react’.

@angshuonline @binduak @vmalini @swetha184

In case we do not have any concerns, as a first step I will go ahead and create the ‘openmrs-module-appointment-frontend’ repo and start moving appointment scheduling code to it.

@angshuonline @binduak @swetha184

Thanks @snehabagri - it will be good to bring it up on today’s PAT call.

@snehabagri Do you mean you will not be able to achieve what @jdick is proposing because the backends are not the same or ??? I did not understand your statement above.

Also I would like to encourage your team to consider the proposals made by @jdick and @mseaton to explore how their suggestion would work, given that it has such a huge impact factor for other implementations who are reworking the appointment scheduler as well.

I would be happy to schedule a Design Forum to discuss this ASAP to finalize and conclude on the way forward if it will help bring final consensus, or I could join your upcoming PAT call to better understand how we create that synergy between the various efforts.

What time is the PAT call?

@angshuonline

@c.antwi I think discussing this on the design call would be appropriate. However, if you can join Bahmni PAT call today, we can give you an update on the difference between the 2 modules. Its not just technology, its also the approach that is different between OpenMRS appt scheduling and Bahmni’s. This would also provide you context, why Bahmni decided to go with a different approach. (although if you search in talk, you will find enough materials, User research, including technical threads)

I would like to get an understanding of how many existing implementations (and orgs) are using the OpenMRS appointment scheduling and broadly what feedback they had.

In the other thread, I don’t think there was a discussion over features / approaches for making a decision. We can share our past user research, their feedbacks and requirements if this would clear up things.

Look forward to your participation in PAT call.

1 Like

Thanks so much @angshuonline I will be at the PAT call this afternoon.

Hi,

The new react piece of code will have styles written as below:

  • SCSS (preprocessor)

    1. Will have a common file to define all common properties like primary color, secondary color, font type etc. We can use css var to define constants in this common properties file eg:
    $primary-color:  var(--primary-color); //using css var
    
    :root {
        --primary-color:  #61dafb; //css var
      }
    
    1. Each component will have their own scss files for styles. Things like width, height of component like button will be constants and will be defined inside style of these components
  • CSS Modules (To ensure class names are unique)

@angshuonline @binduak Let me know any concerns/suggestions.

2 Likes