fulcro

Book: http://book.fulcrologic.com, Community Resources: https://fulcro-community.github.io/, RAD book at http://book.fulcrologic.com/RAD.html
tony.kay 2021-06-15T04:26:27.183300Z

Yes, synchronous operation is the only way to do an input that transforms things

Marcus 2021-06-15T06:22:33.183500Z

Thanks @tony.kay @holyjak

Timofey Sitnikov 2021-06-15T10:04:58.185600Z

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

2021-06-16T07:20:47.201500Z

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))}})))

2021-06-16T07:26:30.201700Z

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.

2021-06-16T09:21:11.202100Z

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 Sitnikov 2021-06-15T10:06:11.186500Z

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]))

Marcus 2021-06-15T10:51:53.187800Z

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 Ebbinghaus 2021-06-15T11:01:07.187900Z

Can you share some code?

Björn Ebbinghaus 2021-06-15T11:02:52.188100Z

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. 🙂

Marcus 2021-06-15T11:20:22.188300Z

@mroerni thanks, got it working 🙂

Marcus 2021-06-15T11:50:34.188500Z

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

timovanderkamp 2021-06-15T14:29:07.190400Z

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?

2021-06-15T14:51:59.190600Z

@mroerni @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 Ebbinghaus 2021-06-15T15:05:34.190900Z

Can you share your code?

tony.kay 2021-06-15T17:16:13.191100Z

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.

1
tony.kay 2021-06-15T17:17:54.191300Z

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.

tony.kay 2021-06-15T17:20:19.191500Z

(see batched-networking branch, I think)

timovanderkamp 2021-06-15T19:11:08.191900Z

Thanks!