Fork me on GitHub
#fulcro
<
2021-03-23
>
zhuxun200:03:47

(df/load!) uses the mutation df/internal-load! which has a fixed action section (that only sets a load-marker). This means that I can't inject any optimistic code myself. Is this by design?

Tyler Nisonoff00:03:03

load is specifically about fetching data from remotes. If you want to perform an optimistic update along with a load, you can define a mutation with your custom action section filled out, and trigger a load from that as well

zhuxun200:03:55

Hmm, I guess by "trigger" you mean write (df/load!) in the action section of the defmutation? So far I've never done transact! inside another transact! since I felt that's like dark magic and something I wasn't supposed to do. I just took a look at the source code of default-tx!, seems that calling it immediately queues up a tx-node in the ::submission-queue of the runtime-atom. I guess it means that behavior is predictable when my custom defmutation doesn't have a remote section? (If it does, then this custom request will be sent first before the load request)

Tyler Nisonoff00:03:10

i dont think you want to call transact! again — you can just call df/load! directly — see this example in the book: https://book.fulcrologic.com/#_mutations_that_trigger_one_or_more_loads

(defmutation next-page [params]
  (action [{:keys [app state] :as env}]
    (swap! state ...) ; local optimistic db updates
    (df/load! app :prop Component {:remote :remote}) ; same basic args as `load`, except state atom instead of `this`
    (df/load! app :other Other) {:remote :other-remote})) ; as many as you need...

zhuxun200:03:30

Under the hood df/load! calls transact!, doesn't it? That's what I meant by transact! in a transact!.

tony.kay00:03:13

You can install a custom load mutation if you want to extend functionality

zhuxun200:03:07

I think my real question is discussed here: https://github.com/fulcrologic/fulcro/issues/305

zhuxun200:03:43

Short answer: transact! in a transact! is okay in Fulcro 3

zhuxun200:03:34

I think having a :pre-action option (like the :post-action we already have right now) for df/load! would be very convenient... but maybe I'm thinking in the wrong direction? What's the right way other than to write my own load mutation?

nivekuil02:03:29

so I just realized that hooks components don't support shouldComponentUpdate, so I suppose fulcro's default render optimization is bypassed as well.. is it good practice to wrap those in enc/memoize or something similar to replicate that behavior?

nivekuil03:03:43

very rudimentary observation seems to indicate class components being faster to render by 10-30% vs memoized :use-hooks? ones. not a proper look by any means but figured I'd share for anyone curious