I've been given the opportunity to speak at ReactiveConf next month where I'll talk about client application routing. I have been experimenting with and working on routing for nearly two years, and it all began when I started to slowly transition from Angular to React. In June last year, the first React Europe conference took place in Paris. I watched it online, and during his Keynote, Christopher Chedeau (AKA Vjeux) said, talking about routers in React:
We've only seen one player. Is there any innovation going on? (...) Innovation already happened a few years before. And it happened in the Ember community.
At the time, I was working on the first release of router5, a framework and client agnostic routing solution. It is interesting to try to understand what has influenced routing until recently and shaped our "mental model", and why we've believed routing was for most parts a solved problem.
The way we do routing in client applications has been influenced by server-side routing. On servers, routing is some sort of stateless pattern matching. For a given request, a route is matched and a page is returned after execution of a controller method or callback. We have translated this "route => page" approach to clients by making routers responsible for rendering route-level components in single page applications: "route => view" or "route => component". Client applications are not stateless and deal with state transitions (including route transitions), but the server way of approaching routing has led us to hide state away.
If this short introduction makes you want to hear more about routing and new ways to approach it, then don't forget ReactiveConf next month!
Top comments (0)