Closed webinista closed 8 years ago
Agree this should be delivered from the API. That's not there today though, so we'll have to figure out how to add this. Will scope it out on Monday. Thanks for mentioning early on in the build process @webinista!
@webinista when you say "delivered by the API", are you meaning the API returns an actual file that will be downloaded, or something else?
@gnakm do we know what the UX is supposed to be when someone clicks Print? Should it go to a new page or pop a new tab or download a file or other?
@ayaleloehr My assumption -- based on Alex Taylor's description -- is that the link would:
The deciding factor is whether that page can be generated client side and printed. I don't know how well browsers handle printing single page application states. (But I can look into it.)
If it can't be printed, then we need to consider:
Something I found when considering how this would work was jsPDF (http://jspdf.com/). It looks like it would be able to generate a PDF client-side using a selector for a DOM element in the current document.
I've had good experience with http://www.princexml.com for making PDFs of HTML/CSS.
These are good options if an HTML view does not print well.
Tiffany explained well that is expected in terms of the flow, New Window + print dialog
We have heard commonly enough from Veterans that they want to be able to print their medication list that I think this is an important feature for the MVP.
I have been thinking of the vets.gov API as always returning JSON, not HTML, so I am thinking that figuring out how to do this client side will be the best way to go.
With that, an API route will need to be created to filter by date in the way requested here, but at this point I believe the printable page generation should happen client side, whether that be 1) opening up an HTML page + print dialog or 2) generating a PDF.
I definitely agree that the API should only be expected to return JSON, and not files or other data-types. Stumbled across this link which might prove useful.
Closing in light of #2965 and associated discussion.
The idea from the design team is that these links will open a print-ready view of either 6 months, past year, or all prescriptions.
This presents a technical challenge, particularly for all prescriptions. The history could be quite long and take a while to retrieve. It's probably something that should be delivered by the API if possible.
Related to #2588