Fork me on GitHub
Timofey Sitnikov10:06:58

Does it make sense that :will-enter code runs 3 times every time a page is loaded?

Björn Ebbinghaus11:06:52

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?

Björn Ebbinghaus15:06:34

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]
    [: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.

Timofey Sitnikov10:06:11

Here is my :will-enter source:

:will-enter        (fn [app route-params]
                        (log/info "Will enter ResetPwd" route-params)
                        (dr/route-immediate [:component/id :resetpwd]))


I have a component that is not normalized for some reason. Is there a way to debug that, or a common cause? Ident is defined and passed to the component.

Björn Ebbinghaus11:06:07

Can you share some code?


@U4VT24ZM3 thanks, got it working 🙂


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


Hi @tony.kay, I noticed that sends are no longer combined in my network tab. When I looked into the code of the tx-processing it seems that it is currently impossible to combine sends because the first in the queue is the only one that is being send. Is this expected?


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)