yea I think that makes sense. I've also broken the rules by transacting a mutation from within :will-enter because in my case it is an idempotent mutation and calling route-immediate after the mutation, but probably not the best idea. I still have trouble figuring out the lifecycles of the routing system...

personally I just bypassed nearly all of fulcro's routing, using only route-immediate and handling everything else (loading, caching, etc.) through a reitit layer

one reason iirc is that the url <-> route segment system breaks down when you want nested routers sharing the same param, something like /user/:id/panel1, your route segments have to be like ["user" :id] ["panel1" :id]

do you use reitit controllers?

haven't seen those actually. I just have a big (50loc) on-navigate, not too complex though it was tricky to get right, e.g. for clerk and bfcache. I have each route tell me what it needs to load, and then on-navigate does the loading/caching/scrolling logic with a top-level view of what it needs

ah cool, that makes sense

thanks both, that's interesting. probably i'll just do it like @U051V5LLP did for now but @U797MAJ8M's solution is attractive for its consistency

I found the code I was thinking of, :pre-merge is another way to get query param state into the fulcro db:

:pre-merge     (fn [{:keys [data-tree current-normalized]}]
                    (let [{{{:keys [task-id]} :path
                            {:keys [open?]}   :query} :parameters
                           {route-name :name}         :data} (fr/current-reitit-match SPA)]
                      (merge
                        {:ui/open? (and
                                     (= :task-detail route-name)
                                     (= task-id (:task/id data-tree)) open?)}
                        current-normalized
                        data-tree)))