Print directly from pages, rather than via PrintPage

[G-Ambatte]

Your idea:

I was investigating how one might call the print function from within an iFrame, and after some experimentation, I discovered that the following command works to open a print dialogue:

window.frames['BrewRenderer'].contentWindow.print()

However, the print preview shows as result quite unlike the desired output.
In order to print the full Brew, the following CSS needs to be added:

@media print {
	.brewRenderer {
		height: 100% !important;
		overflow-y: unset;
	}
	.brewRenderer .pages {
		margin: 0px;
	}
	.brewRenderer .pages>.page {
		box-shadow: unset;
	}
}

As this makes printing from the New/Edit/Share pages possible, there is potentially no longer a requirement for a separate PrintPage.

Implementation Tasks:

• Edit navbar/print.navitem.jsx to call the print function directly instead of linking to /print
  • As a React Function Component, rather than Class Component (optional?)
• Add @media print CSS to BrewRenderer styling
• Update NewPage to use the standard PrintNavItem rather than a custom LocalPrintNavItem
• Test Print button functionality on all pages
  • EditPage
  • SharePage
  • NewPage
• Remove Print (possibly optional?)
  • Remove PrintPage files
  • Remove /print route
    • homebrew.js routes
    • app.js funtionality

[ericscheid]

I use the /print endpoint with VisualPing to detect breakage.

There are possibly other uses for the /print endpoint too.

Keep it.

[G-Ambatte]

My main concern was to do with server side rendering, as I believe the /print endpoint was the main point of weakness - although I think that was resolved a while back, @calculuschild might be able to confirm.
I would expect that any VisualPing monitoring being done in /print could equally be replicated in /share, although I'm not 100% familiar with the specific tool.

I'd suggest that we take a staged approach, starting by implementing printing directly from the Edit and Share Pages, then monitoring the /print route to see how much traffic it actually gets. We can then make the call to keep or remove it based on its actual usage, and execute that in a future PR if necessary.

---

As mentioned in the Gitter chat, it's also an opportunity to re-write this particular NavItem as a React Function Component, rather than a Class Component. If we're looking at transitioning to Function Components, this would be a good place to start.

[ericscheid]

VisualPing only scrolls the top-most frame. This works with the /print resource, but not with the /share endpoint.

IIRC, /print still delivers a server side rendering in the http response payload. You can confirm this by view-source (as distinct from Inspect DOM)

Removing the server-side rendering wouldn't upset VisualPing because it does run the start_app() javascript.

[calculuschild]

I'm not sure I see the problem this is trying to solve. Can you elaborate? As for SSR, we can change that behavior without fully removing /print.

As @ericscheid points out, /print is being used for other links. For instance it's what Google is using to track several of our reported issues on Chrome.

[ericscheid]

Ah, yes .. links to /print pages could well already exist in other places, as links tend to do. It would be rude for use to make all those links go dead.

[MichielDeMey]

This is also slightly related to #2740.

The fact that /print is done through SRR means it renders slightly different than the editor.

[ericscheid]

This is also slightly related to #2740.

The fact that /print is done through SRR means it renders slightly different than the editor.

Thankfully (stupidly) the page also renders on client side by inclusion of the start_app(..) call with the full brew contents.

[calculuschild]

Wow, I don't remember this issue at all, but I guess I was there.

Now that I better understand the initial request, I may have changed my mind on this. Looks like the main concern was keeping existing /print links working, but now that it's been a while I don't know how necessary that is. I used a few /print links to share minimal error examples with Google, but those ones have been solved. I don't think many users currently share /print links around, but they share the same ID as a share page, so we could easily redirect them to the /share equivalent.

It looks like visualping also supports actions inside iframes now too https://help.visualping.io/en/articles/5948932-how-do-i-use-action-tools#h_08c167fc99 so monitoring should work on /share pages.

At this point I am in favor of this change. Remove the need for a separate /print page we have to maintain, make the UX more straightforward.

[ericscheid]

It looks like visualping also supports actions inside iframes now too so monitoring should work on /share pages.

That's the support for actions inside iframes (clicking buttons, selecting things etc). The image they capture/monitor would still be of the whole page, and thus constrained to the visible size of the iframe. Monitoring the /print endpoint is useful in that up to 10 pages of the content can be monitored.

We could ask them to support targeting an iframe.

[calculuschild]

Fixed by #3491