A couple of us at PIH have been poking around at the new dashboard widgets added to coreapps. They look pretty cool so far, and I wanted to thank @raff and the Soldevelo and all the others in who worked on it. It’s great to see new features being added to the Ref App, and we here at PIH may be taking advantage of some of them in the near future. We also may be looking to make our own contributions–in particular, we may add some new features to the relationships widget, and we also need to add a programs widget, so it seems reasonable to use try to follow the same pattern as the other widgets.
I’m relatively inexperienced with some of the technologies here, so was trying to track down how everything worked. I noticed that “openmrs-contrib-uicommons.min.bundle.js” package that is included in coreapps, and which appears to contain functionality such as the “openmrsRest” service referenced in the various controllers of the the widgets. I assumed there would be a “openmrs-contrib-uicommons” module in github under OpenMRS, but didn’t find anything. I eventually tracked it down here:
It looks cools and well-documented, and I’m looking forward to working with it, but is there any reason that it’s not under the openmrs repo?
Looking at a post from a year ago, it appears that the consensus was not to put in under OpenMRS, but I’m not 100% sure I understand the reasoning (Releasing openmrs-contrib-uicommons to npm). (I have to spend some time today reading up on the NPM release process
If not, it’s location should at least be promoted/advertised better. It seems like a very valuable addition, and I’d hate to have people not figure out where it lives or how it works and decide to rebuild the wheel instead.
Paweł had the project under his account to lead efforts to improve it and do releases. @gutkowski, are you still interested/have time to support the project or shall we continue working on it under the openmrs account?
+1 to moving this to the openmrs repository. I understand the distributed nature of github, but our general historical practice is to put components like this (eg. those that make up the reference application framework) under OpenMRS. As @mogoodrich indicates, this is where we all expect to look, and this is where others will be able to most easily contribute to it. @SolDevelo, thoughts on this?
Continuing the discussion, I had a chance to start working with openmrs-contrib-uicommons today and the dashboard widgets that have been created using the library, as I start building a new “programs” widget, and it’s been a pleasurable experience so far, so thanks again to everyone who has worked on these components.
But it does raise the issue of how to contribute back to the module. I currently need to add a datepicker and a dialog to my widget so my questions would be:
Do these exist yet in openmrs-contrib-uicommons (I see an alert widget, but I new a dialog for data-entry)?
If not, do people think they would be valuable features to add to openmrs-contrib-uicommons?
And, if so, I’m willing to work on this, have we established a process yet to do so?
@mogoodrich, thanks for feedback! We do not have a dialog or a datepicker component yet and yes, they would be valuable additions. Let me exercise the process of contributing to the project again and write it down in the README file. I will do this by Monday.
I’d also like to exercise migrating one of components to Angular 2.x to make sure there’s an easy path to do it when the time for a switch comes.
We also need to modify the packaging of the library so it is possible to build a bundle without Angular, because right now the produced js file has Angular in it. As far as I know a library like ours should produce a bundle without external (vendor) dependencies and another one with vendor dependencies only.
I’ll also go ahead and fork the project into the OpenMRS account to promote it better and open up for contributions from the community.
Have you read this article. It’s a great recipe for migrating from Angular 1.x to 2.x one small step at a time, primarily by adopting best practice conventions in 1.x.
If you want to migrate a repository under OpenMRS in GitHub, then I believe transferring is preferable over forking, since it will automatically redirect old URLs to the new location.
The more documentation the better… even if pointing to good online articles to read on the various technologies we are using such as webpack… I have to read up!
One thing I was thinking of–after I create new widgets, I’ll probably be needing to make tweaks to them as I implement them in coreapps, so it would be good to have a workflow for this. For instance, right now is the process:
Release new openmrs-contrib-uicommons to NPM
Pull that new release into coreapps and use it
If so, is there a simple process to run my local version of coreapps off a “snapshot” of “contrib-uicommons” while I’m working on both? (Maybe there’s an easy answer to this, and it will become apparent to me once I get up to speed on the technlogies, but figured I’d ask now…
I’d agreed that it’s probably not worth spending too much time migrating to Angular 2 at this point, but if I understand correctly I think @raff is just suggesting setting a pattern for developing new widgets in Angular 1 in such a way that they are compatible with Angular 2.
I’ve tried to transfer repository, but as long as fork created by @raff exists, I am blocked. Could somebody authorized please delete this repository so I can proceed with ownership transfer?
Thanks @raff! repo has been transfered. GitHub wanted me to configure team access for this repo, I’ve given permissions to dev/5 group, you may want to modify this configuration.
I’m sorry, but it seems that after transfer I can’t change any settings. Form displayed by GitHub didn’t state what permissions are being assigned. It seems I wasn’t able to assign admin rights during transfer.
Unfortunately, we do not yet use npm for widgets in coreapps so you need to manually copy the resulting min.js bundle into coreapps. I plan to fix that as explained in the other thread you started:
