DRY and all these new ReactJS OWAs...

[darius (Darius Jazayeri)]

My recommendation is:

• build two react libraries to be published to npm:
  1. 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
  2. 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.

@mseaton

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?

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