Add a way to pass basic data to node via rails, document it's use and places not to use it

[marutypes]

Problem

Many apps want to be able to get basic data from the server that is unlikely / will never change over the course of the session before they render any React components. In some cases they need to do this to decide whether they even want to render the React app (looking at you Shopify/Web). We basically tell folks to "just use graphQL / fetch" for these things when they are using quilt_rails, but often they end up going through a lot of contortions to not do that or use it for things that it really shouldn't be used for.

At the very least, if all you're getting is something like a shop_id that will never change during the user's session, it is bad to force an extra HTTP request to do so.

Current art

Presently the only real way to get data from your Rails app to your React app via quilt_rails without making any extra HTTP requests is:

• adding extra HTTP headers to the proxied request
• having the app manually grab them using react-html's getRequestHeader
• serializing/deserializing the extracted data using useSerialized
• providing that data down into the react app via props or context

This is a lot of boilerplate to add for something that is relatively a common want, and as a result what usually ends up happening is they do in fact "just use GraphQL" and add an extra blocking network hop to all their renders.

Proposal

• add an optional argument to render_react which serializes data into JSON and attaches it as a header to the proxied request (for example: x-quilt-data: '{"some": "serialized", "json": "object"}'
• add code to the render middleware generated by react-server which extracts this data and passes it as a prop to the rendered app
• 🎉

Caveats

We definitely do not want this to be seen as the default way to pass all data, so we must be sure to document that it is specifically suited to data that does not change during a session and is needed for every route of the app.