Render callbacks can now inject HTML content into multiple different
elements, and may also append content to the <head> or <body> elements, on
both the client and the server.
This new API was inspired by trying to use the styled-components npm
package on the server, which involves not only rendering and injecting
static HTML somewhere in the <body>, but also appending the resulting
<style> tag(s) into the <head>:
import { onPageLoad } from "meteor/server-render";
import { renderToString } from "react-dom/server";
import { ServerStyleSheet } from "styled-components";
onPageLoad(sink => {
const sheet = new ServerStyleSheet();
const html = renderToString(sheet.collectStyles(
<App location={sink.request.url} />
));
sink.renderIntoElementById("app", html);
sink.appendToHead(sheet.getStyleTags());
});
Note that the server-render package now exports an onPageLoad function,
rather than the old renderIntoElementById function. The functionality of
renderIntoElementById is now exposed by the {Client,Server}Sink API.
I say the client-side version of this API is 'isomorphish' to the
server-side version, because ClientSink methods can accept DOM nodes in
addition to raw HTML strings, whereas DOM nodes don't really make sense on
the server.
Meteor 1.5.1 will pin version 1.4.x of the accounts-password package, so
Meteor 1.6 only needs to use a different (greater) minor version.
Related: 0ad123db5b
Based on this warning:
npm ERR! As of npm@5, the npm cache self-heals from corruption issues and
npm ERR! data extracted from the cache is guaranteed to be valid. If you
npm ERR! want to make sure everything is consistent, use 'npm cache
npm ERR! verify' instead.
npm ERR!
npm ERR! If you're sure you want to delete the entire cache, rerun this
npm ERR! command with --force.
The server-render package requires webapp@1.3.17 or later, but using a
non-prerelease version contraint for a package involved in the release
(i.e., webapp) is tricky during the prerelease phase, since the -beta.n
version is strictly enforced.
This API allows registering callbacks that have the opportunity to modify
boilerplate.baseData on each request, which will be useful for
implementing server-side rendering.
The code in question behaves the same as before if there are no callbacks
registered, so this change should be completely backwards compatible.
