Could use fuller explanation of project vision

[altaurog]

I'm still pretty new to react and redux. I could use a little more explanation here, and I imagine other people might as well.

It's seems a big part of the vision of this project is that the route parameters don't need to be in the app's state store, because react-router already hands them to the route component. Got that. Also it seems like some of us are still confused about that and think that ideally the state store in redux apps should be the one source of all truth. (#68 and #205, for example.) Apparently the authors of redux-router are convinced, however, because they now recommend this project moving forward.

Theoretical stuff aside, I'm having trouble with something simple, and I'm curious to know how the proponents of this project would do it. Here's my code. (tl;dr a select element in the top-level component/route changes child component/route.)

The question is: how do I keep the <select> tag in sync with the route? It would be really nice to have the route parameters while I'm rendering it, but that component doesn't seem to have access to them, only the child route component does. It seems like I have a few options, but none of them are so appealing:

1. I could dispatch a SELECT_BOOK action in onBookSelect with the bookId and have a reducer store the selected book in the state. The BookSelect component would then pull the selected book out of the state when rendering itself. The problem with this is A. it seems redundant and B. it doesn't really solve anything, because the select tag goes out of sync only in cases where onBookSelect wasn't fired (i.e. page refresh/manual navigation).
2. I could parse state.routing.location.path when rendering BookSelect to figure out what the route parameters are. This definitely feels like duplicating work that is already being done somewhere else.
3. (Variation on 2) I could construct the route path for each book and use that as option value instead of the book id. Comparing that to the current location.path would be easier and not require reconstructing the route parameters, but this doesn't really feel right either.

Also (sorry, this might be a separate issue, but it seems related), there is a lot of talk about loading data from the components. I can see how that would be easier, since that's where react-router makes the routeParams available, but it doesn't feel very functional to me. It seems to me that Single Responsibility Principle would be better addressed by loading data from an action/thunk, as recommended in the redux docs on async actions. In my example, I would have onBookSelect dispatch a SELECT_BOOK action which would fetch the data for the selected book. To do that, I'd probably want the bookId on the action, not the book's route path in the app, so strategy 3 ultimately wouldn't save me any (duplicated) work.

Now that I think about it, the async action approach suffers the same shortcoming as strategy 1.

What am I missing? What is the recommended way to handle this? I would really appreciate some insight here.

[jlongster]

@altaurog this is more appropriate for the react-router channel on discord: http://join.reactiflux.com

If you are using react-router and redux, you have two sources of truth, no getting around it. The browser itself can invoke route changes so it's just part of the system. It's fine though. I would figure out how you would solve this if you were just using react-router first (how does a parent component get access to a child route's params? that seems a react-router issue).

Please only open issues if you find an actual bug in our code or have a specific feature request.

[timdorr]

The new render API in react-router may enable us to pull more state directly from the router itself, but that's waiting on a 2.0.0 release (which should be soon?).

I would give react-router 2.0.0-rc5 a shot. It allows you to access the route state via this.context from anywhere in the route tree. That would solve a lot of your problems.