This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-23
Channels
- # announcements (2)
- # architecture (83)
- # asami (2)
- # babashka (49)
- # bangalore-clj (2)
- # beginners (235)
- # braveandtrue (1)
- # calva (17)
- # clojure (109)
- # clojure-australia (5)
- # clojure-czech (5)
- # clojure-dev (24)
- # clojure-europe (17)
- # clojure-germany (2)
- # clojure-nl (3)
- # clojure-serbia (13)
- # clojure-spain (1)
- # clojure-spec (1)
- # clojure-uk (20)
- # clojurescript (3)
- # community-development (34)
- # conjure (10)
- # cursive (21)
- # data-science (1)
- # datahike (1)
- # datalog (1)
- # datomic (12)
- # etaoin (3)
- # events (2)
- # fulcro (13)
- # graphql (8)
- # heroku (2)
- # lsp (58)
- # malli (32)
- # membrane (24)
- # off-topic (63)
- # parinfer (2)
- # pathom (14)
- # portal (14)
- # re-frame (16)
- # reagent (50)
- # releases (1)
- # rum (1)
- # shadow-cljs (10)
- # sql (6)
- # startup-in-a-month (1)
- # timbre (2)
- # tools-deps (61)
- # xtdb (4)
(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?
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!
.
I think my real question is discussed here: https://github.com/fulcrologic/fulcro/issues/305
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?
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?
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
Hmm, interesting