This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-17
Channels
- # aleph (2)
- # announcements (20)
- # aws (43)
- # aws-lambda (5)
- # babashka (9)
- # beginners (231)
- # calva (4)
- # cider (12)
- # cljdoc (8)
- # cljsrn (3)
- # clojure (47)
- # clojure-europe (5)
- # clojure-nl (4)
- # clojure-spec (41)
- # clojure-uk (47)
- # clojuredesign-podcast (3)
- # clojurescript (20)
- # cryogen (3)
- # cursive (4)
- # data-science (2)
- # datomic (15)
- # emacs (4)
- # fulcro (21)
- # jackdaw (6)
- # jobs (1)
- # joker (13)
- # juxt (8)
- # kaocha (10)
- # malli (7)
- # off-topic (29)
- # pathom (11)
- # re-frame (19)
- # reagent (3)
- # reitit (26)
- # remote-jobs (8)
- # schema (2)
- # shadow-cljs (112)
- # spacemacs (1)
- # tools-deps (49)
- # vim (2)
- # xtdb (7)
@mdhaney ah, good pt 🙂 So, it would just be an additional call that you’d make to add options to the current state change transaction. Probably should have had that no matter what.
(uism/apply-action f {transaction options})
I thinkand then there is the actor model to consider…you want to probably list actor names for refresh
big question is: should it be driven externally (where you may have UI code that is triggering events from some location that knows little of the SM structure) or internally (where the definitions know at least the actors).
@mdhaney what do you think of this: https://github.com/fulcrologic/fulcro/pull/361/files?utf8=%E2%9C%93&diff=unified&w=1
I guess this doesn’t yet address the translation from actor names to refresh…I hate to mix the render plugin logic with high-level uism logic
::uism/only-refresh-actors
would be sort of ideal, but then we’re mixing a render-specific optimization with the UISM forever
I’m remembering now that I had intended to analyze what actors had changed in the UISM code automatically and optimize that internally, but again we have the problem of mixing UISM logic with something that can be plugged in with arbitrary custom things.
Guess I could make :only-refresh
a “standard name” for a thing that renderers can choose to implement. Then the refresh actors stuff would be doable
A couple quick thoughts, then I’ll look in more depth tomorrow: External vs internal - I’m thinking handle it internally in the SM. It’s a detail the UI (usually) shouldn’t have to care about, and in the cases where the UI does care, it can always pass event data to the SM to help it do the right thing. I really like the idea of something like ::uism/only-refresh-actors. My initial thinking is you call this once in a handler, then subsequent calls that mutate the state db would adjust accordingly. I was thinking we could just conditionally add :only-refresh to the underlying mutations called by the SM, so no direct changes to the renderer. But it sounds like maybe it’s not that simple. I’ll have to take a closer look at the implementation.
(defmutation add-wire
[{wire-list-id :wire-list/id
wire-id :wire/id}]
(remote [_env] true)
(ok-action [{:keys [app state]}]
(df/load! app [:wire/id wire-id] (comp/registry-key->class :wires.ui/Wire))
(df/load! app [:wire-list/id wire-list-id] (comp/registry-key->class :wires.ui/WireList))))
Isn't something like that considered "bad practice"?I think that is fine (pessimistic). In theory you could avoid chaining by having a returning
mutation, that would both add the wire and bring back wire information. (I've never used, but in the docs: http://book.fulcrologic.com/#ASTMutationJoins)
mutations joins would be the best, specially if you can make the two resources load in a single go (if they are related, you can create a new component that express the query that you need to reload, and use that in returning), this way you can reduce from 3 requests to one
What @U066U8JQJ said…but hard to tell what you graph looks like. If the wire list holds wire, then there is no need to load that specific wire is there? And then if so using returning
in the remote
would be much better.