-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Hacked-up version of Connect and Provider to use new context API
- Loading branch information
1 parent
5d792a2
commit 576f3f2
Showing
3 changed files
with
137 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
import React from "react"; | ||
|
||
export const ReactReduxContext = React.createContext(null); |
576f3f2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm scratching my head on this one as I was trying to use new Context API to write redux-like Provider and connect(), but I think it can just not work with server-side rendering :(
The most important thing is that one root component == one store, so you can call
createStore
for each request and render your component with given store in the tree, without fearing for race conditions between two independent requests which would use the same data.That was OK with old Context API, as it was attached to the actual tree. Now it's attached to an external object we're doomed: in your current implementation (and I could not find better idea), you have only one global context, so if you have two trees, using
<Provider store={store}>…
, with two different stores, you will face race conditions as the first tree will suddenly be udpated by the second one.It will work now, because between createElement() and renderToString() everything is synchronous, but that smells bad :(
Do you have any idea how to solve this?
576f3f2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@naholyr Nothing changes on your end. The same APIs exist for getting your per-request store into the component tree (
renderToString(<Provider store={store}/>...
). This doesn't affect server rendering at all.