(feat) O3-3276: Add support for printing patient identification stickers

[jnsereko]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• My work includes tests or is validated by existing tests.

Summary

Print a sticker at the registration desk with basic patient information like Patient ID, First name, last name, age, gender.

Screenshots

Screen.Recording.2024-05-23.at.13.06.11.mov

Related Issue

https://openmrs.atlassian.net/browse/O3-3276

Other

cc @michaelbontyes @pirupius @denniskigen @ibacher @hadijahkyampeire

[CynthiaKamau]

Thanks @jnsereko for this. I think it would be great to also configure the identifiers to show on the print view, some are very sensitive

[jnsereko]

Thanks @jnsereko for this. I think it would be great to also configure the identifiers to show on the print view, some are very sensitive

@CynthiaKamau, do you mean the implementer choosing which identifier types to include? something like
idToInclude[ 'uuid_for_openmrs_identifier', 'uuid_for_someOther' ]

[denniskigen]

This is very close, @jnsereko. I've left a few more suggestions.

[denniskigen]

Please fix the conflicts with main. Also, have you figured out why printing doesn't work the first time round?

[jnsereko]

Please fix the conflicts with main. Also, have you figured out why printing doesn't work the first time round?

@denniskigen I have been banging my head on the wall since yesterday but not yet sure why this is happening

[denniskigen]

A few other random notes:

• We're using the modal suffix for modal components - so PrintIdentifierSticker should be renamed print-identifier-sticker.modal.tsx.

[ibacher]

Bunch of miscellaneous thoughts. I think, though, that the main thing is to look at this example vs the code here. Note in particular, we are doing nothing that ensures isPrinting is true before the promise resolves.

[ibacher]

I think an allow-list of identifiers to include is better than a list of identifiers to exclude. It would also be nice to not necessarily tie this directly to UUIDs, e.g., it would be nice to be able to specify these by identifier name.

[denniskigen]

Bunch of miscellaneous thoughts. I think, though, that the main thing is to look at this example vs the code here. Note in particular, we are doing nothing that ensures isPrinting is true before the promise resolves.

Could you clarify this a bit more, @ibacher?

[ibacher]

@denniskigen I think I was wrong about that...

[denniskigen]

About?

[ibacher]

Sorry responding to this:

Could you clarify this a bit more, @ibacher?

[denniskigen]

As we discussed elsewhere, we thinking the issue is related to the library, right?

[ibacher]

Something like that. The ReactToPrint library works by copying the DOM of the passed-in ref into an IFrame and printing that. I'm sort of wondering whether between that and Carbon's tendency to sometimes clone nodes, especially when using some composed bits is resulting in ReactToPrint looking at a ref that has no content.

[denniskigen]

@jnsereko I've squashed your commits into a single commit to ensure a cleaner commit history. This should simplify future rebasing and merges.

Thank you for your understanding and contributions!

[denniskigen]

@ibacher FWIW, this is the actual error (from logging inside the onPrintError callback):

It's happening in the onBeforeGetContent callback (per the errorLocation argument).

Also, removing all the Carbon bits doesn't resolve the issue. Nor does switching to the FunctionalComponent implementation.

[jnsereko]

It's happening in the onBeforeGetContent callback (per the errorLocation argument).

exactly @denniskigen

[ibacher]

So at least this is something. That looks like the failure is occurring here (although oddly in code that's trying to format a nice error message).

[ibacher]

So here's my best guess of what's going on:

• The patient chart runs React 18.3.1
• ReactToPrint relies on the deprecated findDOMNode function
• Somewhere along the way findDOMNode() tries to warn about this deprecation or something similar, but only in development mode
• Because the tree being used by ReactToPrint when it calls findDOMNode() is incomplete, an error occurs while generating the deprecation message / warning / etc.
• Built in production mode, which disables the React dev warnings, the print function works as expected

Basically, there's no changes we can make to our code that will make this behaviour go away, but the behaviour only occurs in development mode (you can verify this by modifying the serve command in patient-banner-app to run the development server in production mode and load it into the app shell also running in production mode using import map overrides; actually you don't even need to run the app shell in production mode; you can run the app shell in development mode because the app shell is still using React 18.2.0, which lacks this warning).

However, the upshot of all this is that it is extremely likely that ReactToPrint is incompatible with React 19.

[denniskigen]

Thanks for the deep dive, @ibacher. Is the takeaway then that merging this in will mean it will work as expected in production? If so, then let's focus on getting it in.

[ibacher]

Yeah, I think it's very likely to work as expected in production. We just may need to have a medium-term strategy to either update or replace ReactToPrint too.

[denniskigen]

Could you re-review, @ibacher, @jnsereko? Here's the updated demo:

updated-video.mp4

[ibacher]

Anyway we can set the print rotation to default to landscape? I think that will likely work better. For future work, we probably want to allow implementations to specify custom CSS that could be used to style the identifier badge to meet local requirements, but LGTM.

[denniskigen]

@ibacher it's trivial to add a config property that governs which orientation to default to and then it would leverage this approach. Should I add one and make it default to portrait? (@jnsereko is there a specific requirement for a default orientation for this feature?)

[denniskigen]

Scratch that, it appears that it's not so straightforward to change the orientation for custom sizes (like the default 4in 6in value). For standard page sizes, something like this works well:

const  { printPageOrientation } = useConfig();

<style type="text/css" media="print">
  {`
    @page {
      size: A3 ${printPageOrientation};
    }
  `}
</style>

[denniskigen]

It looks like this is something else worth looking into when evaluating whether to move away from this library. I'm proceeding to merge to unblock Madiro for now.

[jnsereko]

I am going to create a follow up ticket to investigate what's breaking the Library and how to move on. Thank you so much @denniskigen

[denniskigen]

FYI MatthewHerbst/react-to-print#706 (comment)

[MatthewHerbst]

react-to-print maintainer here. Cool to see the tool being used by y'all! Will be getting React 19 support, as well as general modernization (ESM module support for example), figured out in the next few days