Appointment Scheduling Refactoring to React

Software Bahmni
, ,
1

Hi,

We would be working on the ui enhancement for appointment scheduling as mentioned in the talk Enhancements to the UI for Appointment Scheduling, we would like to use this opportunity to upscale ourselves to move away from angular js to react. Angular JS is no more supported by the community, so we would like to move to a more vastly used library react.

This would also help us have a working example of migrating other modules in bahmniapps to react, making the code less cluttered and easier to understand. To achieve this we are proposing a coexistence model.

The path and estimate (approx) required to achieve the same is mentioned in the document attached.Appointment Scheduling Refactoring to React - Google Docs.pdf (78.4 KB)

Do let us know your inputs/suggestions/concerns

@angshuonline @mksrom @binduak @sravya @vmalini

3 Likes
2

I think in general I agree, however I do think there are couple of concerns mixed up.

  1. making Bahmni App Scheduling modular - separately managed codebases, independent deployable unit, refactoring and curving out dependencies
  2. Convert existing Appt Scheduling to React app gradually

My advise would be to keep these 2 separate and target for completion of Part 1 first. Part 1, has nothing to do with React. I do have concerns if you are somehow underestimating this effort. Its not about simply taking bahmni-common part of bahmniapps out - that itself can be extremely dangerous and require a fair amount of work all through the application codebase. This would also require splitting server-side apis codebase. Otherwise, if for a particular feature (e.g. appt), you are required to bring in all other dependencies on the server side. We have been doing some spikes and experiments, and we can share our findings and thought process/ideas.

For the React part, I did not see a path/approach articulated to migration of the existing features/codebases. The attached document mentions routing, buttons, searches, selectors moved to react - but not for the whole features or significant portions. Can you provide some thoughts, if you plan to incrementally move the entire appointments feature to React and over what time?

Mixing two very different frameworks, increases maintenance and also complexity, as with mixed paradigms. In addition, not to say increase in dependencies - Redux or additional libraries. I would like to hear if you have considered other aspects like

  • Performance (with angular+react combined) and weights.
  • Forms 2.0 already brings in React (as a whole substitution of a feature). That version is 15.6. I would assume you would latest React version, - does that mean you would you be helping us to migrate to the newer React, say 16.9?

Additionally, I think, its is also a great opportunity to align with the new microfrontend architecture envisaged for OpenMRS ecosystem. Which might mean, conforming to new standards/specs of single-spa application, using import maps, dynamic loading, resolving imports, tests, webpack based builds - tons of work! I think working in a mixed mode technology (within the same feature) altogether, while making such wide-scale refactoring is quite dangerous.

IMHO, even if you achieve part 1, that would be something significant and providing you the flexibility of doing further incremental enhancements.

attn: @mksd @mksrom @arjun @joeldenning

3

I would vote against investing any precious and scarce resources in moving a stable and well working bahmni appointment scheduling module from angular to react. I would rather look for ways of adding new features in react but without touching existing ones, just for the sake of switching to another framework. Though the OpenMRS Community is investing more in react than angular, the fact remains that angular is still heavily used and supported else where, that i would not be scared to the point of redoing things in another framework. Moreover a JavaScript framework (I guess you know what i mean by this. :slight_smile: )

By the way, i like react more than angular. :smile:

4

I know what you mean! (and I too like React)

5

@snehabagri @angshuonline, a “coexistence model” is exactly what the MF Squad is working on right?

Reading through this quickly hints that this project looks like the perfect opportunity to make Bahmni step into single-spa. We have to start somewhere.

1 Like
6

Hi @dkayiwa,

I agree it would be always a good idea to invest on a new feature, as we have to make UI changes to the existing appointment scheduling as it is not very appealing today. So we are proposing a refactor + redesign.

We are trying to move anyway from AngularJS, we could either upgrade to Angular/React. Given React overall has more likeness and more people have adopted it, so we choose React. We also have existing repo’s in Bahmni on React. Also if OpenMRS is making more investments on React, it will be easier for people to contribute.

At the same time, the idea to move to a new tech stack is just not rewriting a piece of code, as mentioned already we will be making significant changes to the UI, so instead of doing it on a big monolithic codebase, we want to move it to a more modular code.

7

Hi @angshuonline,

You are right, we have 2 parts to the problem.

  1. Making it modular
  2. Refactoring to a new tech stack.

To make it modular, we are proposing to bundle the existing code in bahmni-common as a single js and html bundle and include that as a dependency. Which does not seem difficult, with the working POC we have. The important part is that, this new bundled code will just be used by appointment scheduling, so we will bundle the dependency required by Appointment Scheduling alone.

Once we have bundled and moved out the common code, we can include all the other dependency as npm packages.

At the same time, we would like to understand the difficulties you have faced, to ensure we did not miss on anything significant.

I think we should keep the server side and frontend side splitting as 2 different concerns, as that will itself be a big chunk to redesign and refactor. And we do not want to combine server side and frontend refactoring.

Also, we are looking to do the Part 2 along with Part 1, because we are going to make an investment towards redesigning the UI, so instead of investing in an old piece of code, we want to do it the new design on React.

“For the React part, I did not see a path/approach articulated to migration of the existing features/codebases” -> I would like to understand what other details are you seeking, the document has a mention of the timeline.

Angular and react both being JS framework, I do not foresee any significant performance bottle neck. The react components would anyways get complied to angular components/directive, until the majority of code is in Angular JS.

Form Builder codebase is like a separate module as compared to appointment scheduling, as no point in time we will end up loading 2 versions of react on the browser, as these modules are not interlinked in anyways. So, it would not be a technical concern, to upgrade form-builder first and then migrate appointment scheduling.

We should understand the how we be more aligned to the micro-frontend architecture while performing this refactoring. Though, we would like to do that migration at a later point.

1 Like
8

Yes @mksd,

That is the same idea, we have in mind.

9

I would suggest not doing a random “take-all” and make a “bahmni-common.js” bundle. I would rather take this opportunity to understand whats the dependency and how can we better manage this. And I would start small, with just whats required for appt app to work.

Doing this, will also require our existing app codebase will have to be upgraded for all imports - js, html, etc.

We can talk about this in detail - in short, I would not advise a “mud-ball” bundle creation. I would take this opportunity to set up the patterns right - rather than hoping someone in future is going to again do refactoring to fix this!

What is covered as part of the estimate?

  • are you going to rewrite the complete app UI, or only part of it?
  • if you are going to do only part of it, do you have a plan of incrementally moving the rest to react? The core team does not have capacity of doing other bits of migration. If you plan to do this, can you give us an idea of timeframe?
  • if not, is this the best utilisation to do just one small part in React?

I was enquiring about the entire appointment scheduling app. The document does not reflect that. In brief, I would like to know if you have a gradual path of moving to react, ensuring that we do not leave it “partially” done! - a cost of maintenance for the Product.

We do not want to be in a position where multiple version of the same library is part of the product. This is maintenance cost again.

We wouldnt use Angular 6 in some part, angular 2 in another part - right? Regarding performance, what would be the total downloads size and would that effect a cloud hosted env?

10

Yes, that is the same thing we are proposing, we will bundle the dependency that appt scheduling requires, not everything. We will slowly stop consuming the services, helpers and directives from this bundled code and would write it on the new tech stack. We have already done a small POC around it.

  • It will be a coexistence model, vs a big bang refactor and we can gradually migrate the entire UI.
  • The attached document has the stories and timeline mentioned.
  • If you need as exact break down of what part of the UI gets refactored first, and what gets refactored later, we can provide that list.

We need to talk about this, I want to understand what are the missing parts and update the document accordingly.

11

Not looking for very correct estimation/sizing, but I am trying to get an idea of what would be be left to be done after your projected work.

  1. What % of the existing feature would you be migrating?
  2. What would be the rough effort for the rest to move to react?
  3. Do you have an idea, beyond your current projections, the timeframe over which such refactoring and movement can be done on your project?
12
  1. 50% of the major impacting features we are covering.
  2. The attached document above has all the estimates, it might take 2-3 months with 1 developer working on the remaining part of it.
  3. We are going to work on it in phases, and it also depends on other things that we will be working on, so it is difficult comment on this.
13

Should we go ahead and create a new repository for this on Bahmni, so that we can start raising the PR’s as and when we finish the listed stories?

@angshuonline @mksd @mksrom @binduak @arjun @bharatak

14

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

15

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.

16

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

17

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

18

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.

19

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.

20

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.