From the docs: > WARNING > will-enter can be called multiple times as part of the route resolution algorithm and MUST NOT side-effect. Any I/O must be done in the lambda passed to `route-deferred`, which must then trigger the `dr/target-ready` mutation to indicate that the route is ready. You can use plain `transact!` to start a mutation within `route-deferred`, and the mutation can use `target-ready!` to send the signal. For why exactly will-enter seems to be always called three times, you have to ask Tony directly. 🙂

@U4VT24ZM3 @tony.kay my route-deferred has load! inside (same as in Fulcro book), so client sends 3 requests to the server and load a lot of data. This make bad performance and prolongate page loading time. Any idea how to prevent this behavior?

Can you share your code?

It very definitely should not be sending the load 3x if you used route-deferred properly (gave it a lambda). The will-enter is called as part of route resolution, but doesn't actually do the route-deferred part (unless there's a bug) until that particular route is actually chosen.

my will-enter looks like this

(fn [app route-params]
  (dr/route-deferred
    [:component/id ::ElementsList]
    #(df/load! app :my.api/search-elements-all list-components/ElementsOnList
       {:post-mutation        `dr/target-ready
        :post-mutation-params {:target [:component/id ::ElementsList]}
        :target               [:component/id ::ElementsList :element-list/elements]
        :params               {:filter/element-sort-order :descending
                               :filter/limit              100
                               :filter/before             (datetime/to-inst (:end-time route-params))
                               :filter/after              (datetime/to-inst (:start-time route-params))}})))

it's also throw an error, which could be relevant

core.cljs:159 ERROR [com.fulcrologic.fulcro.routing.dynamic-routing:188] - dr/target-ready! was called but there was no router waiting for the target listed:  [:component/id :app.client.comp.elements-page/ElementsList] This could mean you sent one ident, and indicated ready on another.

Thank you for the answers! I've found the bug. I've been calling dr/change-route-relative! within :will-enter of parent component without lambda. This was a reason for 3 load by child. 🙂 sorry for troubles.

Can you share some code?

@U4VT24ZM3 thanks, got it working 🙂

I wrote comp/query instead of comp/get-query.. doh..

Combined sends is implemented on a branch, but not well tested. The current tx processing does not do it. it's actually kind of complicated because of things like abort, multi-remote support, etc.

(see batched-networking branch, I think)

Thanks!