(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?
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?
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
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)
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...
or this example from the realworld fulcro example app: https://github.com/walkable-server/realworld-fulcro/blob/91c73e3a27621b528906d12bc22971caa9ea8d13/src/conduit/ui/profile.cljs#L19-L23
Under the hood df/load!
calls transact!
, doesn't it? That's what I meant by transact!
in a transact!
.
You can install a custom load mutation if you want to extend functionality
I think my real question is discussed here: https://github.com/fulcrologic/fulcro/issues/305
Short answer: transact!
in a transact!
is okay in Fulcro 3
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?
Hmm, interesting
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