Hacker News Reader

I'm completely favor of non-UI components but that's not how a client-side router should work. What I mean is tying a particular route to a particular UI component is the wrong way to go. Instead the route should be tied to the application state itself, and application state should be what drives UI.

View on HN

We've almost tied all the knots we need to meet this requirement of a router.

Every application has UI nesting at the core of its state, though.

The UI is a reflection of the state. UI nesting is not part of the state itself. The route is just a serialized representation of the state.

Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).

Reply on news.ycombinator.com