Datepicker, and Ref App widgets/styling going forward?

I wanted to start a discussion about what our strategy going forward is for developing reusable components for the Ref App, and, in particular, what datepicker we want to use, as that is an issue I am currently facing.

To add programs support to the Ref App, I’ve created to program-related widgets and made them part of the new “dashboard widgets” that we’ve set up in coreapps using webpack, which use the new “openmrs/angularjs-openmrs-api” package.

It was pretty good to work which, and inline with heading towards more client-side angularjs model, interacting with the backend via the REST module. However, I got a little stymied when trying to add a datepicker to the widgets–obviously a common need within OpenMRS.

Previously, when using the UI Framework, I’d use the datepicker widget provided by the uicommons module, which uses an older version of the bootstrap datepicker. Of course, using a UI Framework gsp wasn’t an option within this new widget, so I shifted to the angularui bootstrap datepicker:

https://angular-ui.github.io/bootstrap/

(To be honest with you, I’m a little confused with the history and relationship between all these bootstrap datepickers that are out there).

I got this new datepicker to work perfectly, and using code that seemed consistent with the model laid out within the other dashboard widgets (it works using pure angular, no need to add jquery code to the html template), but there’s a couple issues:

  • When we include the bootstrap 3 style sheet via webpack, it screws up some of the other styles on the page. I thought there’d be a built-in way to encapsulate the bootstrap styles, but, although there some semi-hacky suggestions, there doesn’t seem to be a “proper” way to do it.

  • We need to add localization support for the datepicker. (this may be straightforward, I haven’t looked into it in detail because I got stuck on the previous issue)

So, I guess my questions are:

  • Functionally, do we have a preference of what datepicker we use within OpenMRS going forward?
  • Technically, do we have a preference, and do we have a technical strategy for using that datepicker?
  • Are we planning standardizing on bootstrap for styling going forward (I believe @ssmusoke was talking about this in the past), in which case we could use just angular ui bootstrap datepicker and spend the time modifying our existing styles to integrate properly with bootstrap?

I admit there’s some frustration on my part here–although I agree that moving away from the UI Framework towards a client-side / REST approach makes sense, it feels like we don’t have a clear direction here, and it’s been frustrating to fight for a couple days with something as simple as adding a datepicker to page, something I could do in about 10 minutes using the UI Framework. Admittedly, some of the slowdown is my very limited knowledge of some of these new technologies like webpack.

Thoughts?

Thanks and take care! Mark

Previous thread, if anyone is interested in the more details in the specific issues I was facing:

copying my opinion from another thread…