Support for custom renderers

[ericclemmons]

Support for custom renderers

[yuchi]

(We’re talking about React ≥ 0.14 of course)

[ericclemmons]

@yuchi That's a good thought. I had similar thoughts along these lines, but still having issues with the v2 branch with v0.14 & React Router v1 (and the issues is most likely that).

TBH, I'm not 100% sure how well the Resolver will apply in those situations. Because React doesn't support async rendering, the current architecture has to recursively reveal the tree for dependencies to resolve.

It's something that'd just have to be tested with those alternatives and see how well it works (or doesn't) and go from there, since the React Native render lifecycle is entirely different than vanilla React.

[yuchi]

[…] since the React Native render lifecycle is entirely different than vanilla React

React 0.14 is here to solve that. In fact react-titanium uses the vanilla React reconciliation through its own rendering. That‘s what react native will do too.

[ericclemmons]

I guess I just don't actually know how they do it. Setting this for v3 in the meantime.

[ericclemmons]

I was working on the v2 branch today & got React v0.14 working.

https://github.com/ericclemmons/react-resolver/tree/v2/examples/react-v0.14

I added some comments in 0a92e51, but I gotta figure out how this will work.

For example, this really only makes sense on the server-side when using require("react-dom/server").renderToString for universal rendering. React Native and everything else can actually just render like normal client-side code just like require("react-dom").render, since there's no need for bootstrapping.

[ericclemmons]

My initial idea to handle this will be to introduce something like:

Resolver
  .resolveWith(renderToString, () => <Handler {...state} />)
  .then(({ markup, data }) => ...)
;

Similarly, the client could use:

Resolver.renderWith(render, () => <Handler {...state} />, node);

The problem with the client-side version is that it _currently relies on renderToString to recursively load the whole tree.

The alternative to this is to render into a hidden "portal" via render, let all the data accumulate, then re-render on last time to the actual target node.