Going in the direction of JS apps we need a new convention for naming repos with js libraries allowing us to share common code. An example of such a library is https://github.com/openmrs/openmrs-contrib-uicommons which I’m intending to split that lib into 2 separate libraries:
with API services like openmrsRest and openmrsTranslate
with UI components (we may split that one even further down the road)
First reaction: I don’t like this. Many of these categories (module, distro, maven, owa, book) imply pretty strongly what technology is being used there. (Contrib is the outlier.) “lib” is just too broad. I’d rather have “js” because that seems like more valuable information to be communicating via the name.
I vote to keep the -js- that Rafal proposes, because it also gives us a place to put “plain JS” libraries that could exist someday. (But I’m fine if we instead go with the convention of openmrs-angularjs-, openmrs-react-, openmrs-js, etc.)
@raff I don’t love calling these things just “api” and “ui” because of the strong implication that these are the primary API and UI forever. (Maybe that’s fine and we won’t have more than one, but I’m just thinking back to the gsp days where we did uilibrary first, and then eventually replaced it with uicommons.)
I think this repos will contain common sources for web apps mainly JS but also It will keep some other web technologies such as HTML and CSS.
In the tech world, Hybrid Web Apps are developed with those web technologies(mainly depend on JS). So for the category naming convention, Why don’t we think about “HybridApps” or HybridWebApps"?
I thought those names will describe the JS libraries perfectly. I referred about Hybrid web Apps from here.
I am new to here, So is it wrong please ignore this reply
@suthagar23, hybrid apps is a term, which I hear often in the context of mobile apps using webview. I haven’t heard of hybrid web apps. Even though js apps may contain html, css, etc., it’s always JS that is used to glue it all together.