Yes, synchronous operation is the only way to do an input that transforms things
Does it make sense that :will-enter
code runs 3 times every time a page is loaded?
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.
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.
Can you share some code?
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. 🙂
@mroerni 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. https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/algorithms/tx_processing.cljc#L104 Is this expected?
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.
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!