[jgautsch]

Two things I've found beneficial are:

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.

[matt4077]

I'm not completely firm on this (and appreciate corrections) but it appears that you could get these benefits without a client-side router? I. e. it's perfectly feasibly to render a different page/view when a link is clicked without a router by just changing the state and swapping out components.

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.

[jgautsch]

> 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.

[tomcam]

Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.