Print directly from pages, rather than via PrintPage about homebrewery HOT 7 OPEN

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

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

Keep it.

from homebrewery.

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.

from homebrewery.

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.

from homebrewery.

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.

from homebrewery.

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.

from homebrewery.

This is also slightly related to #2740.

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

from homebrewery.

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.

from homebrewery.