> Bidirectional routes are indeed especially important to render and dispatch > routes in Om etc. In secretary its a bit awkward since you have to write > stuff like (defroute front-page "/" [] :front-page) and then a separate > thingie for matching the keywords back to the routes.
We have written several Om applications at work and this style of routing has never been a source of problems. The `defroute` macros does , perhaps unfortunately, provide the dual concern of adding a route to the global routes (which we plan to remove) and, optionally, giving you a route generator function if you name it (which we'll probably keep). We added this additional option because we felt that these two concerns came up frequently enough in the same context that it should just be convenient to do them at the same time. That is to say, every time we created a route we would have a function for generating a url to go with it. > On the other hand secretary will probably serve non-React apps well with its > dispatch actions when you dont have React lifecycle methods. I think this observation is a bit misguided. We have actually found Secretary to be solid in practice and that it works *very* well with Om and React. If you interpret route changes as a top level state transition this becomes easy to recognize. Each of our routing functions returns all of the data necessary to transition the app to the next state such as route parameters, view name, etc. Since secretary/dispatch! returns the result of the routing function, we can pass that data to a transition function which handles the actual mutation of the global application state. Each view name is mapped to a component which then receives the application state, so and so forth. This allows us to treat each of our main views as if they were pages (except much better, of course). This actually fits in with the lifecycle perfectly because the mounting/unmounting for a "view" component can be thought of as visiting and leaving a page. It works out nicely for situations like route and query parameter changes. tl;dr an Om and Secretary combination does work. In fact, our routes.cljs (where we defroute) and history.cljs (where we dispatch!) are files we rarely edit because this design works without much fuss. To recap the pattern for this looks like: (Google History) hash change token → dispatch! → data → transition! (Om) In conclusion, I would argue that the choices you make about how you manipulate your application state will have more consequences than the routing library you choose. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
