[girvo]

Interestingly, we're using our "own" router that I wrote in a fit of frustration; it's tiny, not particularly well documented and has the interesting design choice of handing the route matching on to the user of the library; give each <Route /> component a name and have your route matcher callback return that name and you're good to go.

The reason why I went down that route (pun intended) was that we built a rather large, isomorphic/universal web application that for SEO reasons had to act like a website vs a web app most of the time; until it started up the client side JS anyway. "react-router-component" was so close to what we wanted, but because it used React's somewhat undocumented "context" feature, it didn't play nicely with our Flux implementation at the time (Flummox).

For that reason, my tiny router came into being, and for some reason it keeps sticking around despite my best efforts...

https://github.com/studionone/react-isorouter

Ps. I just found out that the README links to non-existent documentation, I really should fix that...

[RobertoG]

Thanks.

I'm trying to find my way around flux but until now has been a little frustrating experience.

I wish something like Elm was mature enough.

[girvo]

> I wish something like Elm was mature enough.

So do I :)

If you're not 100% up on Flux, I recommend having a play with Hoverboard[0] -- it's a tiny implementation of the Flux architecture, with some interesting choices itself. It's a single function, too, which is pretty neat!

I've been using it to implement the "Flux Challenge" in combination with domChanger[1] instead of React: https://github.com/girvo/domchanger-hoverboard-flux-challeng...

And here's a partial TodoMVC implementation I wrote in Hoverboard and domChanger: https://github.com/studionone/todomvc-domchanger-hoverboard

---

[0] https://github.com/jesseskinner/hoverboard

[1] https://github.com/creationix/domchanger