Disclaimer: I am a former Backbone-using developer who hasn't done much front-end work since React became so dominant. I just don't understand this project. I'm

Disclaimer: I am a former Backbone-using developer who hasn't done much front-end work since React became so dominant. I just don't understand this project. I'm commenting to explain my confusion in the hopes that somebody else's perspective can help me see why React Router is helpful. When React came out it was billed as just the "V" in client-side MVC. While just about everybody has their own understanding of MVC, my interpretation of the "V" was that it was about things you can see. So React was going to take my data and maintain a UI based on that data without thrashing on the DOM. Cool! But nobody seemed to do that at first. They put HTTP requests all sorts of stuff inside the React component, and then handled the requesting, processing, and rendering as internal details to the component. Then the Flux idea came around, which was (I think) to brand one-directional events as "actions" and then smartly cache/reduce an ongoing stream of actions into a single data structure that represents lots of potentially disparate parts of your application. This also made some amount of sense to me. Surely there would be lots of things that could create actions: incoming DOM events representing a user's intentions, ajax responses that have potentially new facts about the world, websocket events, signals from the camera and microphone, and anything else that might cause a change in the overall state of the page. With the possible exception of DOM events, which the view should quickly translate into meaningful actions anyways, these actions are really not related to the "V" at all. So what benefit would I get from authoring the logic of URL-change handlers in JSX? Wouldn't it be nicer to write some JavaScript that handles those events and transforms them into actions?