This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-15
Channels
- # babashka (41)
- # beginners (47)
- # calva (7)
- # cider (5)
- # cljsrn (2)
- # clojure (38)
- # clojure-europe (74)
- # clojure-nl (2)
- # clojure-spec (1)
- # clojure-uk (38)
- # clojurescript (42)
- # component (30)
- # core-async (2)
- # cryogen (6)
- # cursive (47)
- # datahike (7)
- # datomic (18)
- # defnpodcast (1)
- # fulcro (17)
- # graalvm (8)
- # graphql (4)
- # helix (5)
- # honeysql (5)
- # introduce-yourself (1)
- # jobs (5)
- # jobs-discuss (4)
- # malli (20)
- # meander (4)
- # mental-health (1)
- # off-topic (41)
- # pathom (18)
- # podcasts-discuss (2)
- # re-frame (20)
- # react (1)
- # reagent (22)
- # reitit (2)
- # releases (2)
- # remote-jobs (1)
- # reveal (2)
- # sci (10)
- # shadow-cljs (42)
- # sql (20)
- # tools-deps (7)
- # vim (2)
- # xtdb (51)
Does it make sense that :will-enter
code runs 3 times every time a page is loaded?
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.
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?
@U4VT24ZM3 thanks, got it working 🙂
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?
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.
Thanks!