(Transmit) Nested Transmit containers and server-side rendering about react-isomorphic-starterkit

[RickWong]

You've hit a known isomorphic issue with Transmit, that its containers need to be declared as a single topdown tree. It's not possible to have multiple separated Transmit trees in your React tree. Normally nesting everything works perfectly because the React tree is alive on the client; nested components just come later. But on the server however you'll need all the nested data immediately. The solution is to return promises to some NestedContainer.getQuery() or some NestedContainer.getAllQueries() in the root view's container queries, so that the tree separation / container-gap is bridged. It really works fine when you get used to it, despite adding what you could consider "boilerplate querying", and sometimes having to write switch-branches twice (once in the React component, and once in the Transmit container). It's not as clean, but the problem is that React's render system is synchronous. The best way to deal with that is to resolve all nested queries at once by using a single topdown tree.

If you don't like this solution, try going back to using react-async (which hacks React + Node.js with fibers to render nested components truly asynchronously). The last commit that uses React Async is https://github.com/RickWong/react-isomorphic-starterkit/tree/1bbc3f247fcf62e71b6f40e12a8c0709bab08234

[Azaeres]

Would all of these queries always be resolved for each request? I'm wondering what scaling strategy to use. Is query caching enough? And/or is there any way to get it to fetch queries based on what route is matched by react-router?

[RickWong]

Would all of these queries always be resolved for each request? I'm wondering what scaling strategy to use. Is query caching enough?

It depends on your Model-layer. If you're using something Flux-like, like I am, then you can put the code interacting with Flux within the Transmit-queries. Any dispatched actions would call setQueryParams to update the query results. If you have any questions or ideas to improve the Transmit-interaction, you're welcome to submit an issue there.

And/or is there any way to get it to fetch queries based on what route is matched by react-router?

Yes you can. Just pass this.context.router from a parent component as queryParams prop to the Transmit container. That's the recommended way to pass context and other "configuration props". Then you'll be able to access the react-router functionality from queryParams.router within a Transmit query.

[Azaeres]

Alright! Much thanks for the advice.

[Azaeres]

Just pass this.context.router from a parent component as queryParams prop to the Transmit container.

If the Transmit container has a parent component, then won't we run into that "known isomorphic issue" you mentioned above?

[RickWong]

Not necessarily. Though it does have to happen at the first Transmit container's parent, where the context data is available and passable as prop from there out, so the first Transmit container can use it or share it with nested Transmit containers.

I know it's not an ideal API to be passing context props down a few layers. But I can't add context support to Transmit, mostly because the context belongs to the React lifecycle tree, not the Transmit querying tree; i.e. when Transmit resolves a sub-query, the wrapped sub-component isn't even alive yet.

[beeant]

I'm having the same problem. If it's possible can you please give us simple example/hint on how to implement the use of this.context.router?
Thank you

[RickWong]

@beeant Thanks for sharing your problem. I'll see if I can incorporate a routing example. React Router 1.0 rewrite is going to be released soon, so I might wait for that first.

[doronaviguy]

What about , react-router transitions ?

because of single top down tree of routes , it is impossible to implement transition with react-router.
any idea , how to overcome this problem ?

[elverskog]

Just to chime in, I'm running up against this as well. Rick, You may remember, I posted an issue about not getting server side rendering working at all (this was solved by moving the child query calls to root component). Not sure why I read it this wasy but because of the reference to Flow in the README, I was assuming the goal was to only make transmit calls that are bound only to components that appear on a initially loaded page. I'm currently trying to come up with some layer that allows this in a graphQL specific way...but am axcited to see how you would handle this.

[kulikalov]

@RickWong is this still relevant? If so, may be this information needs to be added to docs? Because it wasn't clear at all before i've read this issue.

Also, i still not quite sure, if i got the react-router-related stuff correctly. Does it means, that i have to create a single Transmit container on each route? Or only single container for entire app?
For example, here few routes:

<Router>
  <Route path="/" component={Wrapper}>
    <IndexRoute component={HomePage} />
    <Route path="/a/:id" component={Article} />
  </Route>
</Router>

Should i create Transmit containers for each of these 3 components (including Wrapper)? Or only one container somewhere on top? If one, then could you advice, how to do that, because i don't follow, where it should be located and how it should pass props to subroutes

[kulikalov]

ok, seems i've figured this out:

Create Transmit container from Wrapper, and call getFragment from there on descendants:

const RootComponent = Transmit.createContainer(Wrapper, {
  initialVariables: {},
  fragments: {
    data: (data) => {
      return Promise.all([
        HomePage.getFragment('data', {data}),
        Article.getFragment('data', {data})
      ])
    },
  }
})

I just need to figure out what route is it and call getFragment on specific components relatively

[kulikalov]

Also, why does server goes through the entire server-side lifecycle of Transmit-wrapped components twice? E.g. in this particular case HomePage, Article and Wrapper run "componentWillMount, ..., render" twice on server side. Is this intended behaviour?