I was randomly looking at one of the new OWAs that an Andela team is working on. Not to pick on this one in particular, but I have two concerns:
OWAs should be able to run with just the basic OpenMRS platform, and they should never require the uiframework module, and preferably not the uicommons module. (I wonder if this existing work can be used as a starting point.)
Can we do something today that prevents us from having every new OWA replicate the header? This stuff needs to live in some npm-hosted shared library which can be included into the React application.
@dkayiwa, @Andela is this something that some team can prioritize? (or has it already been addressed?)
I also encountered this problem for some other reasons.
OWA needs the reference application style files. Previously I have fetched that library and attached into lib folder of the OWA. Then I removed it from the lib folder and linked it from the uicommons module,
Can we do something today that prevents us from having every new OWA replicate the header? This stuff needs to live in some npm-hosted shared library which can be included into the React application.
I agree with you. Why don’t we create a common style library for OWAs including this required tags?
Can we do something today that prevents us from having every new OWA replicate the header? This stuff needs to live in some npm-hosted shared library which can be included into the React application.
This makes perfect sense. The current andela team will like to take this up. However, we request some more clarity on how this could be done. Here are the options we are considering
Making the header into an npm package. This would require anyone designing pages that requires the header to install the npm package and supply some props to it for customisation
Build a react version of the uicommons module. The existing uicommons module generates angular components, one approach will be to create a react version of this implementation.
Looking forward to what the community has to say about these options and perhaps more clarity on what we really seek to achieve
cc @Andela@dkayiwa
Making the header into an npm package. This would require anyone designing pages that requires the header to install the npm package and supply some props to it for customisation
AFAIK, the header is not only expected here, we can think more about it like the ui-commons for angular
Header part
Breadcrumbs
Common table format
Sample Tap content
Sample form content
Sample dialog boxes, alert, and notifications
Common CSS Styles for further UI development like the reference application
Build a react version of the uicommons module. The existing uicommons module generates angular components, one approach will be to create a react version of this implementation.
This makes sense for me. We can think about building a separate ui-commons module for ReactJS based OWAs. It should export these components and should support for initial customizations. Then we can include this module through the npm and can link with our regular ReactJS based OWAs.
Anyway, thoughts of other community members also welcome
web-style-referenceapplication is pure styling (scss/css) and has no components, whereas contrib-uicommons has AngularJS (1.x) specific components like header, breadcrumbs, etc. The goal was to make contrib-uicommons depend on web-style-referenceapplication.
I’d recommend to use web-style-referenceapplication when building react components.
Sorry if this is a dumb question, but I’d love to hear from the Javascript gurus and learn if the state of Javascript today is such that we do really need to re-invent / re-write every component, every time we decide we want to leverage a new major framework.
Is it possible to take an existing investment in Angular components, and use them within React code (in an OWA or otherwise), or to take React components and to use them within existing Angular code? Is there some way we could write this header component, for example, such that we could maintain one version that is used across the application, regardless of whether a particular page is built with Angular or React?
A quick google search brings up libraries like react2angular and angular2react. Are there efforts like these that are worth investigating and pursuing?
After long experience investing in various Javascript and other UI frameworks for OpenMRS that are now being replaced, it would be great to know that investments today in React and Angular can build upon each other, and that they can work with whatever new great framework inevitably comes along to replace them soon.
openmrs-web-reactcomponents: contains lower-level components (autocomplete, formatted table, tabs); only build these components as-needed, i.e. don’t replicate the entire style guide
openmrs-web-reactrefappcomponents: depends on (1) and the web-style-referenceapplication and it implements the higher-level shared code that’s more specific to the Reference Application look and feel, like the header
If it’s too much of a pain to separate this way, I can live with those being a single library.
keep in mind that we want to modify the style guide to be based on bootstrap 4’s CSS, and to make the design responsive. I’m not sure if there’s anything actionable about this for you now, but eventually it points to us refactoring openmrs-web-style-referenceapplication.
I’m not a JS guru, but I’ll try to answer this…
It’s possible to combine frameworks together in some interesting ways. e.g. Bahmni’s new forms engine is built in React but it’s included in the existing Angular 1.x UI using ngReact.
But our existing investment in Angular is in Angular 1.x, and things have moved beyond this now. Further, our real big investment is actually in an unholy mess of server-side gsp, Angular 1.x, with some knockout and underscore templates. Adding to this mix seems like a mistake to me.
While it’s true that every few years another better JS framework comes along and catches people’s attention, the reason it’s better tends to be that it takes a different approach and allows a new and different style of writing code. So, trying to mix this in with an older framework tends to negate these advantages. Also “every few years” is not actually that often, and as long as we’re only rewriting a bunch of stuff once per framework, it doesn’t bother me very much.
So, as long as we have this…
good REST endpoints that we continually improve
a single shared CSS library that’s independent of any particular JS framework
only one shared library for most things in Angular 1.x, only one for React, only one for Angular 2+, etc
one standard approach for things like i18n within each framework
a reference application that’s built around the idea that each “app” can be written in a different tech stack, but they can link seamlessly together (with the cost of having to do a page load if you move from a GSP screen to an Angular screen, to a React screen)
…then I think this is the best balance we can have between reusability and the ability to take advantage of new things.
(Ultimately, though, I believe that supporting new approaches without requiring every new dev who shows up to understand a bulky, non-standard, tech stack rich in “historical artifacts” means that new devs will be able to show up and be productive faster. And if this means that an Andela team can come along and built an order entry feature (in React) in few months, which we never actually got done in the old way, then that’s an argument for prioritizing the new ways.)
One thing I would consider is building the header (including breadcrumbs) and the footer with plain jQuery, which is compatible with angular, react and other frameworks. That way we do not have to maintain these simple elements for every framework rather have them easily included with (almost) pure JS in every app. It would make it also much easier to overwrite these elements for a specific implementation to add branding or additional features like location selection for the whole system.
The project simply contains scss files, which are transpiled to css files (referenceapplication style guide) and resources (fonts/icons/images). I can release it to npm next week and add some info on how to import and use in any js project. It’s actually published at @openmrs/style-referenceapplication - npm already. If I have extra time, I’ll migrate openmrs-contrib-uicommons to use it, which should be straightforward.
This is an interesting idea, but I fear these wouldn’t participate correctly with Angular scope or React state.
I think I’m okay with removing any state-affecting behavior from the header to mitigate this, e.g. we currently allow you to change the session location without reloading the page.
Can we use the callback functions(instead of building the actual plain jQuery functions) in the header for the events? then we can simply integrate those header click events from Angular or ReactJS.
I should further say: I think this is interesting, and I hope that someone pursues it at some point, but it takes us yet one step further away from actually building an app. So, I would recommend that the current Andela team working on the order entry app only go as far as making a reusable React library.
fyi, I created a “openmrs-contrib-reactcomponents” project in github and have begun to work on it:
Currently there is nothing in it except for a “Hello World” heading, but I plan to start building a reusable Ref App header by extracting some of the code int he Order Entry UI module.
Note that instead of creating two projects, “reactrefappcomponents” and “reactcomponents” I started with just a single project to keep things simple. (“reactrefappcomponents” is a bit of a mouthful as well). I put the header in a “refapp” subdirectory for now. I’ll continue to refactor as things get more complicated and I get a better sense of where things should live, but feel free to start weighing in now on structure… and feel free to start contributing as well!
Nice work @mogoodrich. The current Andela team on OrderEntry OWA project have thinking along this line since we had to (re)implement the app header, patient dashboard and a couple of other components ourself. I (and hopefully, my other team members) will be on the look out for how we can help. Thanks
