Thinking of component reusability across toolkit

dev

(Ivange Larry) #1

Hi all

I am proposing to start a sprint to break down radiology ui into individual webcomponents using Polymer and here are my reasons

  1. The new Radiology UI is an Angular 2 app. Angular 2 is completely component based but the problem is that angular is a framework(I didn’t see this as a problem at the time). The components built in the radiology owa are easily reusable within the radiology owa itself but to make it available to other OWAs may need a little effort and I’m guessing any other owa that will need to make use of any of these components should also be an angular 2 app. I think that makes reusability an issue.

  2. We’ve been experiencing a lot of problems deploying this on toolkit but it’s working fine on openmrs for me though a lot have complained they get the same problems even openmrs. This is mostly due to how angular 2 handles it’s routing. There are things the owa module did not anticipate and a lot of changes may need to be made to the app before deploying it. I had to learn Angular 2 while building this app so I’m no expert in angular.

  3. Getting new contributors to contribute on the frontend takes a lot of effort as the openmrs sdk/owa-generator have no support for Angular 2 yet. Hence, when developing we don’t get live reloads. We literally have have to build, package and redeploy on every single change.

  4. This won’t be much work as it seems. We’ll mostly be doing copy past since we already have the html and css code inside radiology.

  5. Seems webcomponents has properly been tested(not by me) to have no issues with toolkit and owa

How I think this should be done

  • Look at angular components in the radiology app and make individual polymer components from them. These don’t have to be a complete owa. An owa is a complete app and some components won’t make sense as an owa. For example, making the navigation component an owa doesn’t make much sense. People should not install an owa just to see a navigation. But anyone building an owa should be able to easily use this component just like using an external library.

  • Each component should have it’s own repository or be a child repository of a custom webcomponents repository e.g

  • Have a distribution plan for how different OWAs will share these components. We could have a single owa like owa-uicommons that will be like a library with all librehealth supported custom components and an admin page that will show developers available components that they may take advantage of. Or we could publish these components to a public repository and have developers add them to their project when they need them.

  • Have a new radiology-ui that will just make use of these new components. The community should decide on wether they’ll still want to use a framework(note: angular 2 is not supported yet by the sdk hence rapid development may still be an issue) or just be as simple as html+javascript with jquery for server communication.

I am hoping I can get as much input from the community on this. It get’s boring having to do the same thing over and over again. Like I said making this change may not be much work since the radiology-ui is still in it’s early stage.


(Robby O'Connor) #2

A good chunk of work can be done during Code-In.


(Judy Gichoya) #3

Why don’t we try this approach using GCI

The tasks are pretty sine and we can have a good idea where this works or doesn’t


(Robby O'Connor) #4

Have we thought about how we want the system to look? That should drive what components we need…not randomness.