On Thursday, April 24, 2014 10:50:21 PM UTC-4, Don Jackson wrote: > On Apr 11, 2014, at 3:28 PM, Dylan Butman <[email protected]> wrote: > > > > > Wrote a very small library on top of secretary that allows for two way data > > binding between edn (think application-state) and browser history. > > > https://github.com/pleasetrythisathome/tao > > > Thoughts, comments, pull requests, greatly appreciated! > > > > Very cool, thanks for sharing! > > > > I have some questions/thoughts: > > > > Would it possible (and a good/OK/reasonable idea) to keep the routing state > in the component local state of the Om root component, instead of the > app-state? > > > > If so, would it also be possible to initialize things like nav-chan, > init-history, and deftao routes in the iWillMount implementation of the Om > root component?
You only need to (and should) call init-history once, which starts watching browser history for changes and then dispatches secretary routes. Under the hood, deftao does two things. 1. Creates a secretary route (that is dispatched on matching history changes). When the route is matched it's params are passed through the :->state transformations, merged into together into a single hashmap at :path, and then put! [:route state] into the channel passed into deftao. 2. Adds an entry to an atom of state-matchers. When update-history is called, the state-matchers are mapped over, params are extracted from state at :path, and passed through :->route transformations. Tao then chooses the LAST route for while all params are non-nil (filter identity). I'm planning on adding optional dispatch functions that define when a route is valid, which would allow you to have multiple routes where all params might be non-nil and define criteria for when they should be considered valid. The way things work right now, you could absolutely put the output of the nav-chan into local state, and you could similarly call update-history with local state in IDidUpdate (or somewhere else). The problem with defining routes inside IWillMount is that you would no longer have control over the order in which routes are defined. I'm somewhat uncomfortable with the convention of picking the last matching route, but since secretary (and all other routing libraries i've used) do the same to match history to route, I'm ok with it for now. It might be possible to figure out a way to handle the matching order of asynchronously defined routes for state->route, but secretary doesn't support anything like that so it'd break the route->state portion. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
