Fork me on GitHub

I got the fulcro-native-template example app running on my mac and noticed two things: 1. the laptop’s fan doesn’t stop running (this is a 2.3 GHz 8-core i9 w/ 32 Gb 2400 MHz DDR4 ram) 2. the iOS Simulator says WARN [taoensso.sente:1287] - Chsk is closed: will try reconnect attempt in 1000 ms


@fappy (2) is it trying to connect to Fulcro Inspect Electron…it is harmless, but you should have that tool for development.


no idea on your fan


should not be soaking CPU…be sure to turn OFF hot code reload and such in the simulator


shadow handles the hot code reload, and if you have the one on in expo it can cause weirdness


@fappy Is your MacBook a 2016-2019 model? Those are notorious for not having enough cooling to handle the older generation 8 core processors. It doesn’t take much load at all to set off the fans.


@tony.kay Yes, I believe I have both of those in the simulator turned off because both menu items say “Enable _“. I’ll make sure I have Electron. @mdhaney Yes, it’s a 2019. Your explanation is probably it. thanks2

Jakub Holý (HolyJak)07:02:38

Hello! How to make a load! in :will-enter execute exactly once, instead of multiple times? I do load! in :will-enter because it depends on the routing params. The problem is that :will-enter is called multiple times and a new load! is issued every time. I thought that Fulcro is smart enough to see they are all the same and execute it just once, but according to the Network tab in the Inspector it does execute every one. I've tried to check for the load marker before issuing the load but that does not work, transactions are async and the load marker is only set later on. So what is the correct and simple way to load data based on routing params just once? Thank you!


you’re probably looking for dr/route-deferred


but it might be tricky to get an immediate routing experience with it, so some instead go with loads via UISM

Jakub Holý (HolyJak)14:02:53

I see. I started with deferred but then it seemed better to go with immediate so that I could show a progress info based on the load marker while waiting for the data. I'll look into UISM though I hoped for a simpler solution :) Thank you!


as a workaround for some cases, you can put a loader component as the first target in router’s :router-targets, dynamic routers use the first target as the default until they are properly routed


@U0522TWDA one other thing: There is an under-documented feature of the router: The body (normally empty) can contain rendering code for routes that defer too long…the thing that isn’t mentioned (fixing that now) is that you get a route-factory and route-props for the currently rendering route, which you can use to show an indication of progress:

(defrouter MainRouter [this {:keys [route-factory route-props] :as props}]
  {:router-targets [LandingPage ItemForm InvoiceForm AccountList AccountForm]}
  ;; Normal Fulcro code to show a loader on slow route change (assuming Semantic UI here)
    (when route-factory
      (route-factory route-props))))


docs improved, but it was actually already there


It can also be useful to just show a general “busy” marker in the UI, which you can do like this:

(defsc Root [this {::app/keys [active-remotes]}]
  {:query         [::app/active-remotes]
   :initial-state {}}
  (let [busy? (seq active-remotes)]
      (div :.
        (div :.
          (div :.item
            (div :.ui.tiny.loader {:classes [(when busy? "active")]}))))

👀 4
Jakub Holý (HolyJak)16:02:10

I used the router body originally but it wasn't optimal for my case because what happen (if I recall correctly) was that 1.the first route target was rendered, 2.after a while (the deferred timeout, I assume) the defrouter body showed up. If I could skip rendering of the default route and directly show the router body then I could use that. Perhaps if I set the deferred timeout to 0... Or perhaps I could make a default route consisting of an empty component to show "nothing" initially and, after a short delay, "Loading..." (which wouldn't thus show at all if the load happenen really quickly...)


@U0522TWDA I’m open to adding options to dynamic router. It could use some enrichment. We could, for example, tell it to always use the router body if present (if you added an option in the component options map that said that’s what you wanted). That would let you look at the route and control the UI very explicitly.

🎉 4
Jakub Holý (HolyJak)17:02:42

That sounds as a good thing, and aligned with Fulcro's principle of allowing the user to control as much as he wants. Of course we need to weight that against the increased complexity but perhaps here it would be a good trade-off... It certainly sounds as a good and simple solution to my problem. I could then freely use deferred routing and display a "loading.." in the router body.


@U0522TWDA well, for bw compat it would not change how it works, it would add that as an option you could enable.


I think it would just be changing this line in the macro when you set something like :always-render-router true to always return true.


@U0522TWDA try 3.1.16-SNAPSHOT. Add option :always-render-body? true


then perhaps :pending-path-segment in props is more useful, since it should change as soon as a deferred route is submitted.

Jakub Holý (HolyJak)17:02:37

Awesome! Thank you! I will try it first thing tomorrow.

Jakub Holý (HolyJak)19:02:46

A thought: wouldn't it be reasonable to allow the body to return nil, in which case the routed target would have been rendered? Instead of having to type (`when route-factory (route-factory (comp/computed route-props (comp/get-computed this))))`?


rather not…there’s already one way of auto-rendering…if you want to take over, then take over. Less cases is better,

👍 4
Jakub Holý (HolyJak)08:02:10

Thank you! It works like a charm. My data loading and progress notification needs are fully satisfied 🙂


Note on read/write combining: Fulcro 2 was doing that. Fulcro 3 could do it, but I have not written the logic in the tx processing layer, so for now read/write combining isn’t happening. An actually, the combining I would be doing would be network layer combining, which would (in this case) still sent N loads, just on one network payload. How am I supposed to know you really meant to load it just once? Maybe you want rapid updates? The combining has always intended to be about reducing round-trip overhead, not changing what you said.

👍 4

you could, for example, issue a load that looks the same 3x but change some parameter (like abort ID). Very easy to overlook cases.