The holy-grail of server rendering

[goatslacker]

There's some clean up work I'd still like to do with this but I'm throwing it up here for now to gather early feedback/let people know what's coming.

Why?

It allows us to define our data fetching needs in the component. It's not quite relay though, you don't define what you need but rather how you're going to get it.

This works very well with Alt's Data Sources.

This lets you keep your singleton stores and actions which are easier to reason about and you don't have to pass flux around in context.

[iam4x]

Since you added browser: true in eslint configuration shouldn't you remove the enable/disable comments?

[goatslacker]

yeah. I'm going to either remove browser: true or remove these.

I just threw browser: true in there so lint would shut up so I could push this.

[hungtuchen]

This lets you keep your singleton stores and actions which are easier to reason about and you don't have to pass flux around in context.

Would you like to elaborate on how this work inside?
Even like when we dealing with chatting service, each request would require specific user session to populate store, Is this still valid in this case?

Sounds nice, hope to see some small example

[srph]

Interesting. I tend to put _request_s on the components itself, and just update / hydrate the _store_s with the response.

[goatslacker]

@transedward sure.

At a high level:

• All the stores are flushed from any previous data.
• We resolve all the data fetches that need to be made in a single pass and then execute them.
• We trap all the dispatches so they buffer the calls.
• Once we have all the data back in a Promise.all we unleash all the dispatches in order. Dispatches are synchronous.
• Once all dispatches have completed we render the component tree again which should have the up to date data from the stores.
• We send that markup down through the promise so one can render it server-side.

[hungtuchen]

@goatslacker thanks for such detailed step by step explanation
do we have guarantee that each request can be handle concurrently even if without multiple instances of flux?
Is that because you mention

We trap all the dispatches so they buffer the calls.

so that program won't be blocked until Promise.all resolved and then all the dispatches dispatched?

[goatslacker]

If the tests are passing then we have that guarantee: https://github.com/goatslacker/alt/blob/master/test/alt-iso-test.js#L124

it is because we trap dispatches, it is non-blocking however, concurrent requests are allowed.

[iam4x]

@goatslacker I have a few questions about AltIso.render

• Is it possible to resolve promise from a child component? For instance I have an App component that will resolve internationalised messages and which render an User component that will resolve an array of users too. I will see only the first component doing the fetch (App for messages).
• Have you tried to run it with react-router? After two transitions/page change it won't render the new component.

I'm trying to figure out but I'm getting stuck now :/ Help would be highly appreciated for updating the boilerplate (iam4x/isomorphic-flux-boilerplate#69)

[iam4x]

For react-router on the first transition, when AltIso.render is called: toDOM will unmount the whole component it will call HistoryLocation.removeChangeListener from react-router and will not be able to render a again the app.