Possible Issues with withAsyncComponent about react-async-component HOT 7 CLOSED

Thanks for getting back on it.
Will try to upload something for you to review based on your redux branch. Will keep you informed

from react-async-component.

Thanks for the report @kikoanis

I'll review these and make sure the cases are covered in the next batch of tests I plan to write.

from react-async-component.

Hi @kikoanis!

I am reviewing your issue. A couple of questions...

Not sure what rehydrateState.resolved[id] is referring to, but in the case of rehydrateState.resolved not defined it throws an error which I guess you should guard against its null-ability.

Have you experienced an undefined error?

I think you kill state rehydration too soon before it gets to the client.
Currently to get around this I only requery store.getState() which is not ideal.

I am a bit confused on this one. I believe store.getState() is against the redux store, if so this should not be affected by the line you have highlighted. The line in question is to remove the state that is used by this library when rehydrating a client with the async components that were resolved in a server render. This data is only needed once, and we therefore destroy to avoid issues with hot reloading and/or remounting cases.

from react-async-component.

Have you experienced an undefined error?

This is the error message I am getting

Which I tracked it down to line 84 in the compiled file

I am a bit confused on this one. I believe store.getState() is against the redux store
Yes it is.

This data is only needed once, and we therefore destroy to avoid issues with hot reloading and/or remounting cases.

I know this is for the client to use the server state only the first time. But the problem is that the client is not getting it first time. Not sure if we need the client to destroy it rather than the server, may be by replacing this line

state: { resolved: execContext.getResolved() },

by this

state: typeof window !== 'undefined' ? { resolved: execContext.getResolved() } : rehydrateState,

from react-async-component.

Hmm, something definitely sounds off here. It appears the state is not being configured properly for your environment. Is there any chance you could share your configuration with me so that I can review?

from react-async-component.

doh... this will take sometime as the redux branch is way behind and the project I am working on is private one and I am afraid I am not in a position to share it.

Anyway. On the server side what I am getting as a state is only this

{ 
   resolved: { 
      '1': true
   }
}

There is no elements of the other store state which is why I am doing Store.getState() again on the client side. Obviously this defeats the whole idea of SSR, doesn't it?

You may be right about the possibility of mis-configuration on our side so I will try to update the redux-opinionated branch to get a solid example to debug and review.

from react-async-component.

OK... So I think I managed to resolve the issue for now by adding a new reducer entry for "resolved" as an empty object into the redux store. The "resolved" entry is mentioned in the withAsyncComponent.
Still not sure if the "resolved" entry is for tracking changes between server and client internally, why we still need it in the redux store.

Unless I am missing something else not obvious in your react-universally@next

from react-async-component.