-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redux Integration #4668
Redux Integration #4668
Conversation
react-router-redux is already 4.0, so it will have to be 5.0.0 for now. Hopefully, we can sync it up soon and Lerna doesn't become too much of a pain to use now.
@@ -1,6 +1,6 @@ | |||
{ | |||
"lerna": "2.0.0-beta.32", | |||
"version": "4.0.0-beta.8", | |||
"version": "independent", |
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.
Done as a separate commit (d296fa9) so we can revert easily.
class ConnectedRouter extends Component { | ||
static propTypes = { | ||
store: PropTypes.object, | ||
history: PropTypes.object, |
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 wasn't sure if we wanted to provide a reasonable default here (create a browser history if none provided) or set up prefab <Connected(Browser/Hash/Memory)Router>
exports.
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.
My personal opinion as an end-user is to serve prefab exports, this avoids me on my end having to put a reference to the history module and init it and pass it in. It also means I dont need a dependency in my package to history (I know I could ignore it, but then some of my tools throw warnings) -- and personally you guys are better equipped to keep those dependencies updated along side react-router.
Just my 2¢
fs.readFileSync('umd/react-router-redux.min.js') | ||
) | ||
|
||
console.log('\ngzipped, the UMD build is %s', prettyBytes(size)) |
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.
Current size is 1.21 kB
As a casual observer, can you verify if I understand this correctly: the main purpose of the |
Yeah, the location gets dispatched as a |
Is there any particular reason that has to be done by the router? Would a <Provider store={store}>
<BrowserRouter>
<SynchronizedLocation store={store}>
...
</SynchronizedLocation>
</BrowserRouter>
</Provider> |
Hmm, that might end up being better. One thing people have constantly asked about is getting the router So, what could be cool here, is to actually do a |
Yeah, if people want params we could probably do it with |
Can people dispatch to navigate? That's another thing we get all the time. What I'm after in this package is:
Bonus would be |
As for jest/rollup, I'm into it, but @mjackson has more say on that stuff than me. |
The biggest blocker from using Jest is that it doesn't support browser compatibilty testing, correct? I know that I've seen a few test failures caused by mobile Safari. Keeping |
Yeah, Jest is node-only. But I'm only using a memory history for testing, so I don't need a DOM (real or fake).
Just discussed that with Ryan. We could do something like this: <ConnectedRoute path="/foo" matchStoreKey="foo" component={Foo} />
<ConnectedSwitch matchStoreKey="baz">
<Route path="/foo" component={Foo}/>
<Route path="/bar" component={Bar}/>
</ConnectedSwitch> That would put it into a known place in the store so you can reference each one. Also, we can set it to listen to the location from the store instead of from context, which means time travel should be a little easier. I don't know if that totally solves the problem of time travel, but it's a reasonable start. I'd also love to get some of the bits of @supasate's connected-react-router added in eventually. This is a first pass and he's got a head start on me, so I know there's some good bits of code gold to pull from. Plus, merging our efforts will be beneficial to everyone. |
BTW, in talking with @ryanflorence, we decided to just merge this in as-is for now and build on it with other PRs. If it's totally boned, that's fine because it's still an alpha. And I've reached out to @supasate and we'll see about merging in some of the connected-react-router goodness. |
Thanks @timdorr. I'll join the force! |
This is mostly copied from the current project, as it all works as-is. However, it drops the whole synchronizing-location-when-time-traveling thing. It was complex and I don't get the sense it was that popular of a use case. The important part was getting location into Redux's state, so you could easily get to it with
connect()
. If people want it that badly, we can bring it back and update for history 4.x (it shouldn't be a ton of work to do so).It adds a
<ConnectedRouter>
type of router that takes in a history prop and can read the store from<Provider>
(or a store prop, of course).Some other miscellany:
I'll add some comments in where I've got some sticking points before this should get merged.