Ref App: Patient dashboard's default encounter template always triggered

Tags: #<Tag:0x00007f01bc47f670> #<Tag:0x00007f01bc47f580>

Hi all,

I wanted to design a custom encounter template for the patient dashboard, the one in Core App’s patientdashboard/visits.gsp. The default encounter template’s code that is triggered upon clicking on the button doesn’t check whether it is supposed to be run or not, it just always fills in HTML content into <div class="encounter-summary-container"></div>.

Therefore designing a custom template produces pretty random results. Sometimes the custom template is triggered last and the expected behaviour is observed, sometimes it is triggered first and the default behaviour is observed.

I guess this is a bug, and I tried to work around it by either changing, in my custom template, the id of the surrounding element (id="encounter-summary{{- encounter.encounterId }}") or the class of the container element (class="encounter-summary-container"). Of course I adapt my JS code accordingly, to no avail though, and I am not sure why, but when doing so nothing happens anymore: ‘show details’ becomes ‘hide details’ but no content shows up (default or custom).

Could anyone either help me make the workaround work or provide any guidance as to how to do this right? If the bug is indeed one, I am happy to pull request the fix… etc.

Thanks.

Do you have an example that i can build to test and reproduce this?

Well, to get moving I made the change in our own fork of Core Apps. It would definitely make our lives easier if this could make a valid pull request, would you be ok?

I guess it depends on how different the custom template is from the default one. In my case, I only want to change the inner HTML of the encounter summary but I would also like to keep all the rest (the decoration with time stamps… etc). So to reproduce the issue, just create a custom template as a copy of the default (GSP + JS), tweak the encounter summary a little, and you will see that one template overrides the other in an unpredictable order.

My point is that the default template wakes up and attempts to change the DOM even though it is not its turn. Should the target ‘CSS selected’ elements exist, they will be touched by it. As a workaround I simply wanted to change the target id and class names, but that would just not work at all, and I’m not sure why (see my first post).

I figured out the ‘workaround’ mentioned in my first post. I repeat again for those attempting a similar effort that I started from a copy of the default encounter template. See below what I had to do on the view side and the controller side of my custom template:

1. The GSP (HTML & CSS)

The key was to change the class of the element that is used to capture the clicks and thus that performs the toggle between ‘show details’ and ‘hide details’. This class should be renamed, ideally to something unique. So for example we go from

<a class="view-details collapsed" ...

to

<a class="mk3s-view-details collapsed" ...

But then of course Core App’s styling is screwed, so we need to bring on it the exact same styles that are in patientdashboard/patientDashboard.css:

#encountersList .encounter-details .mk3s-view-details {
  background: #f9f9f9;
}
#encountersList .encounter-details .mk3s-view-details .hide-details {
  display: none;
}
#encountersList .encounter-details .mk3s-view-details:not(.collapsed) .hide-details {
  display: inline;
}
#encountersList .encounter-details .mk3s-view-details:not(.collapsed) .show-details {
  display: none;
}
#encountersList .encounter-details .mk3s-view-details:not(.collapsed) .icon-caret-right {
  -moz-transform: rotate(90deg);
  -webkit-transform: rotate(90deg);
  -o-transform: rotate(90deg);
  -ms-transform: rotate(90deg);
  transform: rotate(90deg);
  -moz-transition-property: all;
  -webkit-transition-property: all;
  -o-transition-property: all;
  transition-property: all;
  -moz-transition-duration: 0.15s;
  -webkit-transition-duration: 0.15s;
  -o-transition-duration: 0.15s;
  transition-duration: 0.15s;
  -moz-transition-timing-function: ease-in-out;
  -webkit-transition-timing-function: ease-in-out;
  -o-transition-timing-function: ease-in-out;
  transition-timing-function: ease-in-out;
}
#encountersList .encounter-details .mk3s-view-details i {
  font-size: 1.2em;
  padding: 0;
  position: relative;
  top: 1px;
  left: -3px;
}
#encountersList .encounter-details .mk3s-view-details:hover {
  text-decoration: none;
}

2. The JavaScript

And obviously the JavaScript code must capture the click event based on the new new class name:

$(document).on('click','.mk3s-view-details.collapsed', function(event) { ...