Appointment Scheduling Refactoring to React

Software Bahmni
, ,
21

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?

22

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.

23

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

24

Hi @jdick,

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

25

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.

26

image
image942×1412 81.7 KB
.

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’.

27

@angshuonline @binduak @vmalini @swetha184

28

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

29

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

30

@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

31

@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
32

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

34

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
35

Hi @snehabagri ,

We are not able to build the project in our local machine. It is throwing version errors. Can you help us in installing the project?

36

@binduak - maybe you / phani can help here