update API.MD docs

[alecperkey]

Could you review my diff... It needs work still, for example the syntax for the promise function needs its options destructed, right?

Thank you for taking the initiative to manage this repo a bit more than it was being done. !

@asyncConnect([{
  key: 'accountDetails',
  promise: ({helpers, params, state}) => {
    counter: state.counter,
    return helpers.client.get('/accounts/' + params.id);
  }
}])

[AVVS]

Thanks for readme updates, I'll review them today and will leave appropriate comments

[AVVS]

@alecperkey could you update your input into docs based on my comments or give me some timeline around it? I believe this would be helpful for many users

[alecperkey]

To be honest if we go back and forth on this, you will soon realize I have been working with React and Redux for only a few weeks and I don't want to pretend otherwise a public forum ;)

Since it may help others though I can go on a bit... update...turned out a little more than a bit...sorry :S

The boilerplate RRUHE explains the high level purpose here, but I was hoping to understand more from this API doc.

My confusion stemmed from trying to use the decorator to pass async data (promises) to props without delaying rendering. But that is the the antithesis of (what I now think to be) this package's primary purpose: pre-rendered async (promise) data for SSR response with async data already hydrating components' props...

I realize now it is possible to conditionally load something like a loading spinner markup until async data is in the state (and a re-render is fired). Maybe others beside me will wrongly assume they are forced to delay routes rendering whenever async data fetching. In fact, delaying every transition might be only necessary for:

• certain SEO tactics
• heavy personalized content like advertisements (which also must load fast)
• or, like Facebook/Google search use case, providing complex pages to users with strict bandwidth
• phone apps trying to reduce battery usage

Is it possible to have the initial route requested pre-rendered with asyncConnect with SSR, but also ensure subsequent route transitions by user are immediate (request async data after route transition)?

There is mention of fetchDataDeferred, fetchData, componentDidMount for these sort of different use cases here but I'm not sure if these static methods are still in the souce. I could not find them in RRUHE.

But there is a conditional logic in the client.js for filtering render delays it seems

What other use case besides optimized-SEO,

[AVVS]

SSR works like that:

1. references to components that are going to be rendered are gathered from react-router
2. redux-connect iterates over those components and looks for it's method applied by decorator on the components
3. gathers promises and returns their result, as well as resulting store state
4. store is created with initial state from (3)
5. components are rendered in sync fashion with resulting values

Client rendering:

1. on first render we have (5)
2. on next render (any route transition) - it goes through 1 to 3, delaying render until data is fetched

What you can do to circumvent delays is add custom logic for client, which essentially has to either use filter and not try to load data at all, or, if you need that fetching logic to work, but, instead show a loader - add conditional logic based on __CLIENT__ or __SERVER__ globals that are available

Does that make sense?

[alecperkey]

Yes, learned a lot today :+1: Thanks. I also looked into sars repo for appetini-front and seeing the decorator use case helped.

Any example of using these __CLIENT__ or __SERVER__ globals?