It's disappointing that this depends on React's router, considering Redux is an agnostic framework. Unless I'm reading something wrong here..
> After integrating redux and react-router in my site, I extracted my solution to a new project: redux-simple-router. The goal is simple: let react-router do all the work. They have already developed very elegant APIs for implementing routing components, and you should just use them.
The explicit goal of the project is to take advantage of react-router's existing tools when used with redux, it doesn't make any sense to lament that it depends on react-router.
React is just way too heavy for my needs and if I'm going to put markup in my JS files I might as well just use Hyperscript so it actually is javascript. By pairing virtual-dom with redux, my entire application's state, including how the UI currently looks, is held in one large immutable object which I just apply reducers to when I want to change the interface. React, and all the other modern front-end frameworks, still have to deal with state living in two places (in stores and in the DOM) whereas in my apps' state only lives in once place - the Redux store.
Don't get me wrong, React pushed front-end development forward in a big way, but a lot of cool stuff has come out of the woodwork in response to it that is definitely worth checking out. I'm more interested true functional-reactive web libraries than React. Cycle, Elm, Ohm, and Mercury are a few I would recommend checking out.
What is the benefit of using react-router (I am assuming on the client side) versus using a server side router that comes with whatever web framework that you are using?
In a single page app, your client routes (representing individual views) don't have to map directly to your server side routes, which gives you the ability to have pages/views that don't require a server roundtrip.
You can also cache frequently used data on the client and use them on multiple "pages" as you navigate through your client side routes/pages, loading "page" specific data from your API as needed.
So in general it gives you more tools/options for building a snappier app.
As I understand it, client-side routers manage the relationship between URLs and state. The parts of state that are relevant when a page/view might be bookmarked/shared etc. are encoded in the URL, and a given URL can be decoded into an initial state.
I'm now wondering if the first direction (state->url) couldn't just be thought of as a component. It just extracts parts of state and renders it into a string. The other direction would then be an action.
The specific component/state rendered is a reaction to the URL, not the other way around (this can get cloudy with semantics though). Keeping the URL and the current page state in sync takes the form of updating the path, and having your application react to that.
You're right it is perfectly feasible to render a different page/view when a link is clicked without a client-side router library, but the "swapping out components" part can get tricky for non-trivial cases like a hierarchical UI, or components that need to consume URL params.
A client-side router like react-router abstracts away a lot of the hard stuff you'd quickly run into on your own if A.) your app has navigation, and B.) you want to have URLs associated to views/states.