Allow finer grain control of render properties

[pklicnik]

When rendering on the server, react-engine constructs a object containing data for rendering based on "a mash of express render options, res.locals and meta info about react-engine" (quoted from the documentation in react-engine/lib/server.js). This is not ideal in all scenarios because this data is also sent to the client (via REACT_ENGINE variable) when there is no need.

We've specifically hit two scenarios:

1. We are using third party middleware which attaches content to res.locals. That content is completely unnecessary for rendering. react-engine blindly copies this data and includes it for rendering on both server and client side. This is wasteful (increases the overall payload) and also leads to potential security issues.
2. On the server, we fetch a HTML snippet and provide it as part of the render

var renderObj = {
    "top": encodeUriComponent("<div class='top'>My top section<div>")
};
res.render("template", renderObj);

Within our template, we then insert the raw HTML using the dangerouslySetInnerHTML API in React:

<div dangerouslySetInnerHTML={{__html: decodeURIComponent(this.props.top)}} />

This is a situation were we do want the content to be supplied during server side rendering, but it should not be sent as part of the payload to the client.

[dglozic]

Some of this has already been mentioned in the issue #50 (scenario 2, to be exact). We concluded that being able to configure what to omit would be a valuable addition.

[dglozic]

@samsel, are you hoping for a pull request for this or just deliberating :-)?

[samsel]

@pklicnik @dglozic

I have added renderOptionsKeysToFilter property to the server config spec.

renderOptionsKeysToFilter is an array of keys that need to be filtered out from the data object that gets fed into the react component for rendering. more info

Let me know if this will help.

#80

[dglozic]

Thanks, @samsel - we will try it out asap.

[samsel]

@dglozic changes are not merged/published yet. You can directly install from github to test the changes.

npm install git://github.com/samsel/react-engine.git#configurable_omit

[dglozic]

Hey, @samsel - I looked at 2.2.0 and unfortunately renderOptionsKeysToFilter is not doing what we needed. What it does is filtering data before passing to render, but that does not help. What I was looking for was a way to pass the data for rendering on the server, but not send it to the client.

Perhaps we need another array in options, something like 'clientKeysToFilter' whose role would be to omit keys from 'data' object before creating the script element on line 138 of server.js:

  // state (script) injection
  var script = format(TEMPLATE, Config.client.markupId, JSON.stringify(data));

[dglozic]

Bump.

[samsel]

@dglozic curious to know the use case behind having some data only for server rendering and not for client.

[dglozic]

We have a number of microservices that share some common areas (e.g. common header). In order not to make them stack-dependent, we just expose them as API that returns HTML so that any app can fetch the HTML snippet and inline it. In case of react, we just fetch the HTML in the controller, pass the snippet in as a string in the settings, the view renders it by by adding this:

and then the component adds the rest of the page. Since we will not need 'this.props.top' on the client, it is wasteful to send it, and this property can be long depending on the complexity of the snippet coming in. When you look at the source as rendered, a large chunk of it is encoded HTML snippet sitting inside the data sent by react-engine to the client. It bloats the HTML needlessly.

[samsel]

@dglozic can you please clarify what this.props.top is?

[dglozic]

@samsel the more I think about this, the more I realize that the real solution for our problem is not to selectively filter properties we are sending to the components on the server vs client. Doing so would cause checksum problems because React would complain that a server and client side rendering is not the same.

I think what we need to do is render the html/head/body elements on the server using another engine (say, dust.js), and then render the actualy body as a React component. On the server, we can render the react component in a string and just inline it in dust. On the client, we can mount the same react component on a DOM node other than 'document'. For this we need configurable mount node id in Client specs (and you already have an issue opened for this).

You can close this issue and we can track the rest in issue #68.

[samsel]

great thanks