This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-28
Channels
- # babashka (10)
- # beginners (140)
- # cider (6)
- # clj-kondo (10)
- # cljs-dev (39)
- # cljsrn (6)
- # clojars (1)
- # clojure (23)
- # clojure-europe (2)
- # clojure-spec (7)
- # clojure-uk (6)
- # clojurescript (1)
- # conjure (16)
- # cursive (3)
- # datomic (3)
- # emacs (6)
- # fulcro (13)
- # graalvm (3)
- # malli (8)
- # meander (4)
- # off-topic (43)
- # pathom (1)
- # pedestal (15)
- # re-frame (13)
- # reagent (3)
- # sci (25)
- # shadow-cljs (26)
- # sql (9)
- # testing (34)
- # tools-deps (80)
Is there a way to have a UI component inlined in its parent but still have a query that works well with fulcro's normalization?
For example, when Person
in PersonList
is trivial (e.g., just a simple div
), I don't want to create a defsc just for that and would like to simply write (for [{:keys [id name]} person-list] (div {:key id} name))
in PersonList
.
@souenzzo Thanks. I am aware of ui-less components, but that doesn't seem to be what I'm looking for. If I had to write a defsc with ident and query, which is going to feed to UI anyways, I might as well make a defsc with UI...
In other words, I'm looking for a shorter inlined syntax for normalization hinting, if that makes sense ...
I mean, an ui-less defsc is already very short to begin with... I use one for a filtering functionality in our product. I use that very same normalized data both for filtering and in another defsc for rendering the results
@zilti I see your point. Thanks. BTW that's what I am doing right now and I was just unsure if I missed anything else.
Are the remote mutations deduped on the server? I just made an experiment where I did (comp/transact! this [(my-mutation) (my-mutation)])
, but judging from logs my-mutation
only got run once on the server
Two of the same mutation in one tx is not easily supportable, since the response is a map keyed by mutation name. Both mutations will run, and both will go to the server, but you’ll only see one remote response since there’s only one place to “put” the value. In practice this means you must call transact! twice so that they are separate submissions.
I believe that is currently not supported. I think the reason is that you can just make a new mutation that handles the logic of both
I think that it's because both are sent in the same transaction and <something> :)